View the CSM Handbook homepage for additional CSM-related handbook pages.
A success plan is the outline and roadmap for achieving customer objectives using GitLab. It is used on an ongoing basis to align on outcomes, action items, and status between the customer and the GitLab team. It is the foundation of a CSM’s engagement with their customers.
The success plan is mutually agreed upon by both sides, ensuring the details are reflective of the customer’s objectives and GitLab’s plan to achieve those objectives and alignment across all involved on those details.
It is a living document, and is reviewed & updated regularly in cadence calls, business reviews, account team meetings, and all other situations involving customer journey planning & implementation.
The success plan is part of most interactions with the customer, and as an anchor point for GitLab team planning.
Customer objectives are at the heart of a success plan. These are the core results that a customer needs to achieve, and define how we will work with the customer to achieve success. An objective has the following elements:
These core elements form the foundation for the rest of the success plan and the initiatives that fall under each objective. Using these details, we can determine the steps needed to achieve the objective and track our progress over time.
Once an objective has been fully defined, one or more initiatives are created as action plans to achieve the objective. These focus on the “how” to meet the customer outcomes, and enable a division of responsibility for different aspects of the plan.
Verifiable Outcomes (VOs) are a framework designed enhance the objectivity and visibility of customer achievements through adoption of GitLab. For a full video-based introduction to the concept, feel free to review the embedded youtube below (must be signed into GitLab Unfiltered account):
Much like buying a treadmill, the purchase of enterprise software only creates meaningful return on investment through careful planning, and dedicated effort over a sustained period of time. To avoid the trap of the metaphorical “treadmill” becoming a disused ornament where laundry is hung— it’s crucial that Gitlab’s account teams partner with customers to:
The verifiable outcomes framework has been created to:
A verifiable outcome must be SMART:
To be SMART, outcomes must include:
Verifiable outcomes progress through a four-stage process, represented by scoped labels applied to objective epics in the success plan:
~Verifiable Outcome::Proposed
~Verifiable Outcome::Accepted
~Verifiable Outcome::Delivered
~Verifiable Outcome::Verified
When developing verifiable outcomes:
Talk to your stakeholders. Ask open-ended “TED” questions.
Leverage the resources and examples available to you, including:
Draw upon examples from your peers
Strategize with your account team
Talk to your stakeholders
Imagine you have a customer who wants to shorten their time-to-market, improve their developer productivity, or reduce customer-facing incidents. You agree with their platform engineering team that through the use of GitLab’s CI/CD pipeline capabilities, there’s opportunity to drive standardization and optimization of common operations and broaden the use of common testing frameworks.
To bring objectivity and frame the problem in a business-relevant manner, here are four suggested sets of baseline metrics, success criteria and impact statements.
| Baseline Metrics | Success Criteria | Timeframe | Business Impact |
|---|---|---|---|
| Deployment frequency: 2 per week | Increase to 10 deployments per week | Before July 2025 | Time to market improved by 5x |
| Average deployment time: 4 hours | Reduce deployment time to 20 minutes | Throughout Q2 | 75% reduction in deployment time across X projects and Y deployments netting an estimated $$$ in time savings |
| Manual steps required: 15 steps | Reduce manual steps to 2 | December 2025 | Reduced error rate by XX% |
| Deployment success rate: 85% | Achieve 99.5% deployment success rate | September 2025 | Reduced customer-facing incidents XX by XX per year |
It’s unlikely that all four will be relevant to your customer- considering reviewing one or two of your choosing, and align on which measure(s) they feel are most relevant to their situation.
On a weekly basis, any open objectives in customer success plans will be triaged by the continuous triage bot; provided your objective has draft success critieria, the bot will use GitLab Duo to suggest SMART success criteria with metrics & timelines for you.
/Consider using AI/ as a means to brainstorm and ideate on your verifiable outcome, and evaluate if the criteria, metrics and impact are “SMART” in nature.
The success plan starts during the pre-sales phase, driven by the Solutions Architect. Throughout the product evaluation process the SA and the Account Executive define customer objectives, and use these to demonstrate GitLab value aligned to these objectives. The SA documents these objectives in the success plan slide deck with all of the requisite details. This information is part of what is used for a Proof of Value, and ensures that we have a clear understanding of the customer’s needed business outcomes.
To understand the full process between Pre-sales and Post-sales, please read about the mutual customer success plan process.
Once the AE and SA close a customer, the transition to post-sales takes place. The customer goes through onboarding, during which the CSM uses the success plan to outline a plan for adoption and aligns with the customer on the details of this plan. This includes a review of the already-listed objectives to ensure accuracy and initiatives for each of those objectives related to enablement, implementation, and other actions needed for the customer to achieve their objectives using GitLab.
Coming out of this phase, there should be full alignment between the GitLab team and the customer stakeholders on the objectives and the plan to achieve them, including steps for each of the initiatives, ownership of those steps, and commitment from those owners based on defined timelines. Put simply, everyone should be clear on what comes next and who is responsible/accountable for it.
With the first iteration of the success plan agreed on with the customer, the CSM focuses on putting the plan into action. This has a few key facets:
The most frequent customer engagement point for this is the cadence call. As the success plan is the hub of our work with the customer, details about initiatives and objectives are incorporated into the cadence call as part of our adoption efforts and overall customer management.
Business reviews, similar to cadence calls, occur on a regular basis and provide the opportunity to review the success plan at a high level and demonstrate progress against the success criteria, as well as discover new objectives for the future.
The success plan and business review should be thought of as mirror images of each other: the information maintained in the success plan feeds the discussion for the business review, and new information attained through the business review meeting is captured in the success plan to add to the roadmap for the customer’s success.
A success plan consists of two integrated components: the GitLab-based continuous planning project and the Gainsight success plan. These elements work together to ensure ongoing alignment across all stakeholders and enable measurement and analysis of our efforts.
The success plan is maintained as a living document within a GitLab project, following our continuous planning methodology. This approach provides several key benefits:
The structure of the success plan in GitLab organizes objectives as epics and initiatives as issues, with standardized labels and templates ensuring consistent documentation. This makes it easy to track progress, demonstrate measurable results, and maintain up-to-date information that’s accessible to all stakeholders.
For ease of discovery and visibility, the GitLab continuous planning project must be linked in the customer’s Gainsight success plan using the designated field on the plan info screen (to the right of Approval Status).
Gainsight’s success plan capability enables us to analyze and understand patterns across a CSM’s book of business and our organization more broadly, helping identify what drives successful use case adoption.
While detailed information about objectives and initiatives lives in the GitLab project, we maintain key objective actions / updated in Gainsight timeline, like customer calls, meeting or similar.
When an objective is identified and documented as an epic in GitLab, it is also synced to Gainsight. Once an objective is achieved, or if it is removed for any reason, it is closed in both GitLab and Gainsight accordingly.
This workflow minimizes duplication while enabling CSMs to maintain visibility into the progress and status of their initiatives across their book of business and track results over time.
GitLab.com serves as the source of truth for Success Plans, with automatic synchronization to Gainsight. This integration enables seamless visibility while reducing manual overhead.
View the CSM Handbook homepage for additional CSM-related handbook pages.
The questions and techniques described on this page will provide you with some ways to drive a strategic conversation with a customer, and explore the information you need to develop an effective success plan. A Success Plan should always be a continuation of the Command Plan where available. The below questions are for further expanding on what we know from the Command Plan, or refreshing on objectives if it has been some time.
4707bb80)
