Subscription Management Direction: customers.gitlab.com vs. gitlab.com
Background
Currently, customers can see and manage parts of their GitLab subscriptions on gitlab.com (multi-tenant SaaS), self-managed instances, and customers.gitlab.com (our Customer Portal).
Type of information or action | GitLab.com (for gitlab.com subscriptions only) | customers.gitlab.com | Proposal |
---|---|---|---|
Buy paid tier subscription (First-order) |
|
Consolidate: remove gitlab.com flow and point to CDot. | |
Renew paid tier subscription |
|
||
Buy CI Minutes |
|
Consolidate: remove gitlab.com flow and point to CDot. | |
Buy storage (FO or Add-on) |
|
Consolidate: remove gitlab.com flow and point to CDot. | |
Add seats to a subscription |
|
||
Get provision details for a purchased subscription | Note: link namespace for SaaS, see cloud licensing activation code or license for SM. | ||
View Paid Tier subscription information |
|
||
View CI minutes quota | |||
View CI minutes purchases |
|
|
|
View Storage quota | |||
View Storage minutes purchases |
|
|
|
View invoices | |||
View auto-renewal status for eligible subscriptions |
|
Add to CDot | |
Enable/disable auto-renewal | |||
View QSR status for eligible subscriptions | Add to CDot | ||
Enable/disable QSR for a subscription | Keep as it is. | ||
Manage billable account managers/contacts |
|
Add to CDot | |
Add payment method to Billing Account (e.g., Credit Card) | |||
Use saved payment methods from Billing Account (e.g., Credit Card) |
As we look towards our investments in FY24 and beyond, we should consider how to provide a great user experience, while consolidating and centralizing these actions.
User considerations
- Subscription Manager: understand how much has been purchase and allocate quotas across the team, understand how the subscription is being used, determine how much value is being used and what would be needed for the next renewal.
- Billing account manager: manage payment methods, provide visibility into subscription information
- GitLab users: understand what has been paid for, what quotas they are subject to, how to adhere to those quotas or request increases
- Others?
Organizational considerations
- Large enterprises often have to manage a plethora of GitLab deployments: multiple self-managed instances, mixed self-managed and gitlab.com deployments, soon may add GitLab Dedicated to the mix. Their subscription and billing account managers would benefit from a centralized view of all the information across all deployments.
- SMB customers often have a single GitLab paid deployment (either SaaS or SM), but may have a test instance where they need paid tier activated (though not want to be separately billed for users there).
Proposal
At a high-level, I think that we should move towards consolidation into customers.gitlab.com with integration points in the product as it is useful for streamlined and better UX. For example:
- Purchasing additional storage for a SaaS subscription can be done via customers.gitlab.com. To streamline this experience, from GitLab.com (SaaS, multi-tenant) a "buy storage" link could show up next to the quotas page. This link would take the customer into a customers.gitlab.com purchase flow.
- From a user experience perspective, having GitLab.com SSO on customers.gitlab.com would enable a streamlined experience completing in customers.gitlab.com since it wouldn't require customers to log in / lose context.
- Centralize subs mgmt: Managing a single subscription across multiple GitLab deployments
- A top ask from large customers/enterprises is to manage multiple instances (SM or SaaS deployments) with a single billable subscription.
- To enable this, we'd need to centralize subscription usage data across various SM instances and/or SaaS groups/workspaces into a single place.
- The most feasible and likely streamlined place to manage all this information is customers.gitlab.com. Would require SM instance data around users to get synced to GitLab (license sync or some new endpoint) and SaaS groups data.
- TBD other things
Reference
Where purchases take place as of 2023-01
Where purchases take place as of 2023-01
Reference https://gitlab.com/gitlab-org/fulfillment-meta/-/issues/1064#note_1269080324
Edited by Omar Fernandez