View the CSM Handbook homepage for additional CSM-related handbook pages.
A success plan is a roadmap that connects a customer's desired business outcomes to GitLab solutions. It is a living document, developed by the CSM. The input for a success plan comes in the first instance from the value-based conversations with the customer in the presales process and documented in the command plan, focusing on articulated business needs and including metrics where available. The success plan echoes these goals and further articulates metrics, and creates a roadmap for implementation via milestones. It is the strategic vision for the customer to realize success and value with GitLab.
These are some of the reasons we use a success plan:
Success plans are another facet of account engagement and are separate from collaboration projects. The success plan is meant for articulating and tracking high-level strategic business objectives, while collaboration projects are best used for async communication outside of cadence calls, particularly for issues where collaboration with cross-functional groups (e.g. Product & Engineering) is necessary.
As you read through this page, you'll likely notice the success plan described as a living document; this is intentional! A success plan is not a "set it and forget it" exercise. It should be something that the CSM maintains on an ongoing basis and iterates on as they learn new information.
Follow this link for the Success Plan certification on LevelUp: Click here
A success plan must contain:
The strategy section should capture the customer's desired business outcomes, and what GitLab is doing in realizing them.
Examples:
Additional resources that may be helpful in discovering your customer's business outcomes are:
Customer highlights is a high-level overview of the customer and other contextual details. This can include the following suggested headings:
It can also be valuable to capture significant past outcomes in this section, for example:
Reviewing the highlights, the reader should be able to quickly understand the customer's business, why they originally bought GitLab/upgraded to Ultimate and any significant achievements to date
Well-crafted objectives provide an actionable plan towards a customer's desired outcome. They should resonate with both GitLab and the customer.
Each objective CTA should be clearly related to a customer's business outcome (the "why"). This is ideally in the title, or within the CTA's comments.
Objectives should capture:
Within a success plan objective (or "CTA"), tasks can be used to further decompose the plan, assign customer DRIs and provide more timeline detail.
With these three elements, you can develop an objective that allows you to measure and report on progress towards outcomes throughout your book in a scalable way.
There are five types of objectives: Stage Adoption and ROI.
Before we can develop a success plan, we need to understand what is driving the customer's usage of GitLab. This goes beyond the features they are interested in, and extends to the business value GitLab provides.
All stakeholders should agree on the business objectives that the customer is pursuing, which products and services will help them reach that goal, and to keep the scope focused to 1-3 objectives. As you close out objectives, you can restart the process to define and add new ones.
Prepare questions to validate your existing knowledge of the customer's business outcomes and pain points, and learn about business outcomes you don't know yet.
For each business objective, review with the customer:
It's important to share progress with everyone involved as time goes on. The Sales team and the customer should both be kept up to date on where the success plan objectives and tasks stand, so they can continue working on new tasks and in turn sharing the progress with anyone else they think should be aware.
A customer’s business and strategies will change, so the value that they need from you will change with that. To stay up to date, show the success plan to the customer regularly to help keep a fresh understanding of their needs. You can email a report to the customer once a month (or other frequency), listing the objectives and inviting them to reply if they’re out of date. Follow the instructions on how to share a Gainsight ROI success plan.
It's also helpful to identify key times when you interact with a customer that would be good opportunities to review and refresh the success plan. This would ideally be when a discussion of business goals feels appropriate and the right stakeholders are at the table, for example: key handoffs between teams, EBRs, or executive check-ins.
It's recommended for CSMs to use EBRs and/or other recurring meetings such as cadence calls) to review steps achieved thus far and set next steps or new objectives as needed. After these meetings, it's important to log an "Activity" in the relevant objective to record how the customer is trending towards their goals. Before closing an objective, get confirmation from a customer (ideally in writing) that it has been achieved and include that in the activity log.
To keep track that the success plan is up to date, use the custom date field on the Objective in the success plan, “Last Validated”. The CSM will update it when they get confirmation from the customer that it is still a business priority for them.
Internally, CSMs can use the data to track their own trends and objectives achieved over time (e.g. quarter over quarter reports) and use the progress of the success plan to measure the ROI health scorecard.
Gainsight is the platform we use to develop and manage success plans. Below are the steps to create a success plan, followed by best practices and recommendations to apply these steps in practice.
When a CSM is assigned to an account, an active ROI Success Plan will be automatically created with a due date 365 days from the day it is created. To create an additional success plan in Gainsight, perform the following steps:
Customer Name ROI Success Plan" for customer-facing plans and "Customer Name Internal Success Plan" for internal plansAfter a success plan is created, you will need to input the strategy, highlights, and objectives that you've collected from working with the customer.
Success plans can have multiple objectives, though each needs to reflect a key business goal for the customer so typically a customer will have two or three. Key components of the objectives in the success plan include:
Stage Adoption, then select from this dropdown which stage you're helping the customer adoptObjectives should be actionable, and Gainsight provides a way to create milestones as part of the objective, called tasks. A task in Gainsight is equivalent to a milestone in GitLab's historical success plan terminology. In short, the objective is the goal and the tasks are the key milestones to getting there (similar to Objectives and Key Results).
To create tasks, perform the following steps:
Tasks will affect the overall completion of the objective, and provide more granular visibility into progress on the objective when looking at the Gantt chart. To do this, navigate to the Gantt chart tab (next to the Objectives tab) in the success plan and confirm the representation captures the plan. You can adjust dates accordingly (for example, if a task actually started in the past but the entry defaulted its start date to today's date).
Finally, next to the success plan due date, change the "Status" of the success plan from "Draft" to "Active". Don't forget this step, as it determines if your success plan with have a green health score and if your objectives will show up in your cockpit.
On a bi-annual basis (once in the first half of the fiscal year February 1 through July 31, and again in the second half ending January 31), success plans must be manager-reviewed and approved via a checkbox within the gainsight interface.
Managers are to coach each CSM they work with to ensure that all required components are present, with each plan having at least one active objective.
Once the manager and CSM reach agreement that the success plan is in a good state, the manager should click the appropriate checkbox as shown below:
The ROI success plan is the "public-facing" plan that we develop and maintain in collaboration with the customer. It is intended to be shared between GitLab and the customer, and should be considered the foundation of our strategic engagement and the reference for an Executive Business Review.
To share a ROI Success Plan, click the link icon next to the success plan due date and status, search for the users you want to share it with, then click "Preview and Send" and send the email. Alternatively, you can export the success plan by clicking "Export" at the top right.
Stage adoption can consist of two different motions: stage enablement and stage expansion, and each belongs in a specific success plan. Understanding the differences and similarities between these motions is key to properly building your success plans and driving stage adoption plays.
Please review this 3-minute video (GitLab only) on how to open a stage adoption objective and categorize it correctly in Gainsight to enable reporting on our team's progress; the topics the video includes are:
For understanding the Use Case Enablement and Expansion reporting, see Reporting on Expansion and Enablement Objectives.
The purpose of these fields is to provide additional, helpful information as you create and work on the Success Plan. The fields are from Salesforce.
[CP] fields are all from the Command Plan associated with the most recent Closed - Won New Business. Use these fields to track if the customer is adopting GitLab for their intended purpose. Refer to Command Plan handbook page for details on field definitions.
When talking to customers about their objectives, we want to level up the conversation to strategic outcomes. Ideally, the customer will provide us a business outcome in their own words. However, we won't always be able to get that from the customer, and in which case we can use our value drivers to describe the strategic outcome.
When evaluating the customer's articulated outcome, a good way to know if it's a strategic outcome is whether you can connect it directly to one of our value drivers. In practice, if you can describe the connection between the outcome and a value driver with little to no intermediary explanation, it's likely a strategic outcome.
Now that we've gone through the parts of a good objective, let's review some examples of good ones as well as ones that could use improvement.
Example 1:
Title: Reduce SDLC times with higher reliability by implementing HA
Category: ROI
Metrics: Reduce SDLC time by 30%; Achieve 99.999% uptime; Scale to 5,000 users
Comments: The customer's GitLab instance struggles with poor performance and instability, sometimes going offline during peak usage times and costing development teams time, slowing their release cycles.
This example provides the three main components. We have the "what" (higher reliability by implementing HA), the "why" (Reduce SDLC times), and the metrics that will let us determine whether we've achieved the objecive, both strategic (SDLC time reduction target) and operational (uptime and scalability).
Example 2:
Title: Reduce security risk and operating costs by adopting SAST
Category: Stage Adoption
Metrics: Add SAST scanning to 90% of projects; replace existing scanning tool
Comments: The customer wants to adopt the "shift left" security model, and conduct static code scanning earlier in the SDLC. They have an existing tool that runs late in the cycle and is expensive.
Here we have all of the elements, and actually even have two strategic outcomes with one objective! The customer has given us reducing risk and cost reductions (efficiency). Since this is a new part of GitLab that the customer wants to use it's a Stage Adoption objective. We have both a metric related to the adoption across projects, as well as a "binary metric" of replacing a different tool with GitLab. The additional details in the comments help us to shape the narrative of the value we're providing.
Example 3:
Title: Deliver better products faster by adopting GitLab CI
Category: Stage Adoption
Metrics: All new projects use GitLab CI; 75% of existing projects are migrated to GitLab CI from the existing CI tool within 12 months
Comments: The customer's current CI system is cumbersome and requires a lot of administrative overhead to maintain, which slows down the SDLC. They want to replace it with GitLab CI, and conduct a phased migration as well as standardizing on GitLab CI for all new projects.
This objective is using one of our value drivers to describe the strategic outcome. The metrics allow us to track both new projects and existing projects, but as two separate items since they require a different approach. The comments let us describe additional reasons for doing this.
Example 1:
Title: GitLab CI
Category: Stage Adoption
Metrics: Increase GitLab CI usage
Comments: Customer wants to use GitLab CI more.
This objective is lacking in general detail, and provides no strategic outcome for the listed action. There is no definitive metric. At best we can call this an operational outcome since it focuses on tool usage, but since we don't know why they want to use it we can't determine whether they're getting the desired result and value.
Example 2:
Title: Improve reliability with HA
Category: ROI
Metrics: Uptime of 99.99%
Comments: Customer is having downtime issues under heavy load, and needs to be able to scale to the demand.
This is a good operational objective, but we have no articulated strategic outcome. This gives us a "what" and metrics, but there's no "why" that lets us show business value. It's a good starting point, but we'd want to dig deeper into the impact of doing this (and of not doing this) on the business.
The tasks for an objective are the key milestones we will need to accomplish in order to meet the objective. These should be actionable, and they should be granular enough to provide a clear path to success.
Here is an example of a task list that is too broad:
- Initial discovery meeting
- Provide implementation plan
- Implement GitLab CI
The time between each of these tasks is likely weeks, and there is no detail about how we're actually going to implement CI.
Here's a task list/set of milestones that are a little more actionable and detailed:
- Initial discussion about adopting GitLab CI
- Complete discovery call
- Determine interest and create an implementation plan
- Finalize the implementation plan with the customer during review meeting
- Schedule enablement with admins and key users
- Evaluate metrics from the first phase of implementation
- Complete implementation in accordance with implementation plan
- Evaluate metrics after implementation plan has been completed
- Record adoption
The level of detail provides a step-by-step path to moving the customer from the starting point to completion, and accounts for the need to monitor progress on a regular basis.