The first customer success playbook I saw that actually worked was a single page. Not a one-pager in the slide-deck sense, but a genuine single sheet of paper that a CSM could read in two minutes and act on immediately.
It described three situations, what typically happened in each one, what the CSM's decision was, and what good outcomes looked like. That was it. No thirty-day activity schedule. No lifecycle stage diagram. No flow chart with twelve boxes.
Most of the playbooks I see are built differently. They're built like job descriptions: long, comprehensive, describing what CSMs should be doing at each stage of the customer lifecycle. Month one: schedule kickoff. Month two: complete onboarding review. Month three: run first business review. Colour-coded by segment, weighted by account size, usually running to fifteen or twenty pages.
These playbooks are not without value. They document the intended activity rhythm. They're useful for onboarding new team members. But they are not, in the main, decision frameworks, and decision-making is where CS teams most often need help.
What most playbooks document, and what they don't
A playbook built as an activity schedule answers the question: what should a CSM be doing at this point in the customer lifecycle?
A playbook built as a decision framework answers a different question: given what I know about this customer right now, what should I do next and why?
The first question is useful for planning. The second is useful in the field.
The gap shows up in the situations where it matters most. A CSM has an account where usage is declining. Their playbook tells them they're in Month Five and should be running a quarterly business review. It does not tell them whether to run the QBR as planned, lead with the usage trend in the opening agenda item, delay the QBR to do an informal check-in first, or flag the account for CS Ops triage before making any move at all. Those decisions require judgment, and judgment gets better when there's a framework for it, not a calendar.
The three things a useful playbook contains
I'll be direct about what I think a working CS playbook needs:
Situation definitions. A clear taxonomy of the states an account can be in. Not just "red, amber, green" health score labels, but actual descriptions of what those states look like from the customer's behaviour, not from a dashboard calculation. What does a healthy account in Month Three actually look like in terms of usage, engagement, and business progress? What does a deteriorating account in Month Eight look like before the health score catches up? If a CSM can read the situation description and say "yes, that's us," the playbook has done the first job.
Decision points with explicit choices. For each meaningful situation, the playbook should name the decision the CSM faces, not just the recommended action. "If usage is declining and the sponsor hasn't responded in two weeks, the decision is: a) reach out to the sponsor again through a different channel, b) escalate within the customer organisation to find someone who will engage, c) flag internally as at-risk and involve CS leadership. Here's what each of those signals about the account, and here's when each makes sense." Making the decision explicit makes it discussable. CSMs can push back on it, apply judgment, and tell you when the situation doesn't match the playbook. That's useful information. It's how the playbook improves.
Outcomes, not just outputs. Most playbook entries end with an activity: "complete the executive business review," "send the renewal conversation email," "close the escalation." Useful playbooks end with an outcome: "the customer has confirmed their use case is being served and articulated a business goal for the next quarter." The difference between an output (EBR completed) and an outcome (customer articulates next-quarter goal) is the difference between tracking activity and tracking progress. CS teams that track activity can fill dashboards; CS teams that track outcomes can tell you whether they're working.
Who builds the playbook, and how
The playbooks that work tend to have been built collaboratively between CS leadership, CS Ops, and experienced CSMs who've been in the situations the playbook is trying to address. Not written by CS Ops and handed to CSMs. Not written by leadership based on what they think the field looks like. Built together.
CS Ops typically owns the tooling, the data definitions, and the consistency of the framework across segments. CS leadership brings the strategic intent: which situations matter most, what outcomes the business is trying to produce, what "good" looks like from a commercial standpoint. Experienced CSMs bring the field reality: what the situation actually feels like when you're in it, where the playbook as drafted would miss, which customer patterns don't fit neatly into the taxonomy.
That collaborative process takes longer than writing a document. It produces something that gets used.
What to do with the playbook you already have
If you have an existing playbook and it's not getting traction with the team, the most useful diagnostic is a simple question: ask three CSMs to describe the last time they used it on a live account. Not "is it helpful in general", but specifically when and how they applied it to a real decision they were making.
If the answer is "it's good for onboarding but I don't really use it day-to-day," that's diagnostic. The playbook is working as a job description. The decision framework is missing.
The fix isn't always a rewrite. Sometimes it's adding a single section ("when the account doesn't match the expected pattern, here's how to think about it") that gives CSMs permission to use judgment systematically rather than improvising alone.
Questions worth sitting with
- When a CSM in your team faces an ambiguous situation with an account, where do they look for guidance? If the answer is "they ask a senior colleague" rather than "they consult the playbook," what does that tell you about the playbook?
- Can you point to a specific decision a CSM made last quarter that was directly informed by the playbook? Not an activity they completed, but a decision they made.
- Does your playbook describe customer states from the customer's perspective (what they're doing, what they're not doing), or from the internal data perspective (health score thresholds, usage percentiles)?
- Who built your playbook, and how recently have experienced CSMs given input into whether it matches what they see in the field?
- When the playbook is wrong (when a situation doesn't match the framework), is there a mechanism for that insight to feed back into the playbook? Or does each CSM just carry that knowledge individually?
Where Pivotal Path comes in
Building a decision-framework playbook (as opposed to an activity-schedule playbook) is one of the core structural pieces of CS Ops work. We help CS teams design playbooks that actually get used: situation definitions grounded in customer behaviour, decision logic that CSMs can apply and push back on, and outcome measures that tell the business whether the playbook is working.
If your current playbook isn't getting traction, we're happy to look at it with you.
The short version
- Most CS playbooks are built as activity schedules. Useful for planning; not useful at the moment a CSM needs to make a decision.
- A decision-framework playbook contains three things: situation definitions (what does this state actually look like), decision points with explicit choices (not just recommended actions), and outcomes (not just outputs).
- Playbooks built collaboratively between CS Ops, CS leadership, and experienced CSMs get used. Playbooks written by one function and handed to another don't.
- The diagnostic test: ask your CSMs when they last applied the playbook to a real account decision. The answer tells you what kind of playbook you actually have.
Working on this in your business?
We help UK SMEs and scale-ups turn this kind of thinking into action.
Read next
What your offboarding process reveals about your customer success function
Why CSMs Burn Out, and What the CS Ops Infrastructure Has to Do With It
Scaled CS: what it actually means and when you need it
The CS Leader's First 90 Days: Why Fixing Things Too Fast Is the Fastest Way to Get Things Wrong
Automation in CS: Where It Helps, and Where It Backfires
