View the TAM Handbook homepage for additional TAM-related handbook pages.
A success plan is the guiding document which connects the customer’s pain (often the reason for purchasing) to their GitLab solution and verified business outcomes. It is a living roadmap for initiatives GitLab is working on with the customer, tailored to each individual customer based on their needs and adoption.
There are two types of success plans in Gainsight, which is GitLab's Customer Success tool and where we track customer success plans.
For more information on what success plans are, view the slide deck, Success Plans: Foundation for Success, that helped to kick off GitLab's use of them.
A success plan should not be confused with the use of collaboration projects, which are more tactical and less strategic than success plans. Collaboration projects may show some element of strategy and progress as they are used to collaborate on initiatives; however, it is harder to measure and consume the information in issues across projects and groups and in other systems.
A key element of transparency is clarity and focus. If a strategic document becomes noisy with day to day activities, it becomes less transparent. With dedicated success plans, we can focus on our strategic and holistic initiatives and track our progress.
To create a success plan, the TAM will perform the following activities, detailed below:
The objectives should be written from the customer’s perspective and be measurable goals that they drive. For example, an Objective could be “Reduce Cycle Time from X to Y” rather than “Adopt Manage stage” (which would be more appropriate for a Stage Adoption success plan).
You should know how the customer will track the benefits of purchasing GitLab, how the customer will measure success, and how the customer is currently measuring these objectives and if they have those metrics available. If these details are currenly unknown, add some relevant discovery questions to your agenda for your next cadence call, below are some examples:
Business objectives can be either quantitative or qualitative, but both types still need to be actionable and measurable. See below for examples and common pitfalls of each.
Numerical Goals (quantitative): data of past events, such as time saved or money earned
Initiatives (qualitative): description of an outcome that will be a substantial strategic win for the customer
All stakeholders should agree on the business objectives that the project 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.
Start by validating what we understand to be the customer’s pain and your best practices for the group to adapt from there.
For each business objective, review with the customer:
To create a success plan in Gainsight, perform the following steps:
After creating a success plan, you will need to input the objectives that you've collected. Success plans can have multiple objectives, though it’s best to limit it to 1-3 for focus and achievability. Key components of the objectives in the success plan include:
Stage Adoptionis selected, select the Stage Name for reference and reporting purposes
Objectives should be actionable, and Gainsight provides a way to create action items as part of the objective, called tasks. A task in Gainsight is equivalent to a milestone in GitLab's historical success plan terminology.
To create a task, 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".
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.
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.
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 TAMs 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 TAM will update it when they get confirmation from the customer that it is still a business priority for them.
Internally, TAMs 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.
Collaborations projects are meant for continuous use with our customers to track/create issues, collaborate with product/SAs/others on feature requests, engagements, blockers, etc. The collaboration project is often focused on the tactical, day-to-day, and is more specific to Developers, DevOps Leads, Engineering Managers, and Admins, because they use it to talk about issues to solve as opposed to an overall business objectives.
Within the collaboration project, TAMs focus on new/closed/open issues and collaboration with the customer on these issues. It's the primary communication method for the TAM to communicate with the customer on a day-to-day basis and is a way to help the customers adopt using GitLab.
For additional details, see Account Engagement.
Meanwhile, Gainsight ROI Success Plans are a separate entity, as they are meant for articulating and tracking business objectives, typically with executive sponsors, decision-makers, and economic buyers. The succcess plans focus on high-level strategic objectives, instead of the technical and tactical initiatives that are covered in the collaboration project.
TAMs use success plans as part of their EBRs to share insights, progress, and objectives to offer deeper insight into their organization and the value of GitLab, as success plans can track progress towards goals and report on it to the executives.
Stage Adoption: If a customer has as one of their desired business outcomes the adoption of one of Gitlab's stages, then this stage adoption objective would be appropriate to add as a customer objective in the ROI Success Plan.
Gainsight Stage Adoption Success Plans are internal-only and used to track stage adoption campaigns, driving expansion and growth efforts. We see across our customer base an even better retention and growth rate among customers who have adopted 3 stages or more, and we want to measure and iterate on our efforts to drive stage adoption. Data points such as outcomes per stage, length of time for customers to adopt new stages, number of customers adopted per stage/region/segment, and more help us manage growth strategies towards IACV growth. It also gives us the ability to see the relationship between adoption goals and outcomes and relate feedback and blockers to the wider team to help improve GitLab's processes.
The reporting on stage adoption happens at the objective level, so it is key to open an objective with "Stage Adoption" as the category and choose the relevant stage from the dropdown list below.
If we are looking to drive the adoption of a particular stage in a customer account but the customer themselves would not say (yet!) it is a strategic objective for them, then a TAM should use the Stage Adoption Success Plan to open the objective. This second success plan ensures that all customer-facing objectives are aligned with the customer's own goals and strategies but allows us to still track our internal initiatives.
Please review this 3-minute video on how to open a stage adoption objective and categorize it correctly to enable reporting on our team's progress (Gitlab only).