Skip to content

Deprecate SaaS Trial over existing plan support workaround

GitLab Support: Process Change Rollout Plan

Deprecate SaaS Trial over existing plan support workaround

The Story

At the request of individuals in Sales, Support had previously been upgrading the subscription level of namespaces on GitLab.com for current customers who wanted to trial a higher plan.

This is not something officially supported by CustomersDot and was a workaround intended to help service the needs of the Sales team pending the completion of gitlab-org/gitlab#12186 (closed) (originally scheduled for 12.2)

After several customers experienced unexpected reversions to Free, in 2021-11 (6 months ago), we started the discussion of how we could stop offering these without product support in https://gitlab.com/gitlab-com/support/support-team-meta/-/issues/3887 and started requiring a confirmation of risks for anyone who asked for a trial on top of an existing plan.

Unexpectedly reverting to Free on a production SaaS namespace presents an unacceptable risk to customers. A concrete example would be a company who requires merge request approvals for compliance reasons. Losing access to this one Premium feature for even a few minutes could generate weeks of work to ensure that every merge request merged during the window was appropriately approved.

In https://gitlab.com/gitlab-com/legal-and-compliance/-/issues/913#note_969650838, we raised a concern with the legal team that this situation isn't appropriately covered in our contract language. The answer back was clear: we need to stop offering this as a workaround completely in favour of the safer alternative of trialing in a separate (non-prod) namespace until such a time that the product appropriately supports it or amend our contract language to cover this better.

The Roles

Role Description
Champions @lyle @ralfaro @jcolyer
Users Support Engineers, specifically L&R
Impacted Non-Users All of Sales, Fulfillment (if they decide to prioritize gitlab-org/gitlab#12186 (closed) as a result)

Schedule

  • Rollout to begin 2022-06-13
  • Adoption complete by 2022-07-01

Training

This is mainly a cessation of an activity. Support Engineers will require no additional training, just awareness.

Sales will be notified via #field-fyi, which will include a link to this issue and the FAQ:

Success Determination

Explain here how and what you will be monitoring to determine the success of the change. These are typical questions you might want to answer here:

  • What will success look like?

As this change is the removal of a process, the main criteria for success will be if this was communicated widely enough to Support Engineers and Sales to prevent future requests and any confusion about whether or not a trial over an existing plan is a possibility.

The ultimate success would be to have this feature prioritized into our product to allow customers to safely trial a higher tier of GitLab on their main namespace.

Action Plan

  1. Announce the change and include The Story in the SWIR on 2022-06-13
  2. Post a message in the #support_team-chat slack channel (or other support channel as appropriate) announcing the change and pointing to the SWIR announcment on 2022-06-13
  3. Announce the change and tell The Story in Team meetings by 2022-06-20
    • EMEA team meeting
    • AMER team meeting
    • APAC team meeting
  4. Other communications channels
  5. Report back on change adoption, concerns, etc. by date

Follow-Up Plan

How will you follow-up to understand the results of the change, to make adjustments appropriately, and to rollback if necessary? These are typical questions you might want to answer here:

  • How will results be captured? By whom and by when?
  • What is the plan for considering and making quick improvements?
  • What is the plan should the change be deemed unsuccessful?
    • Is a rollback feasible, and if so how will it happen?
Edited by Lyle Kozloff