Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Account Engagement

  1. You are here:
  2. Customer Success
  3. Technical Account Management Handbook
  4. Account Engagement

View the TAM Handbook homepage for additional TAM-related handbook pages.

We are currently developing new account segmentation which will be implemented in the future. Please see the Customer Segments page for details.

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.

Managing the Customer 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.

Start a new customer engagement

  1. Somewhere between step 3 and step 7 of the customer journey sequence, a Solutions Architect should create a project for the customer in GitLab and include a Professional Services Engineer and Technical Account Manager who are best aligned with the customer account. This typically only applies to Enterprise accounts.
  2. After the Technical Account Manager has been aligned with the account, they will assign themselves to the “Technical Account Manager” field within Salesforce.
  3. The Technical Account Manager confirms that a new customer project has been created based on the Enterprise or the Commercial Customer Success Plan Template. If it hasn't, they need to create it and work with the Strategic Account Leader/Account Executive and/or Solutions Architect to complete it. This should have been done prior to Technical Account Management involvement for all Enterprise accounts. For Commercial accounts, the TAM will create the project once they receive the account and determine it is beneficial to have a customer project.
  4. Follow the steps in the PLEASE-READ-THESE-INSTRUCTIONS.md file.

Start a customer upgrade engagement

  1. After the Technical Account Manager has been aligned with the account, they will assign themselves to the “Technical Account Manager” field within Salesforce.
  2. Provided that the customer is part of the TAM-Assigned segment, confirm that the customer project has been created previously during the customer journey sequence, and if not available create a project for the customer in GitLab and include a Technical Account Manager who is best aligned with the customer account transition. For Commercial accounts, the TAM will determine if it is beneficial to have a customer project.
  3. Verify that the project complies with the Enterprise or the Commercial Customer Success Plan Template.
  4. Follow the steps in the PLEASE-READ-THESE-INSTRUCTIONS.md file.

Where does a Technical Account Manager fit in?

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 account-management group.

Customer Engagement Tips

  1. Make use of the account management projects (Template)
  2. Whenever a customer asks a question via email/Slack, kindly prompt them to open a Support ticket or an issue in the collaboration project
    • Examples of a Support issue: Reporting GitLab downtime, errors or accessibility problems
    • Examples of a Collaboration Project Issue: General questions about product usage, best practices or recommendations, adoption or integration questions
  3. Show customers the power of GitLab by using GitLab with them (ex: related issues, tracking milestones, threaded conversations, ability to interact directly with GitLab’s product/engineering teams)
  4. Make sure you are responding in a timely manner to customer's open issues. When you are prompt to respond, the customer is more likely to continue using the account management projects
  5. Have discussions in the public issues as much as possible. If there is a question/discussion point that requires interaction with the GitLab Engineering and Product teams, post it in the public issue, as it most likely benefits everyone reading the public issue.
  6. When adding a SFDC link to a public issue, remember to provide feedback to the product managers using the feedback template
  7. In-person meetings are some of the most impactful and productive engagements, but they are also the most expensive in terms of time and money. To make sure both parties get the most out of an in-person meeting have an agenda planned well in advance and send the agenda to all parties attending the meeting. Also, if a GitLab E-group member is attending the meeting, an Executive Briefing Doc (internal link) will also be required (see the next section for more details on engaging with an e-group member).

E-Group Customer Calls

Occassionally, a GitLab e-group member (VP or C-level) will be meeting 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 an Executive Briefing Document (internal doc link) 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:

  1. Work on the prep doc and call resources with your account team.
  2. Be as thorough as possible about your customer's details (e.g. ARR, # of users, tier, renewal date, stages in use)
  3. Ensure you answer the 5 W's (who,what,where,when,why) of the meeting and what should be the outcome of the meeting.
    • Make sure that we detail both what GitLab wants out of the meeting and what the customer wants out of the meeting. This is a collaborative partnership that benefits both parties.
  4. Be prepared in advance of what you want the E-Group member to do, say, and ask.
  5. Have an agenda for the call and ensure everyone knows what they're supposed to do (who will speak when and about what).
  6. Add any topics you think the customer may bring up (positive or negative) and advice on how to approach it.
  7. Provide links wherever possible (e.g. documentation, feature requests, blockers, etc.).
  8. To add a deep-link to the Gainsight Success Plan, go to the TAM Portfolio dashboard, scroll down to the "Success Plans by Account" widget, expand the report (click the square on the top bar of the report), then click the link under the "Success Plan" (not the link in the account name column to the C360); copy and paste this link to the document. It's typically recommended to use the Gainsight direct login, rather than the Salesforce login, for this purpose.

For an example of a prep doc and additional materials that received positive feedback, please visit this internal only Google doc.

Disengaging with a customer

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:

Customer Personas

