# Cloud license management We are breaking this work into 3 main deliverables: ## v1 MVP 14.0: [Deliver Cloud License management MVP](https://gitlab.com/groups/gitlab-org/-/epics/1878) - Net new customers  - Available for deals sold via sales order form and customers.gitlab.com - Non-partner deals - Quarterly coterms enabled - Autorenewal enabled - Single term deals _(We could deliver multi-term in Q4 if it is ok to generate the license for the entire term at the time of purchase. Meaning, if the term is 3 years, we’d immediately provide the license for a 3 year term which goes against the current sales process of issuing in 12 month increments.)_ ## v2 Gaps Q2: [Deliver Cloud License management gaps](https://gitlab.com/groups/gitlab-org/-/epics/4628) - Migrate existing customers at renewal - Partner deals - Multi-term deals if license needs to be generated in 12 month increments ## v3 More Q3: [Deliver improved subscription management tools](https://gitlab.com/groups/gitlab-org/-/epics/4629) - Using usage data, provide customers with historical usage, including graphs and downloads - Using usage data, provide customers with usage forecasts - Provide in-app ability to purchase without having to leave the application - Provide in-app information related to subscription and even sales person _(where desired and spec’d by sales, for example, for all deals that fit “this criteria”, show the AE Name and email address in the customer’s subscription dashboard.)_ - Adapt license model to allow for tracking user counts and identification of multiple instances (ex. production instance vs. staging) - Automatically deliver security updates --- # 🛠Problem(s) ### 🧐 Customer 1. As a purchaser/customer POC, it's not clear to me how much I owe GitLab or whether or not I'm being billed fairly 1. As a systems administrator, I cannot easily apply my license key due to potential errors around user counts 1. As a systems administrator, it's not easy to see when my instance is out of date and exposed to security vulnerabilities 1. As a customer, sometimes my I have to wait for 24 hours for a ticket response when I have premium support, which could cause longer downtime and cost my company money 1. As a customer, I have to send lots of information to support before GitLab can help me, which could cause longer downtime and cost my company money ### 🦊 GitLab 1. As a GitLab sales rep, renewals and true-ups are hard because I do not have any visibility into my customer's usage 1. As a GitLab sales rep, renewals and true-ups are entirely manual, meaning I can sometimes be stretched too thin and am unable to focus on strategic deals properly 1. As a GitLab sales rep, renewals and true-ups can take a long time, meaning I may not meet my sales quotas 1. As a GitLab marketing executive, I have to deal with hundreds of duplicate records and trial spam, which leads to unnecessary admin and data clean up 1. As a GitLab support agent, I sometimes do not know my customers support tier, so I am unable to know which support SLA they are entitled to, causing potential customer dissatisfaction 1. As a GitLab support agent, I have to add more replies and time to a potentially serious ticket due to the need to find out basic info like their version number, user counts and Plan ### User stories #### 🧐 Customer - As a purchaser/customer POC, I want to pay for accurate usage so that I can feel confident in my relationship with GitLab as a vendor and partner - As a billing administrator, I need to receive clear and accurate bills so that I can process payments faster and more efficiently - As a systems administrator, I need to be able to easily activate my company's GitLab instance so that my DevOps teams can do their work - As a systems administrator, I need to know when the latest security patch is available so I can keep my company's GitLab instance secure and up to date - As a customer, I want to feel confident that my support tickets will be answered in a timely manner - As a customer, I want to have my tickets resolved as quickly as possible and not have to send lots of emails with information #### 🦊GitLab - As a GitLab support agent, I need to quickly know what Plan a customer is using so that I can make sure they receive the right support SLA and are helped in a timely manner. - As a GitLab support agent, I need to know what version a customer is using so that I can troubleshoot their issue more easily - As a GitLab sales rep, I need to be able to easily view up to date user counts on my customer instances so I can make sure that their bills are accurate and their renewals and true-ups are easy - As a GitLab sales rep, I need to be able to process renewals and customer true-ups without friction so I can hit my sales targets - As a GitLab marketing executive, I want to feel confident that we are mitigating trial abuse so that our trial data and lead sources are accurate # 💡 Concept By opting into our Cloud Activation Sync feature, your instance regularly (cadence TBD) syncs a small, encrypted file to our licensing server ([similarly to how an ssh key works](https://en.m.wikipedia.org/wiki/Secure_Shell)). This file/key includes your instance's version number, user counts and status (active/inactive) and product tier (Core, Starter Premium or Ultimate). This feature GitLab to provide you with invaluable services: * You will receive the latest security updates which GitLab can either simply warn you about or you can configure your instance to allow GitLab to patch these updates automatically for you. This is done using the version number. * Configurable, automatic/button click upgrades and system updates. * Fair, usage-based billing based off your inactive/active user counts. True-ups become extremely easy and license keys will no longer be required. This also makes it easier for GitLab to implement different billing models depending on specific customer needs/requirements. * By sending GitLab product tier information, our support engineering team will always know the correct SLA times for your support tickets. # ❓ Why is this important? We want to be able to provide the best service to our customers as possible. This feature reduces significant manual work on our sales and support teams, allows our security teams to protect you from vulnerabilities and your user management and billing experience is vastly improved, reducing friction and frustration for your system and billing administrators. Enabling automatic upgrades also removes the potential overhead for your sysadmins. This feature allows GitLab and our customers to collaborate more closely and opens up possibilities in the future for other exciting features our customers may ask for. Additionally, this protects GitLab from trial and license key abuse, meaning we spend less time handling those issues and more time helping _you_. # ❓ What if our instance is not connected to the internet? Rather than waiting for us to send you a license key, you can copy/paste a unique, encrypted and dynamic instance ID into a field your customer account, which syncs with our licensing server, that contains the data described above. This is something you will need to do anyway whether you are connected to the internet or not in order to create the initial link to our licensing server. If you are not connected to the internet, however, you can simply click a button on your account that says "My instance isn't connected to the internet" which will then generate a token for you to paste back into your instance to create the manual link. This a fairly standard activation process for Cloud Licensing. The downside of not connecting to the internet is you will need to manually re-paste that instance ID every time you want to update GitLab with that information, and you will miss out on live security patches when they are released. However, this is still better than the license key solution we have today as the instance ID/token will do the syncing for you rather than you and your GitLab account manager having to review everything manually during a true-up/renewal. # 🎨 Current design flow exploration https://gitlab.com/gitlab-org/gitlab/issues/31825 # 🧬 UX Research https://gitlab.com/groups/gitlab-org/-/epics/1963 # ✅ Result * Less confusion and frustrations around true-ups and no more license key application issues. * Easier user management * A better experience overall for both GitLab folks and customers * We always know their support level, meaning customers don't end up accidentally missing out on their premium SLA's. * \~100% elimination of Trial license key abuse as we would know if the instance has been on a trial before from the instance ID. # 🚨 Open issues that this may solve * https://gitlab.com/gitlab-org/gitlab-ee/issues/8626 * https://gitlab.com/gitlab-org/license-gitlab-com/issues/102 * https://gitlab.zendesk.com/agent/tickets/128784 * https://gitlab.com/gitlab-org/gitlab-ee/issues/8418 * https://gitlab.com/gitlab-org/gitlab-ee/issues/12241 * https://gitlab.com/gitlab-org/gitlab-ee/issues/4154 * https://gitlab.com/gitlab-org/gitlab-ee/issues/7008 * https://gitlab.com/gitlab-org/customers-gitlab-com/issues/308 * https://gitlab.com/gitlab-org/gitlab-ee/issues/3606 * https://gitlab.com/gitlab-org/customers-gitlab-com/issues/392 * https://gitlab.com/gitlab-com/support/feedback/issues/602 * https://gitlab.com/gitlab-org/license-gitlab-com/issues/63 * https://gitlab.com/gitlab-org/gitlab/issues/7008 * https://gitlab.com/gitlab-org/customers-gitlab-com/issues/392 * https://gitlab.com/gitlab-org/gitlab/issues/14747 * more to be added..