---
title: "Why CSMs Ignore the Customer Success Playbook You Built"
description: "A customer success playbook goes unrun for seven repeatable reasons: too many plays, a calendar trigger, no decision rights, no outcome test. The fix for each."
topic: "Playbooks & Operations"
author: "Raj Bheda, Co-founder, GainTrace"
audience: "CS Operations, Head of Customer Success"
published: 2026-09-18
modified: 2026-09-18
source: https://gaintrace.com/explore/playbooks/why-csms-ignore-the-customer-success-playbook
---

# Why Do CSMs Ignore the Customer Success Playbook We Built?

*When the plays fire and nothing happens*

**Short answer:** A customer success playbook goes unrun because running the play costs the CSM more than skipping it and nobody checks either way. Seven causes do almost all of the damage, and five of them are design faults you can fix in a week: too many plays, a calendar trigger, a first step that needs someone else, no decision rights, and no outcome test.

**Key takeaways**

- Count the plays before you blame the people. A set a CSM cannot recite from memory is a document, not a customer success playbook, and six to nine live plays is the ceiling most teams can hold.
- Triggers built on a date fire at the wrong moment for every account. Build the trigger on a change in the account and the play arrives when the CSM already believes it.
- A play whose first step needs an approval, a data pull or a second team will be skipped, because the CSM is measured on the outcome and not on the waiting.
- Measure the ghost play rate: the share of plays marked complete that changed nothing in the account within 30 days. High completion with a high ghost rate means the team is processing the playbook, not running it.
- Retire plays on a schedule. A playbook that only ever grows reaches the point where following all of it is impossible, and CSMs start choosing which rules to obey.

The customer success playbook took a quarter to write, three people reviewed it, and six weeks after launch the tasks it generates are being closed in batches on a Friday afternoon with no email sent and no note written. Nobody is refusing to use it. The plays fire, the queue fills, the completion percentage looks respectable in the weekly report, and the accounts carry on exactly as they did before.
This page is for the CS Ops lead or Head of CS who built the plays and cannot work out why the team will not run them. It names the seven causes, shows which five are design faults you can repair without asking anyone to change their behaviour, gives the two numbers that tell you whether a play is alive or dead, and sets out what to do if the team still will not run it after the rewrite.

## Why do CSMs ignore the customer success playbook we built?

> **The ghost play:** A ghost play is a play that fires on schedule, gets marked complete, and leaves no trace on the account: no reply, no meeting booked, no change in usage, no note another person reads. The ghost play rate is the share of completed plays that produced nothing measurable within 30 days, and it is the only number that separates a customer success playbook being run from one being processed.

CSMs ignore a customer success playbook when running the play costs more than skipping it and nobody checks either way. That is the whole mechanism. A CSM with more accounts than hours triages by instinct every morning, and a play that arrives with no context, needs a data pull before step one, and produces a task nobody will ever look at loses that triage to an angry email every time.

The pattern shows up in public reviews of the tools these plays run in. Of 4,978 public G2 reviews of customer success platforms read in September 2026, 432 (8.7%) mention a playbook and 329 (6.6%) mention CTAs, and the complaints cluster on volume and relevance, not on the feature. One reviewer names the cause without being asked to.

> "The ease of customization of playbooks can sometimes cause us to create too many but that may be more a problem with our processes than with the platform itself."
>
> — Mid-Market reviewer, public G2 review

> "My cockpit tends to fill incredibly fast and separating the noise from the signals can be difficult."
>
> — Mid-Market reviewer, public G2 review

Across 33,600 Reddit posts from r/CustomerSuccess, r/SaaS, r/sales and r/startups dated May 2024 to September 2026, 194 mention a playbook and 58 mention one alongside CSMs. The threads read the same way: the plays exist, leadership asks for evidence they are being followed, and the people who own the accounts describe the exercise as admin that nobody downstream reads.

> "AMs don't care what CS plans are, my CSMs barely update them anymore because nobody reads them or works them into the overall account plan."
>
> — r/CustomerSuccess, 2026

## Which seven reasons stop a customer success playbook being run?