Technical Account Managers focus on helping customers achieve business outcomes by advising and enabling customers on usage of GitLab features. We are able to do this most effectively when we are engaged with customer personas who are responsible for the capabilities that GitLab provides.

We have defined two key personas that TAMs should regularly engage with and align on outcomes and use cases:

Development Lead

A member of the customer's development or engineering department, in a leadership role. This person is aware of and/or responsible for delivering on customer business objectives related to the customer's software production. They are able to speak to development workflows, and SDLC and DevOps practices and challenges.

Software Security Lead

Has responsibility for the security of the software the customer develops. This person is able to speak to business requirements, objectives, compliance frameworks, etc. that the customer has related to the software they produce. They have knowledge of (and possibly own) the customer's current security scanning & management tools.

Persona Enablement

We have role-play scenarios to practice identifying and gaining access to the defined personas.

Capturing customer personas in Gainsight

Customer personas are attributed to individual contacts in Gainsight when viewing an account. To capture a customer persona, use the following steps:

  1. Inside of the account view, click the Contacts link on the left.
  2. Switch to List View by clicking the button next to the word "Contacts" at the top of the screen.
  3. Search for the contact you would like to update, and click on their name.
  4. In their contact record, edit the GitLab Role field and select the persona(s) that apply to them, and then save the field by clicking the check button to the right.

Customer Prioritization

GitLab uses a customer prioritization model and associated metrics based on their customer segment (Strategic, Mid-Touch, Scale) to focus the TAM's efforts where they will have maximum value and impact.

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 vary by TAM segment.

Post-Sales Customer Segmentation

Why do we use a prioritization system?

The TAM Portfolio Dashboard is used to help highlight and review each client, including their priority level.

Strategic Accounts

Priority definitions are as follows:

  1. Priority 1:
    1. TAM-led onboarding
    2. Biweekly check-in call
    3. Yearly EBR (as minimum)
    4. Active Account Growth Plan
    5. 1 active Stage Enablement playbook on customer's current use case
    6. 1 active Stage Expansion playbook into new stage
    7. 2 TAM led workshops per year
  2. Priority 2:
    1. TAM-led onboarding
    2. Monthly check-in call
    3. Yearly EBR (as minimum)
    4. Renewal touch point no less than 3 months prior to renewal
    5. Customer attends 2 Scale Webinars per year
  3. Priority 3: Non-managed child accounts only

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. There may be rare use of a Priority 3 (P3) tier, wherein an account is a child account that is not actively managed outside of its parent account but is still within the Strategic segment.

Each TAM should aim to have roughly one third (1/3) of their book of business listed as Priority 1, and the rest as Priority 2.

Determining priority

Parameters

The following parameters are considered when determining customer prioritization:

Parameter Yes No
Open tier upgrade in the next 3 months 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
Contraction or Churn risk Account in Triage process No contraction or churn risk identified
Onboarding Within first 60 days of onboarding Not in onboarding phase
ARR limit Within ARR limits for P1 Not within ARR limits for P1 phase
Prioritization model

Using the defined parameters and guidance on how to know whether they are applicable, we can use the following flowchart to evaluate priority:

graph TD uptier[Open tier upgrade in the next 3 months]-- Yes -->p1; uptier-- No -->churnrisk; churnrisk[At risk of contraction or churn]-- Yes -->p1; churnrisk-- No -->onboarding; onboarding[First 60 days of onboarding]-- Yes -->p1; onboarding-- No -->ARR; ARR[Within P1 ARR limits]-- Yes -->p1; ARR-- No -->p1exception; p1exception["P1 exception*"]-- Yes -->p1; p1exception-- No -->p2; p1((Priority 1)); p1-.->p2exception; p2exception["P2 exception*"]-- Yes -->p2; p2{{Priority 2}};

A working spreadsheet was created to help determine customer priority.

* Please see priority exceptions for details.

New customer onboarding

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.

Keeping prioritization updated

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.

Priority exceptions

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. Exceptions will be addressed to the regional Sales Management team and documented in Gainsight.

Growth Accounts

The Growth segment aims to have no more than 20% of a CSM's book of business to be Priority 1 at any given time.

For a customer to be Priority 1, they must meet at least one of the following parameters:

The primary difference between Priority 1 and Priority 2 customers is the frequency of synchronous engagement:

Priority 1 customers will also have more focus on having EBRs to ensure alignment on use case adoption and future expansion.

Scale Accounts

The Scale Account prioritization model will be defined in FY23Q1.

Commercial (NORAM, LATAM, EMEA)

Determining priority

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.

Qualification Criteria

Priority 1

Priority 2

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 $200k ARR or above 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:

Engagement Guidelines

For each level of engagement above, the TAM is expected to provide the following services:

Priority 1

Priority 2

Open in Web IDE View source