GitLab's Technical Account Managers serve as trusted advisors to GitLab customers. They offer guidance, planning and oversight during the technical deployment and implementation process. They fill a unique space in the overall service lifecycle and customer journey and actively bind together sales, solution architects, customer stakeholders, product management, implementation engineers and support.
See the Technical Account Manager role description for further information.
A Technical Account Manager is an advocate for both the customer and GitLab. They act on behalf of customers serving as a feedback channel to development and shaping of the product. In good balance, they also advocate on behalf of GitLab to champion capabilities and features that will improve quality, increase efficiency and realize new value for our customer base.
Technical Account Managers maintain the relationships between the customers and GitLab. Making sure that everyone is working towards pre-defined goals and objectives.
Technical Account Managers help to bring GitLab to all aspects of your company, not just software development. They can do this by showing other business unit's how to use GitLab for their day-to-day tasks and to advocate for new features and functionality that are in demand by other groups.
Technical Account Managers make sure that the adoption of GitLab is successful at your company through planning, implementation, adoption, training and regular healthchecks.
All Premium customers with a minimum ARR of $100,000 are aligned with a Technical Account Manager. There are various services a Technical Account Manager will provide to ensure that customers get the best value possible out of their relationship with GitLab and their utilisation of GitLab's products and services. These services include, but are not limited to:
It is also possible for a customer to pay for a Technical Account Manager's services in order to receive priority, "white glove" assistance, guidance and support as well as more time allocated to their account on a monthly basis. There are also additional services a Technical Account Manager will provide to the services listed above. These are currently to be determined and will become available before the end of the second quarter of 2018.
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.
|TIER 1||TIER 2||TIER 3|
Technical Account Managers will typically manage customer engagements via a GitLab project in the
account-management group. This project will be based off a customer collaboration project template and then 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.
During the pre-sales process, a Solutions Architect owns the project with assistance from the Strategic Account Leader and should include the Implementation Engineer if there is one assigned. During the pre-sales project, 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, IE and Technical Account Manager) and the customer. There is a preloaded issue for this in the project template.
This 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 project going forward. The project is then moved from a pre-sales project under the
pre-sales account-management group to a post-sales project under
Typically this project template isn't used for small business or mid-market accounts. However, if an Account Manager feels this could be useful to assist their relationship with the customer, then they can utilise it and edit down as needed.
On an account view in Salesforce, there is a Customer Success section, with the following fields:
In order to appropriately track and create Executive Business Review Objects please follow the instructions below:
Creating the first EBR for an account:
Executive Business Review Nameis the name that you give this EBR. Select the
EBR Datethat the EBR is schedule to occur on. If the EBR Date changes please see below for handiling EBR Date Changes To relate the EBR to the appropriate account using the search functionality provided by the
EBR Statusshould be set to either 'Not Started' or 'Scheduled' depending on the current state of the EBR. All other fields should be left alone. Please refer to the section below on if you should link the EBR to any Opporutnities.
Creating any successive EBR's for an account and haddiling Declined/Cancelled EBR's:
EBR Successto the appropriate value. This will automatically create the next EBR for this account 90 days after the
EBR Datefor the current EBR (ensuring that there is 1 EBR per quarter). A number of fields will also auto populate making the creation process of new EBR's much easier and quicker.
Tracking the performance of EBR's:
EBR Status- This field denotes if the status of scheduling of the EBR. This should be used to help monitor workflow (Scheduled vs Not Started) and also to track cancellations, declined EBR's as well as completed EBR's that were actually held
EBR Success- This field tracks the overall success of the EBR with the default set to
Incomplete. This field should only be updated either once the EBR is held or after a cancellation or declined EBR. This tracks what the TAM believes was the outcome of the EBR (or if it was declined or Cancelled)
Cancelled- The main differnce between a Declined EBR and a Cancelled EBR is dependant on how it is handeled. EX: If a customer pushes to only have 2 EBR's a year than 2 of the EBR's each year should be labeled as Declined. Wehre as if an EBR in a the third Q is cancelled last minute and the customer decides not to reschedle and instead to sync next Q than that EBR was cancelled.
Handiling EBR Date Changes:
EBR Dateis changed and is still planned to occur within the same fiscal quarter that it was originally planned to take place during simply update the
EBR Datefield to the new scheduled date
EBR Dateis changed to a date that is in the next fiscal quarter please treat it as if that EBR was declined. Update the
EBR Statusand the
EBR Successfield to
Declinedand save the EBR. Please review the section above on creating successive EBR's for an account as it will automatically be created.
Linking EBR's to Opportunities:
The concept of a customer meta-record is how a Technical Account Manager develops and maintains a holistic understanding of customer accounts. It is a living record that includes both business and technical information about the customer. The data captured here informs not only the Technical Account Manager, but all of GitLab about critical details to the success of our customers.
The business profile is captured during the discovery and scoping stages in the pre-sales phase of the customner lifecycle. Once an opportunity is set to closed-won, the Technical Account Manager is largely responsible for maintaining this data. The business profile of a customer's meta-record contains data points related to their organizational structure, the internal advocate/champion, the features most compelling to the customer, the "why" of purchasing GitLab, objectives for the implementation and critically, the data captured in the customer feedback loop.
The technical profile includes objective data points about a customers technical landscape and can be captured at any stage of the customer lifecycle. Specifically, items related to architecture, sizing, scale, security and compliance requirements are captured in the technical profile. In general, solution architects and implementation specialists are primarily responsible for collecting and capturing information for the technical profile. This information is transitioned to the Technical Account Manager once a customer goes live and the Technical Account Manager maintains the information throughout the remainder of the customer lifecycle.
A series of data sheets and automation scripts is being developed that will streamline much of the intake, discovery and reconnaissance activities during the pre-sales stages of the customer lifecycle. Decisions surrounding where this data will reside and which information is part of the critical path during customer onboarding are currently underway.