Codifying Your Company’s Customer Success Playbooks

What is a CS playbook?

A prescriptive framework for handling a repeated milestone or activity – outlines the tasks and activities required to execute or support a milestone or activity in the customer journey. We have playbooks for things like new customer kickoff, NPS follow-up, and contract renewal. I break playbooks down into four different categories: risk, opportunity, lifecycle and activity.

What’s the purpose of developing playbooks?

Continuity and consistency – makes sure that everyone is doing the right things at the right time to support the customer and it’s clear to the entire team. We want customers to know that they’re going to get the same kind of support from each CSM, so if a customer’s CSM leaves, they won’t feel as if they won’t be able to get the same kind of support from a different CSM. Playbooks allow a team to make sure the right things are happening at the right time in the customer lifecycle, for every customer.

Leadership visibility – if leadership can see which playbooks are being run across the customer base, they can keep tabs on where my teams are, and to intervene as needed. For instance, during onboarding, leadership can see when a new customer has kicked off, where they’re at in the process, what’s been completed, what’s not completed, and what’s taking too long. 

What does a CS playbook look like? What format are they in, and how long are they?

If you use a CS tool, playbooks can live there – we use Gainsight the same way that sales uses Salesforce. All of our playbooks are built in there and then we have activities that we can execute against. We have some that are manually triggered, and some that are automatically triggered. For instance, 120 days before the out of contract date, Gainsight will automatically trigger our renewal playbook. There are a number of other CS tools out there, like ChurnZero, ClientSuccess, and Catalyst.

If you don’t have a CS platform, you could use Salesforce, Word, or Excel – in Excel, I’ve seen setups where all of their playbooks are a different worksheet and each customer has their own Excel doc that they’re working off of. As different milestones, events, and other things occur, they can go into that worksheet. From there, they have all of those plays and can manage notes, tasks and activities. This still allows for leadership to have visibility as well. 

Upgrade to a CS platform once you have all of your processes documented – for somebody who’s newer and going on this journey for the first time, I’d recommend that you work out your processes through a kind of crawl, walk, run lens and see what works. Figure out what you want to build into your processes, and then, when you’re ready, you’ve got everything documented and can look to move to technology to automate that and streamline it. 

When should a company start to invest in documenting its playbooks?

Start building playbooks when you hire your first CSM – CS gets developed at different times at different companies and that’s ok. If you start documenting playbooks with your first CSM, then you have somebody to work on it with and you have another person to go through the testing. You need to learn about your customers and how they behave. Even though you’ve got a journey map, what are the actual tasks and activities that you need to march them through for your company to be successful. I’ve built playbooks at four different SaaS companies, and there are bits and pieces that are the same, but there’s also a lot that is very nuanced. 

How many CS playbooks might a company have (at $5M, at $10M, at $20M ARR)?

As you mature, I believe in having playbooks to support everything – give your team the flexibility to use them as needed in a way that’s going to provide the best outcome for the customer. We have 50 because I want to take the guesswork out of repeatable tasks. We have four different ones for NPS (for if they’re a promoter, passive, detractor, or no response), one for renewal, one for loss of power, one for M&A, one for onboarding. We have a playbook for all the different things that could pop up and introduce risk into an account or present an opportunity for growth. 

For a start, have playbooks for key lifecycle stages – you could probably get started with 5:

Kick-off

• Kick-off, making sure there’s an activity CSMs see as a hand-off from sales
• Renewal process
• Business review process
• Risk mitigation for a couple key scenarios (e.g. lack of adoption or negative NPS)

Who writes the playbooks, and who’s involved?

The CS leader, working with the CS team – as a CS leader, I work with the CS team to get feedback on what works and what doesn’t, and then we edit often. Quarterly, the operations manager and I will review our playbooks. We’ll also go through and remove tasks that we feel are redundant or we remove steps where our CS team gets stuck because our customers are behaving differently. 

What are some of your top playbooks? What are some of the key steps/components within each?

Risk Playbooks

There could be a lot of playbooks in this category, specific to your business – e.g. budget issues, competitive threat, decrease in device data collection, detractor NPS, lack of product adoption, loss of executive stakeholder, loss of power, user M&A, onboarding taking too long, poor engagement, renewal risk, and technical support risk.   

Sample steps for a detractor NPS playbook:

