## Related to OKRs * https://gitlab.com/gitlab-com/gitlab-OKRs/-/issues/3376+s ## Purpose In the event that a renewal process takes longer as intended (e.g. customer takes longer then average to sign renewal deal), customers run into the problem that their license expires at the subscription term end and the customer loses complete access to their GitLab instance (**Self-managed or SaaS**). In the case of the above described event, a sales team member creates an internal request with the Support team for issuing a temporary extensions. Once the temporary extension is issued and applied, the customer is unblocked to use their GitLab product again until the renewal is processed successfully (speaking of a timeframe of around <span dir="">\~</span>3 weeks at renewal date). **More context can be found** [**here**](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/997#context "Temporary extension: Allow the field to unblock SM customers licensing issues with a temporary extension license")**.** **Please note:** This is only valid in the event of an upcoming renewal. ## Value for the customer and GitLab With the right guardrails in place this process can be automated. Eliminating the support team involvement from this process can improve efficiency for both the sales team and support (which does not need to be involved in this process if there are sufficient compliance guardrails in place) and most importantly doesn't cut off valid customers for using their GitLab product. Since about April 2022, there have been 1183 internal requests to extend an almost expired subscription license, which averages about 99 extensions per month. In a nutshell, if we are automating the process it should have a positive impact on: - Reduction of customer outreach - Reduction of internal support requests - Efficiency increase in sales workflow - Smooth transition in a cumbersome renewal period (e.g. new years period) - Traceability and analysis of temporary extensions **Note**: The proposed approach is a stop-gap solution and shouldn't be used as the de facto process for renewals. We still want to ensure that customers are able to transition the renewal smoothly through the normal sales rep renewal process. ## High-level requirements The high-level requirements are [available in this issue](https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/997#guardrails-and-abuse-prevention "Temporary licenses: Allow the field to unblock SM customers licensing issues with a temporary extension") for self-managed customers. The solution for SaaS customers should follow the same guardrails as self-managed customers (as outlined in the issue before). The graph below depicts the occurrence of events with the current agreed upon guardrails and abuse prevention mechanisms. ### Timeline of events  [timeline_tempextensions.drawio](/uploads/ed902a10005ec7af9bf3d406eb87666b/timeline_tempextensions.drawio)