# 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 https://gitlab.com/gitlab-org/gitlab/-/issues/12186 (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](https://about.gitlab.com/handbook/support/license-and-renewals/workflows/saas/trials_and_plan_change.html#applying-a-trial-to-a-namespace-with-an-active-subscription) 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](https://gitlab.com/gitlab-com/legal-and-compliance/-/issues/913#note_969650838) 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 https://gitlab.com/gitlab-org/gitlab/-/issues/12186 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: - [FAQ](https://docs.google.com/document/d/14oypfuslV75Uqw_JWvJmoxCEtrOQ_At_DIm4sk8KzvM/edit) ## 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. [x] Announce the change and include [The Story](#the-story) in the SWIR on `2022-06-13` 1. [x] Post a message in the [`#support_team-chat`](https://gitlab.slack.com/archives/CCBJYEWAW) slack channel (or other support channel as appropriate) announcing the change and pointing to the SWIR announcment on `2022-06-13` 1. [x] Announce the change and tell [The Story](#the-story) in Team meetings by `2022-06-20` - [x] EMEA team meeting - [x] AMER team meeting - [x] APAC team meeting 1. [ ] Other communications channels - [ ] Other communications channels, if required: - [ ] `#sales` - [ ] `#customer-success` - [x] `#field-fyi` - issue link: https://gitlab.com/gitlab-com/sales-team/field-operations/enablement/-/issues/1566 1. [ ] 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?