Customer Success

Welcome to the Solutions Architect Handbook

Role Description

Solution Architects are the trusted advisors to GitLab prospects and clients, showing how the GitLab solutions address clients business requirements. Solution Architects are responsible for actively driving and managing the technology evaluation and validation stages of the sales process. Pre-Sales/Solution Architects are the product advocates for GitLab’s Enterprise Edition, serving as a trusted advisor to the client, focusing on the the technical solution while also understanding the business challenges the customer is trying to overcome.


Primarily engaged in a pre sales technical consultancy role, providing technical assistance and guidance specific to enterprise level implementations, during the pre sales process by identifying customers technical and business requirements in order to design a custom GitLab solution In partnership with the sales team, formulate and execute a sales strategy to exceed revenue objectives through the adoption of GitLab Educate customers of all sizes on the value proposition of Gitlab, and participate in all levels of discussions throughout the organization to ensure our solution is setup for successful deployment Work on­site with strategic, enterprise­ class customers, delivering solutions architecture consulting, technical guidance, knowledge transfer and establish “trusted advisor status” Capture and share best-practice knowledge amongst the GitLab community Author or otherwise contribute to GitLab customer-facing publications such as whitepapers, blogs, GitLab Handbook Build deep relationships with senior technical individuals within customers to enable them to be GitLab advocates Serve as the customer advocate to other GitLab teams including Product Development, Sales, and Marketing Present GitLab platform strategy, concepts, and roadmap to technical leaders with the customer’s organization

Mission Statement

Team Initiatives

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:

  1. Awareness
  2. Adoption
  3. Usage

Initiative: Awareness

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 beleive in our vision and strategy

Initiative: Adoption

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.

Initiative: Usage

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.

When and How to Engage a Pre- Sales Solutions Architect

Engaging GitLab Solutions Architects

Before getting SA involved: 1) Qualification: What is the qualified reason to engage with us? What is the size/quality/state of the opportunity? Have you created your plan?

2) Preparation: Help us, help them. 3 ASKs. Outcome. Infrastructure. Challenges. The SA should either be included in a discovery call or provided with Outcome / Infrastructure / Challenges (see below) information uncovered by the AM in prior interactions with the account. Occasionally, we could support a combination call of discovery and technical demonstration/deep-dive, but this is suboptimal. However, the latter approach does not allow the SA time to prepare for and/or tailor the discussion.

Outcome. WIIFM/T. What’s in it for them? Why are they looking at a new strategy for s/w dev. We need to be able to tailor our demos and presentations to demonstrate value and how we can address their issues. Infrastructure. What i2p tools do they currently have in place? E.g. Jenkins for CI, Ansible/Chef for automation, Codebear for review, VS/eclipse/emacs/vim for dev, etc. Challenges. What problems/roadblocks are they having? Release velocity, visibility, collaboration, automation

3) Engagement Protocol: Navigate to the SA Activity Board: NOTE: The board is located in the Project “Customer Success” and the name of the board is “SA Activity Board” Create a new Issue Add the “SA Backlog” label to the Issue The SA Team will triage the SA Backlog queue and collaborate with the submitter via Issue Discussions. This will not replace SFDC. The SAs will still be required to input the necessary information for each account that is critical to the strategy

Other Sales Topics

Customer On-boarding Process

  1. Welcome! — Welcome the customer aboard GitLab, introduce yourself and your purpose within the company and how you will support them throughout the relationship with the business and what they can expect from you. Provide the introduction to support and how to obtain support "For enterprise, Enterprise Edition receives next business day support via e-mail. Please submit your support request through the support web form.
  2. Personal introduction — (2-5 days) Create a task in Salesforce to conduct a personal introduction to your new account contacts. This should be quick and informal phone call, this is not an opportunity for discovery but an outreach for you to build rapport and open lines for communication.
  3. Installation follow-up — (7-10 days) Create a task in Salesforce to follow-up on the installation, was it successful did they have encounter any issues, were the issues self resolved by using documentation or was the help of support required. This time is a good opportunity to share with the customer the vision of GitLab "Idea to Production" YouTube video.
  4. Education — (20-30 days) Create a task in Salesforce for product education. Remind your customer that our releases are on the 22nd of each month per our Direction. Depending on your timing of this correspondence you may inform them of any major enhancements that have been released or are about to be released.
  5. Discovery — (60 days) Now that your customer has had some time and experience using GitLab, set out to discover the need for EE features and products by running through EE Product Qualification Questions.
  6. Check-in — (90 days) Create a task in salesforce for check-in with customer. Ask if the customer has any outstanding issues. Do they have any feature requests? This is also an opportunity to identify if there has been any changes in the organization, or an opportunity for further user adoption for their goals. For a status check, also identify that key decision makers and license contacts are still current.
  7. Outlook — (6 months) Same as 90 day Check-in task, additionally discuss what the customer roadmap and outlook looks like for the next 6 months. What can we expect in terms terms of growth, what does the customer expect in terms of our product and offerings.
  8. Renewal/Expansion — (10 months) Check in with the customer and let them know they are soon due for renewal. Are there any changes to who is responsible for the renewal or otherwise? Good time to ask about their team growth to see if they need more seats. Good time to educate and develop need for GitLab Products.
  9. Renewal — (11 months) Check in with the customer if they have not yet renewed, if there are any blockers to renewal or any changes to expect.
  10. Renewal — (12 months) Follow up with the customer, if we have lost their renewal discover the reasons why we did not succeed and if any changes can be made or improved. If they have moved to another solution, which and why?
  11. Expansion — For Strategic Deals, an Account Expansion Template should be created.

Customer Success Team Roles

Customer Success has two roles assigned to account coverage - Solutions Architect (SA) and Account Manager (AM). For definitions of the account size, refer to market segmentation which is based on the Potential EE Users field on the account.