The Customer Success department is part of the GitLab Sales function who partners with our large and strategic customers to deliver value throughout their journey with GitLab.
To deliver value to all customers by engaging in a consistent, repeatable, scalable way across defined segments so that customers see the value in their investment with GitLab, and we retain and drive growth in our within our enterprise customers.
Our large and strategic customers are in need of an ongoing partnership that combines expert guidance with flexibility and adaptability to support their adoption and continuous improvement initiatives.
These customers expect that partner to provide a streamlined, consistent and fully coordinated experience that encompasses the full span of their needs as well as the fully lifecycle of the relationship. Need to focus on 3 main areas in order to grow in our existing accounts as well as land large and strategic:
Opportunity to improve the overall awareness of GitLab in order to promote and evangelize our brand and solution in a meaningful way to provide big business impact to our customers so that they believe in our vision and strategy.
Ensuring paying customers are successful in their onboarding in order to gain adoption and get the most out of our platform and remain happy, paying GitLabers and brand advocates.
Collecting and making use of customer data and insights is key to customer success. It’s important to do more with data and when necessary share back with customers, which in turn helps and encourages our customers to improve and drive adoption.
In an effort to capture the wider scope of customer interactions with GitLab, the flow outlined below will soon addresses the business processes involved through the entire service lifecycle and customer journey. There is an active initiative to unify stages, phases, titles, names, etc led by Marketing and Sales.
The table below depicts the relationships between activities, responsible roles, relationship and opportunity stages in the customer lifecycle. A more detailed in the responsibility assignment matrix (RACI) format will be an critical tool for every GitLab customer.
|Sequence||Activity||Who's Responsible||Business Relationship Stage||Opportunity Stage||Output|
|1||Create relationship lifecycle meta-record (e.g., SFDC)||Account Executive||Lead or Contact||Discovery||A data record containing information related to the prospect and having data fields attributes that will support the long term ability to "current state" of a customer at any given point in the lifecycle. This cell links to an example customer "meta-record"|
|2||Qualify the lead in terms of GitLab value to their organization||Account Executive||Lead or Contact||Discovery|
|3||Engage solution architects||Account Executive||Lead or Contact||Discovery|
|4||Intro and engage solution architect in technical conversations||Account Executive||Lead or Contact||Discovery|
|5||Update relevant SFDC fields with new information||Account Executive||Opportunity||Scoping|
|6||Demo GitLab tech and articulate the value proposition||Solutions Architect||Opportunity||Scoping|
|7||High-level technical discovery and fit assessment||Solutions Architect||Opportunity||Technical Evaluation||Updates to the customer technical profile that demonstrate the architectural fit is feasible and provides sufficient information for generating a SOW and solution design blueprint.|
|8||Capture environment and technical specifics for each prospect||GitLab Group||Opportunity||Technical Evaluation||Enriched customer meta-record|
|9||Create a solution design blueprint from requirements gathering, tech discovery and customer meta-record||Solution Architect||Opportunity||Technical Evaluation||Blueprint solution design diagram|
|10||Handoff solution design blueprint to Implementation Engineer and TAM||Solutions Architect||Opportunity||Technical Evaluation||IE and TAM full review|
|11||Validate the solution design as generated by Solutions Architect||IE and TAM||Opportunity||Proposal||Approval / signoff by IE and TAM|
|12||Create and submit professional services implementation SOW to stakeholders||Implementation engineer||Opportunity||Proposal||Statement of Work (inclusive of blueprint solution design)|
|13||Create and submit Proof of Value (PoV/PoC) plan to stakeholders||Solution Architect||Opportunity||Technical Evaluation||PoV plan (inclusive of blueprint solution design)|
|14||Agreed upon success criteria||GitLab Group||Opportunity||Negotiating||A document that clearly articulates what done looks like and when done is successful. The success criteria are required for proof of value or a professional services implementation. The document should be signed by an accountable individual from both parties and verbally discussed.|
|15||Create and complete Customer Success Plan||Solutions Architect||Opportunity||Negotiating|
|16||Close with a technical win, negotiated terms and signed contract||GitLab Group||Opportunity||Closed Won||Contract, MSA, SLA, OLA, et al the other legal bits|
|17||PoV/PoC project kick-off||Solutions Architect||Opportunity||Negotiating||Kick-off and proof of value execution plan catered to the customer|
|18||Official introduction and account management transition to TAM to customer stakeholders via Welcome Call||Account Executive||Opportunity||Technical Evaluation|
|19||Professional Services Implementation kick-off||Technical Account Manager||Customer||Closed Won||Kick-off and implementation plan catered to the customer|
|20||Transition customer meta-record and technical profile to IE or TAM||Solutions Architect||Customer||Closed Won|
|21||Transition customer meta-record and business profile to TAM||Account Executive||Customer||Closed Won|
|22||Manage the ongoing customer meta-record rigorously||Technical Account Manager||Customer||Closed Won|
For definitions of the account size, refer to market segmentation which is based on the Potential EE Users field on the account.