Seven causes account for nearly every customer success playbook that stopped being run. Five are design faults in the play itself, which means they can be fixed without a single conversation about accountability. Two are structural, and no amount of rewriting will touch them. Find your rows first; most playbooks carry three or four at once.

| Cause | What you see in the queue | Fix |
| --- | --- | --- |
| Too many plays | Nobody on the team can name the plays without opening the tool. New plays get added every quarter and none are ever retired. | Cut to six to nine live plays. Retire anything that has not changed an account in two quarters, and cap the total so a new play displaces an old one. |
| Calendar trigger | Plays fire on day 30, day 90 and 120 days before renewal regardless of what the account is doing, so half arrive at accounts where they make no sense. | Trigger on a change in the account against its own baseline: usage drop, champion role change, support pattern, billing movement. The CSM then already believes the play before they read it. |
| First step needs someone else | Tasks sit open for a week. The CSM is waiting on a data pull, an approval, a credit decision or a second team, and the clock runs against them anyway. | Rewrite step one so it can be done alone in under five minutes. Put the data the play needs inside the play, not in a report the CSM has to go and build. |
| No decision rights | The play ends in a recommendation the CSM cannot act on: a discount, a credit, an escalation, a roadmap commitment. So the play stops at the recommendation. | Attach the authority to the play. Name the limit in writing (credit up to X, an extra training session, a named engineer for an hour) and who approves anything above it. |
| No outcome test | Completion is high, results are flat, and nobody can say which play saved an account. The report measures whether the task was closed. | Score every play on what changed within 30 days, not on completion. Retire plays with a high ghost rate instead of defending them. |
| Coverage is the real problem | The playbook is fine and the CSM has 180 accounts. Every play is skipped, not this one. Skipping is the only rational triage available. | Fix coverage or cut the tier. A play cannot buy back hours that were never there, and a queue nobody can clear teaches the team to ignore the queue. |
| The playbook was written by people who do not run it | The steps describe a customer who does not exist: one product, one contact, no procurement, a reply within two days. CSMs say so and are told to follow it anyway. | Have two CSMs run the play on live accounts before it ships, and give whoever ran it the authority to change a step without a committee. |

> "The only minor issue is that sometimes CTAs get triggered too often based on the rules set up."
>
> — Senior Customer Success Manager, mid-market SaaS, public G2 review

The last row is the one that makes people uncomfortable, and it is also the most common in our corpus. A playbook written by someone who has never carried a renewal reads as theory to the person holding the account, and the tell is always the same: the steps assume a tidy customer. The same complaint appears outside customer success too, where a team building sales plays found the documents lost to the work.

> "We have tried playbooks in Notion and Confluence and neither really works in the flow of an actual deal."
>
> — r/startups, 2026

## How many plays should a customer success playbook contain?

A customer success playbook that a CSM can hold in their head runs to six to nine live plays, not sixty. No published benchmark exists for the number of plays a CS team can sustain, and anybody quoting one is guessing, so the honest test is arithmetic on your own team: count the plays that fired last month, multiply by the median minutes a play takes end to end, and compare the answer with the proactive hours your CSMs have after meetings, escalations and inbound.

**Play load**

```
Play load = Plays fired per CSM per week × Median minutes per play ÷ Proactive minutes available per week × 100
```

Where:
- Plays fired per CSM per week: every task, CTA or alert the playbook generates for one person, counted from the tool, not from the design document
- Median minutes per play: from opening the task to sending the thing, including the data the CSM has to go and find; time five real ones with a stopwatch instead of estimating
- Proactive minutes available: the week minus meetings, inbound, escalations and admin. On most portfolios this is 4 to 8 hours, not 40
- What good looks like: under 60%. Above 100% the playbook is asking for hours that do not exist, and the team will triage it by ignoring the plays that are quietest about being ignored

