If you have run a customer success team for more than a year, you have a playbook library. An onboarding playbook. A low-usage playbook. A champion-left playbook. A renewal-in-90-days playbook. Somebody spent a quarter building them. Most of them have not been opened since.
This is not a discipline problem. It is a design problem. Playbooks fail for structural reasons, and no amount of enablement fixes them. This post is about what those reasons are and what a team does instead.
The promise
The pitch for playbooks was reasonable: customer success was improvised, improvisation does not scale, so write down what good looks like for each situation and have everyone run it. Repeatability, consistency, a way to onboard a new CSM in weeks instead of months.
The idea borrowed from sales, where playbooks work tolerably well because a sales cycle has a small number of stages and a clear end. Customer success does not have either.
Why playbooks fail
Accounts do not fit the trigger
A playbook fires on a condition: usage drops 20%, a champion leaves, a renewal is 90 days out. Real accounts hit three conditions at once, or hit one for a reason the playbook never imagined.
Usage dropped 20% because the customer's busy season ended. Usage dropped 20% because they lost half their team. Usage dropped 20% because they found a workaround that is actually a feature request. The same trigger, three completely different right answers. A playbook can hold one of them.
The steps are generic because they have to be
A playbook written for every low-usage account cannot mention the account. So the steps are "schedule a check-in call," "send the adoption email template," "share relevant resources." A competent CSM already knows to do this. The hard part, which is what to say on the call to this customer about their situation, is exactly the part the playbook leaves blank.
They are static and accounts move
The playbook was written against the product as it existed when it was written, for the customer base as it existed then. Both have changed. Nobody rewrites playbooks, because rewriting them means admitting the library needs maintenance, and maintenance is a job nobody was given.
They create work before they remove any
A playbook assigns tasks. Twelve open playbooks across a book of sixty accounts means forty-odd tasks, most of them "check in," most of them not urgent, all of them overdue by Thursday. The CSM learns to close tasks without doing them, the playbook completion rate looks fine, and the dashboard is now lying.
They encode last year's thinking
The best CSM on the team wrote the playbook from what worked on the accounts they had. That knowledge was real. Frozen into a template, it becomes the ceiling: nobody does worse than the playbook, and nobody is supposed to do better.
What replaces them: a plan per account
The alternative is not "go back to improvising." It is to do what the senior CSM who wrote the playbook was actually doing, which is reading the account and deciding what this account needs, and to do it for every account instead of the fifteen there is time for.
A plan per account has four parts.
It starts from what this customer bought you for
Not the segment, not the tier, not the trigger. The sentence the customer would say about why they signed. Everything that follows is judged against that sentence, so the plan for a customer who bought you for quarterly reporting looks nothing like the plan for one who bought you for daily workflow, even if their usage charts are identical.
It is written from the account's current evidence
The plan names the things that actually happened: the champion who left and the person who replaced them, the three escalated tickets and what they were about, the module that stopped being used and when. A plan that could have been written without reading the account is a playbook with a different name.
It is a short sequence of specific steps, each with a reason
"Call Dana (the new VP of Ops, started September 2) this week. She inherited us from Marcus and has not been on a call. Goal: re-establish the quarterly-close outcome as the thing we are accountable for. Then: the reporting-module walkthrough her analyst never got. Then: a 60-day check against the close-time number before the renewal conversation."
Three steps. Each one names a person, a reason and an outcome. Each one could only be about this account.
It is rewritten when the account moves
Dana takes the call and says the close-time outcome is no longer the priority; the board now cares about something else. The plan changes that afternoon, not at the next quarterly review. A plan that cannot change as fast as the account is a playbook that happens to be more specific.
The objection: this does not scale
It did not, which is why playbooks were invented. A senior CSM can write a real plan for perhaps fifteen accounts a quarter. The other forty-five got the template.
This is the part that has changed. Reading the usage data, the tickets, the email, the call transcripts and the public web for every account, every day, and drafting a plan against each customer's success sentence, is work a machine can now do. It is tedious, high-volume, and judged against a written standard, which is the profile of work that automates well.
What does not automate is the decision to run the plan. The CSM reads the proposed plan, agrees or edits, and clicks activate. The steps then get executed and tracked: the task appears in the CRM, the email is drafted for review, the meeting brief is written the morning of the call. The CSM's job becomes the fifteen judgment calls a week that were always the real job, instead of the hundred mechanical ones that filled the week around them.
What to do with the playbook library
Keep it as a reference for what the team believed in 2024. Then stop assigning it.
Pick ten accounts. For each one, write the success sentence and a three-step plan from what you actually know today. Compare it to what the playbook would have assigned. The gap between those two is the work your team has been doing by hand, or not doing at all. Either way, it is what you were paying for a customer success platform to fix.