Resources · Playbooks
Playbooks your CSMs won't ignore
Every customer success team that automates eventually builds too many playbooks. It starts well: a playbook for onboarding, one for low usage, one for renewals. Then someone adds one for NPS detractors, one for support spikes, one for accounts that haven't logged in this week. Six months later a CSM opens their task list on Monday and finds 47 automated tasks, most of them about accounts that are fine.
They do what any sensible person does. They stop reading the list.
A playbook is only useful if the work it creates gets done. Here's how to design playbooks that earn their place.
Fire rarely
The best playbooks fire on a small number of accounts and matter a lot when they do. Tidewater Freight's sponsor change playbook fires when an executive sponsor's email bounces or their title changes in the CRM. Across 1,400 accounts it fires a few times a week. Each time, the CSM knows it's important, because it always has been. In its first year it saved 31 accounts.
Compare that with a playbook that fires whenever weekly logins drop 10%. On a large book that's dozens of tasks a week, most of them noise from holidays and reporting cycles. CSMs learn quickly that it's safe to ignore, and then they ignore it on the one account where it wasn't.
A good test: if a playbook fires on more than 5% of your accounts in a month, the threshold is probably wrong.
Create one clear action
A playbook should tell the CSM what to do, not just that something happened. "Usage dropped" is information. "Usage dropped in the finance team after their admin left; here is a drafted email to the new admin offering a 20-minute walkthrough" is an action.
Draft the email, pre-fill the task, link the account page that shows why. The less work it takes to act, the more often it happens. Always let the CSM review anything that goes to a customer, though. Automation should do the preparation, not the talking.
Measure what happened afterwards
Most teams know how often their playbooks fire. Very few know what happened to the accounts afterwards. Did the at-risk accounts that got the playbook renew more often than similar accounts that didn't? Did the score recover?
Look at each playbook's outcomes every quarter. Keep the ones that move retention. Rewrite the ones that might, with a tighter trigger or a clearer action. Retire the rest. Retiring a playbook is not a failure. It gives your CSMs back the attention the playbook was using.
Respect the customer's inbox too
Playbooks that email customers need limits. An account that drops in usage, files a ticket and hits its renewal window in the same week shouldn't get three automated emails from three playbooks. Set a per-account limit on outbound messages, set quiet hours, and give every playbook a priority so the most important one wins.
Your customers can't see your playbook design. They can see whether you sound like a person who knows them or a system that's been triggered.
Start with three
If you're building playbooks for the first time, or starting over, start with three:
- Sponsor change. The executive who bought the product leaves or changes role. Find the new sponsor within two weeks.
- Health drop. An account's health score falls from green to amber or red. The CSM reviews why and logs a plan.
- Pre-renewal review. 120 days before renewal, every account gets a review on the weekly risk call, whatever its score.
Run those for a quarter. Measure them. Then add the fourth playbook your data says you need, not the one that sounds useful in a meeting.
The point of automation
Playbooks exist so that CSMs spend their time on the accounts that need them, doing the work only a person can do. If your playbooks are creating work instead of focusing it, they're doing the opposite. Fewer, better alerts. That's the whole idea.
Want to see how Playbooks work on accounts like yours? Book a demo.