View the TAM Handbook homepage for additional TAM-related handbook pages.
There are three models currently offered for Technical Account Manager engagement. These are broken into tiers that currently use Annual Recurring Revenue as a metric for determining a manageable volume for a single Technical Account Manager and the depth of involvement during the engagement.
Technical Account Managers will typically manage customer engagements via a GitLab project in the
account-management group. This project will be based off the Enterprise or the Commercial Customer Success Plan Template and customized to match the customer's needs as outlined above. The project is pre-loaded with milestones, issues, labels, and a README template to help kick off the project and outline a proof of concept, implementation, and customer onboarding. The following is a short introduction video on GitLab's first iteration of the Customer Success Plan.
During the pre-sales process for Enterprise accounts, a Solutions Architect owns the project with assistance from the Strategic Account Leader and should include the Professional Services Engineer if there is one assigned. A Technical Account Manager is involved but only for visibility. Until the account becomes a paying customer the project remains in pre-sales. Once the customer has paid, the Strategic Account Leader will set up the "Welcome to GitLab" call along with the key GitLab employees (SAL, SA, PSE and Technical Account Manager) and the customer. There is a preloaded issue for this in the project template.
For Commercial accounts, the Account Executive owns the pre-sales process and engages a Solutions Architect as needed. Once the account becomes a paying customer, the Technical Account Manager will create a customer project if it will be useful to their relationship with the customer, and the Account Executive will schedule a "Welcome to GitLab" call with the customer and the Technical Account Manager.
The "Welcome to GitLab" call will introduce the customer to the Technical Account Manager and begin the handover process. The Technical Account Manager will then lead the rest of the call and own the customer project. If the project was created in the pre-sales project under the
pre-sales account-management group, then it is moved to a post-sales project under
Occassionally, the CEO or another GitLab executive will meet with a customer, for example, as part of an executive briefing, escalation, etc. Please review the EBA handbook page on guidance on how to schedule with the E-Group, specifically the section on customer, prospect, and partner meetings with an E-Group member. There will be a prep call prior to the customer call (typically the day before), and there is a briefing document that must be prepared and shared with the EBA in advance of the prep call, in addition to any materials that will be used during the customer call. Below are some tips to ensure a positive experience:
For an example of a prep doc and additional materials that received positive feedback, please visit this internal only Google doc.
There are situations when a TAM needs to disengage with a customer. Examples include:
When this happens, it is important to manage the disengagement so that the customer understands the reason, and is clear on who they should communicate with going forward. Here are some recommendations for how to have this conversation:
Recommended options to review with the customer include:
GitLab uses a customer prioritization model and associated metrics to focus the TAM's efforts where they will have maximum value and impact. Different regions utilize different models for determining customer prioritization, as described below. The customer prioritization can change during the lifecycle and is reviewed by each region quarterly.
On the Gainsight Attributes section, the TAM can set the priority level per customer with levels 1 or 2, with 1 being the highest. A new TAM-assigned customer coming on to GitLab will default to Pr1 until their onboarding enablement is complete. Pr3 is solely for unmanaged child accounts, and Pr4 is only for our digital customers and not for the TAM-assigned segment, with the exception of the Public Sector that is trialing a TAM-assigned digital customer.
Priority Definitions include:
Why do we use a prioritization system?
TAM Portfolio Dashboard is used to help highlight and review each client, including their priority level.
TAM-assigned customers are segmented into two priority tiers:
Priority 1 (P1) and
Priority 2 (P2). We use a series of "yes/no" parameters to evaluate a customer's prioritization, based on the key aspects of a TAM's responsibilities and value to the customer.
Each TAM should aim to have roughly one third (1/3) of their book of business listed as
Priority 1, and the rest as
The following parameters are considered when determining customer prioritization:
|LAM||High degree of confidence, or explicit evidence, of greater than 10%||Uncertain about LAM, or know for sure it is less than 10%|
|Growth in the next 6 months||Open growth opportunity in Salesforce, and/or explicitly stated intent from the customer for growth||Uncertain about growth in the given timeframe, or the customer has clearly said they have no growth in that time|
|Open tier upgrade||Upgrade opportunity is open in Salesforce and actively being discussed with the customer||No open opportunity in Salesforce, and/or no active upgrade discussion with the customer|
|Current/upcoming stage adoption||Actively working with the customer on planning or implementation||Nothing actively being worked on, or only discussed as a future initiative|
|Current/upcoming infrastructure change||Actively working with the customer on planning or implementation||Nothing actively being worked on, or only discussed as a future initiative|
Using the defined parameters and guidance on how to know whether they are applicable, we can use the following flowchart to evaluate priority:
* Please see priority exceptions for details.
When a new customer is in onboarding, they are automatically
Priority 1. This is a key lifecycle event for a customer, which warrants high engagement from the TAM. Once onboarding is complete, the customer's prioritization should be reassessed.
Since the parameters used to evaluate customer prioritization will change over time, each account's priority should be reviewed and updated quarterly, coinciding with QBRs.
There are occasions that warrant a customer to be prioritized differently than the model indicates. In cases where the TAM and/or SAL believes this is true, an exception may be made.
Examples of when an exception may be appropriate include:
In order to make an exception, the TAM or SAL should discuss the details with the members of the account team and their respective managers. If there is agreement that an exception is warranted, the customer can be prioritized accordingly.
TAM-assigned customers are segmented into two priority tiers: Priority 1 (P1) and Priority 2 (P2). Priority 3 (P3) is used for handling Unmanaged Child Accounts. The prioritization helps TAMs to focus on aligning, enabling and expanding on the customers journey with GitLab.
Each TAM should aim to have roughly 5 to 8 customers as Priority 1, and the rest as Priority 2. A smaller number of Priority 1 customers will allow an increased focus, higher effectiveness and better results. A TAM should roughly spend 60% of their time with Priority 1 customers.
Following parameters and metrics define the prioritization:
|Organizational change within the customer||GitLab ownership is moving to another department within the customer organization|
|Customer lifecycle stage (Gainsight)||Customer is still onboarding majority of the user base|
|Current/upcoming infrastructure change||Actively working with the customer on changing the or implementing GitLab including migrations|
|Customer engagement level||Customer expressed the wish to collaborate on a weekly base|
|LAM||Increasing seats to close gap between licenced users and LAM|
|Expansion plays||Stage adoption or expansion plays as part of success planning|
|GitLab organizational changes||TAM account handover|
Exceptions will be addressed to the regional Sales Management team and documented in Gainsight.
All new Commercial customers default to
Priority 1 to start their engagement. This ensures sufficient time for discovering customer needs and orienting them to working with GitLab (Support plan, success planning, available services and training, etc).
While engaging with a customer, the TAM then determines the appropriate engagement model below needed to ensure long-term success with GitLab. Based on the criteria below, the TAM essentially qualifies the account for a lower level of engagement, moving from highest to lowest engagement.
For each priority level, we follow the ARR rule OR some combination of the other rules. So an account could have clear objectives and be using 5 stages, but if are a top 30 ARR account they remain priority 1. For smaller accounts with low upside, or low stage adoption, we will mark them
Priority 1 only until we have captured Objectives, so that Sales can have more specific conversations when a TAM isn't fully engaged.
In the future we may consider the following:
A TAM may choose to qualify an account up to a higher level of engagement based on the following considerations:
For each level of engagement above, the TAM is expected to provide the following services: