Review `Update GitLab Plan` mechanizer function

Summary

Update GitLab Plan is the most used mechanizer function and supports for multiple use cases.

The goal of this issue is:

  1. to review the use cases that this function is supporting and getting to the root of why these use cases exist
  2. next steps: once we have a good understanding of the use cases, we will address each use case separately and form a plan to either reduce mechanizer usage for the use case, or migrate the mechanizer function to customersdot

Outside the scope of this issue, but iterating towards:

  1. solve for the use cases with reasonable product or process changes, that does not increase the existing burden of effort for any internal team
  2. deprecate this mechanizer function

Use cases

1. Downgrade existing Ultimate trial to Premium

  • 1a) As a customer, I request a Premium trial so that I can determine if the Premium plan is the best fit for my company
  • 1b) As a sales rep, I submit an internal request to downgrade the customer's Ultimate trial to Premium because it is not offered as a self-serve option
  • 1c) As an SE, I use the Update GitLab Plan mechaniser function to downgrade an existing Ultimate trial for a namespace

2. Extend the end date of an existing trial or plan

  • 1a) As a customer,
  • 1b) As a sales rep,
  • 1c) As an SE, I use the Update GitLab Plan mechaniser function to extend an existing trial for a namespace

3. Reactivate an expired trial

4. SaaS NFR (not for resale) "Subscriptions"

Analysis of root problem for each use case

Ask the following questions for each use case:

  • why does the use case exist?
  • are there any workarounds?
  • is the function addressing a bug or a missing feature?

1. Downgrade existing Ultimate trial to Premium

- Why does the use case exist?

There is no option for the customer to select a Premium trial and there is a demand for Premium trials.

- Are there any workarounds?

Yes, a trial can be downgraded via customersdot if the namespace and the cdot account is correctly linked.

- Is the function addressing a bug or a missing feature?

The function helps to provide a feature where one does not currently exist.

2. Extend the end date of an existing trial or plan

- Why does the use case exist?

  1. The customer requires more time to trial GitLab features and isn't ready to purchase yet
  2. The sales process is taking longer than expected and a trial extension ensures the customer has access to GitLab features when a subscription is not active

- Is the function addressing a bug or a missing feature? (What need is this use case trying to address)

This use case is primarily driven by sales-related needs; tickets generated by web direct customers asking for a trial extension are not very prevalent.

The extension can secure a deal by providing a longer lead time for the initial selling process - insight from sales as to how the length of a trial impacts the sale could be useful to determine whether the 30 day length is hampering the sales process.

The extension also fills a gap in time from the trial to the provision of a subscription; or from a subscription end date to the renewed subscription start. Looking at the pipeline for a sales-assisted order, a lead would need trial GitLab, confirm their seat count for the order, negotiate the order with GL sales, possibly organise procurement for the sale from their finance team, get approvals and sign the deal all within 30 days in order to not lose functionality on their namespace. There is possibly a missing feature for this use case.

3. Reactivate an expired trial

- Why does the use case exist?

These come from sales where a prospect says they can't start their own trial. There two scenarios:

  1. Prospect had a trial a long time ago and wants a new one for evaluation.
  2. Same as "Extend an existing trial" #359961 (comment 958510452) but where it recently expired.

Utilization built and implemented a self-serve SaaS trial extension feature, however, this was switched off after it was discovered that the rollout strategy impacted sales efficiency.

- Are there any workarounds?

No, there is no way for a customer to reactivate a trial. They can only start a new trial on a new namespace if they wish to continue a trial with GL.

4. SaaS NFR (not for resale) "Subscriptions"

This doesn't directly rely on update_gitlab_plan, but is closely related to the use of it

The current workflow (hack) involves requesting the partner to start a trial on the namespace, and then a support engineering modifying that Order object manually to change it from a trial to a plan code, setting seat quantity, and extending the end_date (typically for a year)

Why does the use case exist?

SaaS Not For Resale (NFR) subscriptions are not currently supported in GitLab because they don't exist as a product SKU in zuora, and there's no SFDC tracking of the "subscription". We essentially offer them ad-hoc to Partners.

Are there any workarounds?

No.

In the past, namespaces were directly modified via dotcom admin interface to set the plan which circumvents any automation, and occasionally left unregulated, non-expiring Ultimate plans in place.

Solution brainstorm

  1. Special trial controls for sales-assisted customers to cater to their unique needs
Edited by Donique Smit