> **Worked example:** A CSM covers 120 accounts. The playbook fires 34 tasks a week for them. Five timed plays take 9, 22, 14, 6 and 19 minutes, a median of 14. That is 34 × 14 = 476 minutes, a little under 8 hours. The same CSM logs 6 hours of uncommitted time in a week, or 360 minutes, so play load is 476 ÷ 360 × 100 = 132%. The playbook is asking for a third more time than exists, which is why 11 of the 34 get closed unread on Friday. Cutting to the six plays that moved an account in the last two quarters brings the weekly count to 12 tasks and the load to 47%. These figures are illustrative; run the count on your own tool export.

Coverage sets the ceiling on all of this, and it is worth checking before you touch the plays. If the number comes back above 100% and the account count is the reason, [how many accounts per CSM is too many](https://gaintrace.com/explore/playbooks/accounts-per-csm-coverage-model) and the [accounts per CSM calculator](https://gaintrace.com/tools/accounts-per-csm-calculator) are the better place to start. A playbook cannot create hours.

> "Good luck trying to build advanced playbooks or workflows without wanting to yeet your laptop."
>
> — Customer Success Manager, enterprise SaaS, public G2 review

## How do I redesign a play so a CSM will run it?

Redesigning a play means rewriting three things in order: the trigger, the first step and the exit. Everything else in a play is decoration. A play with a trigger the CSM believes, a first step they can take alone, and an exit that says what happens when it works and when it does not will get run without a reminder from anyone.

1. **Replace the date trigger with a change trigger.** A play that fires 90 days before renewal fires on a healthy account and a dying one with equal confidence. Trigger instead on movement against the account's own baseline: weekly active users down 30% over 30 days, the champion changing role, a support pattern shifting, an invoice going unpaid. A [customer health score](https://gaintrace.com/blog/customer-health-score) built on change rather than level is the usual source, and the CSM reads the trigger as information, not as a reminder.
2. **Put the evidence inside the play.** The play should open with the three facts that justify it: what changed, when, and who it happened to. If the CSM has to open two other tools to find out why the task exists, the play has already lost to the inbox. This one change does more for completion than any amount of training.
3. **Make step one doable alone in five minutes.** Send the message, book the call, read the ticket. Anything that needs an approval, a report or a second team belongs at step three, after the CSM has committed to the play. A first step with a dependency is a queue, and queues are where plays go to die.
4. **Attach the decision rights to the play.** Write the authority into the play itself: the credit the CSM can offer without asking, the training hours they can give away, the engineer they can borrow for an hour, and the named person who approves anything larger. A play that ends in asking permission is a play that ends.
5. **Define both exits before you ship it.** Say what done looks like and what the play does when it fails. A save play that ends with no reply after three touches should hand the account somewhere: a manager, a different channel, a written risk. Plays without a failure exit leave the CSM holding an open task with nowhere to put it, and open tasks with nowhere to go are the ones closed in batches.
6. **Run it on ten live accounts before it ships to everyone.** Two CSMs, ten accounts, two weeks, and the authority to change any step without a committee. What comes back is usually a shorter play with a different trigger. Ship that one.

The order matters more than the content. Teams almost always start by rewriting the wording of the steps, which is the one part a CSM was never blocked by. The tools tell the same story: reviewers ask for control over the plays they run, not for more of them.

> "If we could create our own library of playbooks to help with repetitive CTAs based on our own workflows and customer groups that would be excellent."
>
> — Director, Client Service Delivery Management, enterprise SaaS, public G2 review

## How do I measure whether the customer success playbook is being run?

Two numbers measure whether a customer success playbook is being run, and completion rate is neither of them. The first is the fire-to-open rate: the share of plays a CSM opened within the window the play was designed for. The second is the ghost play rate: the share of completed plays that changed nothing in the account within 30 days. A team can score 95% on completion and 90% on ghost rate, and that combination is the most common failure we see.

**The ghost play rate**

```
Ghost play rate = Completed plays with no account change in 30 days ÷ All completed plays × 100
```

Where:
- Account change: a customer reply, a meeting booked, a ticket closed, a usage movement, an expansion conversation or a written risk. Something another person could verify without asking the CSM
- 30 days: the window after the play was marked complete, not after it fired. A play that sat for three weeks is measured from the day the work was done
- What good looks like: under 30%. Above 60% the play is being processed instead of run, and the fix is to retire it, not to chase the team on completion

| Fire-to-open | Ghost play rate | What it means | What to do |
| --- | --- | --- | --- |
| High | Low | The play works and the team runs it | Leave it alone and copy its trigger into the next play you write |
| Low | Low | The play works when it is run, and the team cannot reach it | Coverage or timing problem. Cut the volume of other plays before touching this one |
| High | High | The team is clearing the queue and the plays do nothing | Retire the play. Completion is measuring compliance, and compliance is what you get |
| Low | High | Nobody runs it and it would not matter if they did | Delete it this week. Every dead play in the queue makes the live ones harder to see |

No trustworthy public benchmark exists for play completion, play outcome rates or process adoption inside customer success teams. Every figure we found circulating was a vendor blog with no sample, no field dates and no definition, several repeating the same numbers in the same wording. Measure your own baseline in the first month, publish it, and compare the playbook against itself from then on. That is a better number than anything you can cite.

> "It can be difficult to create buy-in, drive adoption and change behaviors of CS team members."
>
> — Enterprise reviewer, public G2 review

**Before you blame the team**
- [ ] Somebody has counted the plays that fired per CSM last month, from the tool export, not the design document.
- [ ] Five plays have been timed end to end with a stopwatch, including the time spent finding the data.
- [ ] Play load is under 60% of the proactive hours a CSM has after meetings, inbound and escalations.
- [ ] Every live play has a change trigger and not a date trigger.
- [ ] Step one of every play can be completed alone in five minutes.
- [ ] Each play names the decision the CSM may take without asking, and who approves the rest.
- [ ] Each play has a written failure exit, so no task can end with nowhere to go.
- [ ] The ghost play rate has been measured once and is on the same report as completion.
- [ ] At least one play has been retired in the last two quarters.

## What if CSMs still will not run the playbook after a rewrite?

A playbook that stays unrun after a rewrite has a coverage problem or an ownership problem, and neither is fixed by more plays. Coverage is the simpler of the two: run the play load formula again, and if the answer is still above 100% the team is not ignoring the playbook, it is triaging an impossible queue in the only way available. Cut the tier, cut the plays, or add people.

Ownership is harder. Plays that ask a CSM to carry work another function is accountable for (a pricing decision, a product commitment, a support backlog) fail in a way that looks like defiance and is not. One practitioner with 20 years in pre-sales and post-sales described being asked to maintain a parallel list of action items that already existed in three other places.

> "I told him I've been doing this for 20 years now, in presales and post sales and I haven't ever in my entire career worked this way, and at worst I had to do something similar for larger deals or risky renewals."
>
> — r/CustomerSuccess, 2024

There is a third case worth naming, because teams spend quarters on it: the playbook is running correctly and the number it was meant to move is not moving. One team on r/CustomerSuccess in 2026 described rebuilding kickoff calls, adding touchpoints and tightening response times against an onboarding churn problem, and finding that none of it touched the outcome until they changed what sales handed over.

> "We tried fixing all of that. Better playbooks, more touchpoints, faster response times. None of it moved the number."
>
> — r/CustomerSuccess, 2026

If the plays run and the outcome stays flat, the cause sits upstream. [What should be on the sales to customer success handoff checklist](https://gaintrace.com/explore/onboarding/sales-to-customer-success-handoff-checklist) covers the handover version of that problem, [how do I move to proactive customer success with a reactive team](https://gaintrace.com/explore/retention/proactive-customer-success-for-a-reactive-team) covers the version where the team never gets ahead of inbound, and if the plays exist but the tool they live in is the thing being avoided, [why is customer success platform adoption so low among CSMs](https://gaintrace.com/explore/customer-success/customer-success-platform-adoption-csms-back-to-spreadsheets) is the page for that, because tool adoption and process adoption fail for different reasons and need different fixes.

> "Set up is pretty complicated and without solid buy-in from the team and good data it would be easy to let this amazing tool end up on the sideline."
>
> — Mid-Market reviewer, public G2 review

## How does GainTrace decide which play to run?

GainTrace fires a play when an account changes, not when a date arrives. The play opens with the evidence that triggered it, so the first step is the work instead of the research. It connects billing, CRM, product usage and support, watches each account against its own baseline, and keeps the queue short enough to clear. [Playbooks and flows](https://gaintrace.com/platform/playbooks) covers how a play is built and retired, and [triage](https://gaintrace.com/platform/triage) shows the ordering the team sees each morning.

## Frequently asked questions

### Why do CSMs ignore the playbooks we built?

Because running the play costs more than skipping it and nobody checks either way. The common design faults are a calendar trigger that fires at the wrong moment, a first step that needs a data pull or an approval, no authority attached to the recommendation the play ends in, and a report that measures completion instead of what changed on the account.

### How many plays should a customer success playbook have?

Six to nine live plays is the ceiling most teams hold, though the honest answer comes from arithmetic, not a rule. Count the plays that fired per CSM last week, multiply by the median minutes each takes end to end, and divide by the proactive hours a CSM has after meetings and inbound. Above 100% the playbook is asking for time that does not exist.

### What is a playbook in customer success?

A play is a named sequence of steps with a trigger, an owner, a decision the owner may take, and a defined end. A customer success playbook is the set of those plays a team runs: onboarding, a usage drop, a champion leaving, a renewal, an expansion signal, a save. The set is the playbook; the individual sequence is the play.

### Should playbook completion be a CSM KPI?

No. Completion measures whether a task was closed, and a task can be closed in a batch on a Friday with nothing sent. Measure the ghost play rate instead: the share of completed plays that produced no reply, no meeting, no ticket and no usage movement within 30 days. Publish both numbers on the same report so completion cannot be gamed alone.

### How do I get CSMs to buy into a new process?

Have two of them build it on live accounts before it ships, and give whoever ran it the authority to change a step without a committee. Buy-in arrives when the play arrives with the evidence that triggered it, the first step can be done alone in five minutes, and the CSM can make the decision the play ends in without asking permission.

### Is there a benchmark for playbook adoption in customer success?

No trustworthy public figure exists. Every number we found circulating came from a vendor blog with no sample size, no field dates and no definition of what counted as adoption, and several repeated identical ranges in identical wording. Measure your own fire-to-open and ghost play rates in month one, publish the baseline, and compare the playbook against itself from then on.

## How this was researched

We read 4,978 public G2 reviews of customer success platforms in September 2026 and isolated the 432 (8.7%) that mention a playbook and the 329 (6.6%) that mention CTAs, grouping every complaint about volume, relevance and rigidity by cause. We then read 33,600 Reddit posts from r/CustomerSuccess, r/SaaS, r/sales and r/startups dated May 2024 to September 2026, of which 194 mention a playbook and 58 mention one alongside CSMs. No public benchmark exists for playbook completion, play outcome rates or process adoption inside CS teams, and the page says so instead of citing one. The seven-cause taxonomy, the ghost play rate, the play load formula and the redesign order are our own analysis; the worked example uses illustrative figures.

## Sources

- [r/CustomerSuccess: Success Plans, does anyone read them or care?](https://www.reddit.com/r/CustomerSuccess/comments/1ucf11l/)
- [r/CustomerSuccess: My VP wants an action plan for every customer, which is a waste of time](https://www.reddit.com/r/CustomerSuccess/comments/1fhigvu/)
- [r/CustomerSuccess: We fixed our onboarding churn by changing one thing in the sales to CS handoff](https://www.reddit.com/r/CustomerSuccess/comments/1sx31eb/)
- [r/CustomerSuccess: What is the most annoying part of customer success that nobody talks about?](https://www.reddit.com/r/CustomerSuccess/comments/1uqzk12/)
- [r/startups: How are you handling guided selling when onboarding new reps constantly?](https://www.reddit.com/r/startups/comments/1tp2gu2/)
- [r/CustomerSuccess: CS Managers, what is still the hardest part of your job?](https://www.reddit.com/r/CustomerSuccess/comments/1mr02t5/)

## Next steps

Export last month's plays, time five of them, and work out your play load before you write another one. [Start free](https://app.gaintrace.com/auth/login) or [book a demo](https://gaintrace.com/booking).