L&R Support Engineers help resolve problems encountered by customers in the process of purchasing or renewing a GitLab subscription.
L&R work generally involves collaborating with customers and other GitLab teams, primarily Sales and Fulfillment, as well as checking internal GitLab systems and performing data validation. Some examples:
In July, 2020, a decision was made for L&R work to be handled by Support for the foreseeable future. At the time, business-critical priorities prevented the Fulfillment product section from having sufficient capacity to address and resolve the major L&R-related issues. And whereas creating an entirely new team for this work would have been difficult, Support was already engaged and was in a position to scale up quickly to meet customer needs.
See the Fulfillment section description in the Product Handbook to learn who our current Support Stable Counterparts are. If you are interested in being an L&R SSC, please talk with your manager and one of the Regional DRIs.
In collaboration with Sales, Fulfillment and other teams we aim to improve the customer experience related to managing subscriptions. We achieve this by:
Before starting to work L&R tickets, be sure you complete the L&R / Subscriptions training module.
To be effective with this work, you'll need access to systems and tools which you might not otherwise encounter working other Support problem types. This list supplements the baseline entitlements for the Support Engineer job family.
CustomersDot is the common name for the web application built by GitLab and found at https://customers.gitlab.com. All license and subscription management is conducted on this site. You will need access to this to generate, forward and modify customer license and subscription information. When submitting an access request (AR) for CustomersDot, use this information:
CustomersDot - admin
L&R Support Engineers need CustomersDot admin access to work on customer licensing and subscriptions issues and to debug issues on the application itself.
A Salesforce.com (SFDC) account makes collaboration with Sales team members more efficient, primarily because you'll be able to receive notifications when you're tagged in a Chatter message (see the working with Sales workflow).
When creating an individual/bulk access request, use the following information:
SalesForce, Role: Executive - No View All, Profile: Read Only GitLab, with US public sector record visibility
SalesForce, Role: Executive - No View All, Profile: Read Only GitLab
L&R Support Engineers need their own Salesforce accounts to better collaborate with Sales team members as they work on customer licensing issues.
Discussion of Licensing & Renewals tickets and customer issues occurs in the #support_licensing-subscription channel in Slack. This ensures:
- L&R team members will have one channel in which to collaborate
- Increased visibility in queries and shared knowledge
- Increased cohesion in the L&R team regardless of region
At the commencement of the APAC region's Support Hours (23:00 UTC) there is a Daily Stand-up Bot for Licensing and Renewals in APAC post which tags all Support Engineers who have some responsibility for L&R tickets. This thread notifies the team of who is away for the current week, and allows team members to provide updates to each other about when they're working on the queue. This helps ensure coverage reliability of the L&R tickets across the APAC region's support hours.
Zuora is considered the single source of truth or system of record for many subscription and renewal-related items, such as product SKUs, subscriptions and invoices. See the Transition to Zuora as the SSOT issue for more information.
Having access to Zuora will help with troubleshooting in situations where a customer's CustomersDot and Salesforce records present conflicting or confusing information.
When creating an individual/bulk access request, use the following information:
Zuora READ-ONLY access
L&R Support Engineers need read-only Zuora access to troubleshoot Licensing and Renewal customer issues and support requests.
.gitlab-license files.As you work through the queue and on issues, if you spot something in the
Fulfillment backlog
that would makes things better for customers and Support, please label it with
Support Interest::Categorize. See Support's issue list for Fulfillment for more information.
The Fulfillment Stage manages Purchasing and Provisioning, CustomersDot Usage, and Subscription Management. These teams own responsibilities that align with the types of requests we generally see in the queue.
#s_fulfillment channel in Slack
When we look at the product Growth
stage, we can see that the team owns responsibilities that align with some of
the types of requests we generally see in the queue, in particular the
Conversion group.
The queue should not be used for the following:
| Issue tracker | Use Case |
|---|---|
| GitLab Issue Tracker | Issues related to self-managed or GitLab.com functionality or backend processing |
| CustomersDot | Issues caused specifically by something within CustomersDot or affecting self-managed license generation, generated licenses |
| Term | Description |
|---|---|
| Add-on | An optional extra that can be purchased to increase the limits of what is available in GitLab. Common examples of this are a Seat add-on where additional seats are purchased during the subscription term, or an additional Storage or Units of Compute purchase (on SaaS only). |
| Cloud Licensing / Cloud Activation (SM Only) | The preferred method of activating a self managed subscription where subscription data is synchronized daily from the customer instance to Customers.gitlab.com. Unlike a License File, a cloud activation code does not need to be re-applied when the subscription is modified or renewed. |
| Customers Portal / CustomersDOT / customers.gitlab.com | Available at customers.gitlab.com, the customers portal allows customers to view, manage and purchase subscriptions. L&R Engineers can generate, modify and send subscription information from here. |
| GitLab Dedicated | Provides the benefits of SaaS (fully managed maintenance and operations) with infrastructure-level isolation while the customer has access to Administrator account on their instance. |
| Legacy License File / License Key (SM Only) | License files are now a legacy option used to provide SM trials, or for customers subject to certain criteria. License files are necessary to activate a subscription prior to GitLab 14.1. License files typically have a maximum validity of one year, and must be re-issued and uploaded again if a subscription is modified or renewed. |
| Namespace (SaaS Only) | A top-level group on gitlab.com where a subscription is applied. The subscription plan is available to all subgroups and projects under the namespace |
| Offline Cloud Licensing (SM Only) | In situations where customers must maintain an instance without Internet access, an Offline Cloud License) provides the benefits of Cloud Licensing by generating a usage data file locally. The customer is prompted to upload this file monthly. |
| Quarterly Subscription Reconciliation (QSR) | Introduced as a “Pay as you Go” alternative to True-Ups. A QSR is processed quarterly and will deliver cost savings versus the annual approach of True-Ups. |
| Seat | A seat represents GitLab’s implementation of a ‘concurrent software license’, which means the maximum number of users who will use the GitLab application and access paid features at any one time. Customers can change the specific users working with a GitLab Seat, providing the total seats in use does not exceed the total number of seats purchased. |
| Self-Managed (SM) | Instances of the GitLab application managed by the customers themselves. The customers retain complete access and administrative control over their environment. |
| Software-as-a-Service (SaaS) | GitLab.com is the Software as a Service (SaaS) offering for the GitLab product. GitLab team members handle the maintenance, operation and upgrading of GitLab.com. |
| Subscription | Typically, a 12-month agreement to receive access to a tier of features in GitLab. |
| Trial | A short trial (usually at most 30 days) of GitLab paid features with some restrictions when used on SaaS. Customers can initiate a trial directly for both SaaS and Self-Managed on gitlab.com. Trials are often requested by GitLab Sales to extend subscriptions when a customer purchase has not been finalized. |
| True-Ups | A method of reconciling Users over Subscription after the subscription term has expired. True-Ups require the full subscription fee for Users over Subscription to cover the previous subscription term. |
| User | A user on the GitLab platform. Most users will occupy a seat, subject to some exceptions. Users can include administrator accounts (on Self-Managed), as well as automated job or bot users. |
| Users over Subscription (SM) / Seats owed (SaaS) | GitLab permits additional usage over the purchased seat agreement, ensuring more users can be added during the subscription term without unnecessary obstacles. This overage can be processed at any time by adding more seats to the current subscription (seats add-on), processing the overage annually (True-Ups) or quarterly (Quarterly Subscription Reconciliation). |