• Review the NPS comments and research possible sources of concern.
• Review the survey responses from other respondents to determine if this is a shared sentiment from the company as a whole, or if there is an outlier individual who’s having a poor experience at the moment. We want to understand any individual’s response as it compares to the whole company.
• Contact the detractor to discuss the concern and create an action plan to course correct.
• Close the loop by asking the customer if our score would be higher after going through the above steps, or if it’s still the same. There will be a lot of little tasks in there, but we try to simplify this one into four steps so there will be less box checking for the team.

Sample steps for a lack of product adoption playbook:

• Identify current product usage and look at the data to identify changes and patterns of behavior to understand if this is a moment in time or if this is a trend.
• Dig into the data to map the product usage to the customer’s business goals (since no two customers are going to have the same product usage since it’s based off of what they intend to get out of the platform).
• Schedule a call to discuss the customer’s usage. If the customer shared with you that they intended to use your product that way, there may be no real risk. If that’s not the case, uncover potential root causes – have we failed to properly train or enable the customer to use the product? Was there turnover, so there’s now a new person on board who doesn’t know how to use the product?
• Schedule a follow up. The goal there is to make sure that they’re properly trained and enabled.
• Build out an engagement plan and solicit feedback from appropriate teams (if needed).
• Have a line item to monitor product adoption for the two weeks after training enablement.
• Escalate to the business owner if there is no increase in product adoption.

Sample steps for a technical support risk playbook:

• Review the tickets to understand the nature of the customer’s issues. Discuss with the support team, if necessary, and align on the path to resolution.
• Reach out to the customer to understand the challenges. Sometimes this is reaching out to make sure the customer is aware that we are aware and we’re going to continue to work with the support team to make sure their issue is taken care of in a timely manner.
• Have a follow-up discussion or training if necessary. Sometimes customers will go to technical support if they don’t know how to do something. When that’s the case, we want to conduct a training so that it reduces the need to go back and forth.
• Loop in product if necessary. If there’s friction around how the product is working, we want to make sure the product team is privy to what’s happening there.
• We’ll escalate appropriately if the situation warrants it. That comes down to the size of the customer, severity of the issue, and business impact to the state of the issue.
• Close the loop at the customer. We have an email template already created for them to do that.

Expansion/Opportunity Playbooks

These playbooks are mostly for teams that upsell – you might trigger one to discuss additional product offerings based on activity or firmographics, to follow up on a positive NPS survey, or to start a conversation about additional offerings when a customer indicates that they want to renew.

Sample steps for an application/use case discussion playbook:

• Review the applications in their customer 360 to see what their subscription supports today.
• Review their platform usage to ensure the customer is using the products they’ve purchased.
• Reach out to the customer to schedule a technology review. We have no intention here other than to make sure that they’re aware of a feature that our product provides.
• Meet with a customer to review the product and learn a path forward. Our whole motion here is to help the customer visualize what’s possible and we do that through storytelling.
• Schedule a follow up to discuss the upsell opportunity. If it makes sense, we’ll open up an opportunity in Salesforce and start to manage that sales cycle.

Lifecycle Playbooks

These playbooks optimize key parts of the customer journey – process and standardization ensure that best practices are leveraged every time.

Sample steps for a kick-off playbook:

• An email goes to the customer following their introduction.
• Schedule an internal handoff with sales and onboarding.
• CSMs review the contract and all the Salesforce notes.
• CSMs prepare the customer kickoff materials (which is a deck template we’ve created which takes less than 30 minutes to populate).
• Schedule a deck review meeting with the account team.
• Host the meeting with the customer where you review everything above.
• Send a follow-up to the customer with the deck and our success plan.
• Post-onboarding, schedule a review with the customer to discuss if we’ve met the customer’s criteria and ask them if they feel like they’re set up to succeed with the technology. We build that deck, have that meeting, and then send out that review.
• If customers validate that we’ve been very successful, move them out of this initial state of execution into adoption.

Sample steps for a renewal playbook:

• Playbook fires automatically based off of the contract date.
• Team reviews the customer data – product usage, engagement, relationships. They audit everything before going into that conversation so there won’t be any surprises.
• Discuss the renewal – if the customer responds with anything other than a resounding “yes, we intend to renew” we treat it as if they don’t intend to renew. We dig in deeper to see why it isn’t a yes. We’ll fire off a risk playbook if it’s appropriate.
• If it’s a yes, the next step is to prepare a renewal playbook in accordance with the customer’s feedback.
• Contact the business sponsor to confirm the renewal and review it in detail.
• Have a call to review our proposal with the business sponsor.
• Send over the renewal paperwork and follow-up until signed.

