GitLab.com subscriptions work slightly differently to Self-managed licenses.
Unlike Self-managed licenses which grant equal access to features across an installation, GitLab.com subscriptions are applied to namespaces on GitLab.com (typically groups). Members of groups that have subscriptions applied to them will enjoy those features anywhere within the licensed namespace. For example, if BigCorp has a Gold license, the sub-groups BigCorp/Frontend, BigCorp/Backend will each have access to Gold features and share a common pool of Shared Runner minutes.
Misconception: If I'm in a Gold group, my GitLab.com profile should say "Gold"
Reality: GitLab.com subscriptions are scoped to a namespace, and individual users could participate in many groups with different subscription types. For example, they might have personal projects on a Free subscription type, particpate in an open-source project that has Gold features (because it's public) while their company has a Silver subscription.
Misconception: Subscriptions grant "the midas touch" and any group or project a subscription-bearing user creates will get the features of their subscription level. i.e. a Gold user will be able to create Gold groups in which all members will have Gold features.
Reality: Subscriptions can be applied to any namespace all items created within said namespace will receive the features of the subscription level.
Reality: Applying a subscription to a personal namespace will mean that group-level features will not be present in any groups that user creates.
Misconception: A license key will be emailed out and applied somewhere in the UI of GitLab.com
Reality: Subscriptions are managed, and applied, through https://customers.gitlab.com on a linked GitLab.com account
Misconception: Someone in accounting made the purchase and can pass along the subscription to the team using it.
Reality: Subscriptions are managed by a GitLab.com account who has Owner in the group.
Misconception: I should purchase my subscription first before setting up accounts on GitLab.com
Reality: You can do this in any order, most will find it easier to set things up on .com before they purchase, with the exception of those who want to set up SAML.
Misconception: I can apply different subscription levels to subgroups.
Reality: Subscriptions are applied to top level groups; sub-groups inherit their license (and Shared Runner minutes) from the top-level group.
Misconception: Minutes are deducted from my group for any jobs that are run, even on my personal runners.
Reality: Runner minutes are deducted only from jobs run on GitLab.com Shared Runners, you can set up your own runners per project or group without affecting your shared minutes.
Trials should be initiated by users by going to the Settings page of the group that they want to apply the trial to.
Common issues the Support Team encounters with sales-assisted purchases
The support team sometimes receives tickets in Zendesk from sales-assisted clients with basic questions like how to set up groups, how to add additional users, why subscriptions are applied to groups vs users, permission questions, etc. Support will direct them to corresponding documentation to address their questions.
Customers are typically not aware that creating an account in the customer portal does not create an account on GitLab.com or how to link a customer portal account to their GitLab.com account.
There is presently not a self-service way for customers to upgrade/downgrade subscriptions so any of these requests must go through the sales team via a queue in Zendesk.
Requests can sometimes be delayed by the volume or lack of information provided when the ticket is sent to Sales.
How we can set the customer up for success
The best way to assist a user or system admin on any new platform is to arm them with the resources they will need when questions arise. During the onboarding process after the sale, the user/admin will receive an email from GitLab with pertinent information about their subscription. Highlight this and encourage them to save it somewhere easily accessible.
While many of the links below are included in the email, it would be helpful to review each of the following resources personally with the user/admin.
A few more best practices to ensure a smooth start
On this page, you'll read about differences between GitLab.com and Self-Managed functionality. Whenever in doubt, don't hesitate to ask us about a particular feature/functionality which is important to your prospect prior to promissing it is available. For a question like this, contact us on Slack in the #support_gitlab_com or #support_self-managed channel.
Be sure to stress to the new user/admin to submit their support issues directly to us via the Support Portal instead of using you as a go-between. This will provide the most timely and comprehensive support we can offer.
If you find yourself having to submit something on behalf of the user/admin, do not submit a ticket via the Support Portal/Zendesk. Instead, create an issue in dotcom-internal.
For GitLab.com, make sure the user understands how to link their GitLab.com account to the customers portal and how to associate their group with their subscription. See managing subscriptions page for instructions.
Important differences between GitLab.com and Self-Managed subscriptions
The Pricing page includes a "Frequently asked questions for GitLab.com" section that answers "What features do not apply to GitLab.com?" in detail. Here are some highlights:
Access controls: customer is admin on GitLab instance vs. group owner on GitLab.com
Log information and auditing: unrestricted access vs. no access on GitLab.com (can work with Support/Security to answer questions)
Instance wide settings: custom vs. same for all GitLab.com users
Infrastructure: manage your own, anywhere vs. GitLab manages HA Architecture, instance level backups/recovery, upgrades, based in US