Sample steps for a business review playbook:

• Reach out to the business partner to schedule a meeting.
• Review the customer data, looking for any open cases and feedback tickets.
• Build a business review deck (which is a deck template we’ve created which takes less than 30 minutes to populate).
• Circulate the presentation internally for review.
• Meet with the customer champion to align on the message.
• Have our meeting with the customer (and we log that in our timeline, so we have a record that we’ve held that event).
• Send out a follow-up to the customer where we memorialize the entire conversation and outline next steps.

Objectives Playbooks

These are playbooks for each product to ensure customers are getting outcomes – we have playbooks built out for every one of our products and we use them to help support our customers in their adoption and outcome realization. We have a framework built with 10-20 steps that we’ll partner on together to ensure that our customers are getting the value they need to see from our solution. Every product can have different playbooks because there are different outcomes that different customers want to see.These playbooks help the customer see that they’re really getting the ROI/value from the different products and they’re tied directly to their success plan. 

Sample steps for a product objectives playbook for a product that reduces fuel costs:

• The CSM shares the important data sets that impact fuel performance. They pull that data and share it with the customer to say, “here are the areas where your assets are high and there’s a high expenditure on fuel.”
• We’re telling them the insights so they can make changes to burn less fuel.
• Sign up for data sharing agreements with a fuel provider.
• Customers will work with us to configure the product where fuel providers allow us to have access to see where fuel is being spent.
• Customer assigns fuel cards to their designated assets. At this point, we’re doing a pairing in the platform so we can map that data correctly.
• Customer works with the CSM and product manager to implement fuel alerts. So now we’ve created alerting in the platform so the customer will know anytime there’s an increase or something that isn’t in line with the parameter that they’ve set.
• Customer reviews fuel dashboard for instances of fuel burning activities, so they operationalize around those insights.
• Customer assesses weekly and monthly to see those fuel savings. Now we’re working with them to document that we’re driving the cost down over a period of time, and that could take place over several months.

How flexible should you be in departing from the playbook?

The playbook is just a framework – sometimes things happen where the playbook needs to be adjusted (such as a company was acquired). In that case, now we need to contact the salesperson and see where we are in that proces. The steps in our playbooks will be applicable 80% of the time, and then there’s 20% where the team gets to tinker and make the playbook applicable to the exact experience of the customer.

How does the CS leader track all the playbooks that CSMs are running?

Dashboard for all active playbooks – that pulls visibility for all of our playbooks into one place. From there, we can see if our strategic accounts team has a playbook that’s risk related, if tasks are hitting roadblocks, or if we’re running behind on tasks. 

How do you make sure playbooks actually get used, and keep them up-to-date?

Revisit playbooks quarterly – on an ongoing basis, our team submits feedback to my ops manager. We have a team’s channel in our CS group that is exclusive for Gainsight. So the team is giving us feedback and our ops manager is basically managing against that queue and then bubbles anything up to me when we do our quarterly review. Then, every quarter we review our tech stack to make sure the tools that we’ve purchased are working the way we need them to work. Gainsight is the thing that takes the most time and attention, but we look at our other tools too to reflect on and make sure that we’re getting what we pay with every tool that we use. 

You can’t manage what you can’t measure – track playbook usage somewhere. Create a cadence in which you’re connecting as a leader with your team to get that feedback and understand how it’s being used. Unless you’re having that dialogue, you’re not going to have that visibility. 

What are the most important pieces to get right?

Figure out what playbooks you actually need to help your team – don’t create playbooks just to have them. Make sure you’re creating playbooks that will fully support your team and provide the best experience for your customers. 

Get feedback from your team – as you’re building the playbooks, partner with people to get their feedback and determine the appropriate steps and activities that each person needs to complete. Be clear on what the tasks should look like. 

Make sure you can track and measure playbook usage – you need to make sure that they’re being used, because the playbooks aren’t useful if nobody is using them. You also need to check that the playbooks are being used in the right scenarios.

What are common pitfalls?

Provide clarity on what you expect – lay out when you want your team to do certain tasks and activities, with appropriate detail for clarity. Give context on when it’s appropriate to use which playbook. Empower your team to do what is right to drive the outcome. 

Don’t over-engineer – don’t make the playbook creation process too complicated (especially if you’re a small team). Get in a room for 90 minutes and have a conversation about the process and what’s working.