Every customer success team has motions it runs again and again: saving an account that has gone quiet, following up on an expansion signal, nudging a stalled onboarding, preparing for a renewal. In many teams those motions live in people's heads or in a slide deck nobody opens. Each CSM runs them a little differently, and some accounts never get them at all.
A CS play fixes that by turning a motion into something you define once and run on every account that needs it. This guide explains what a play is, the three parts every play needs, how plays relate to workflows and action queues, and how to design the four core plays most post-sales teams rely on.
What Is a CS Play?
A CS play is a named, repeatable motion with three parts: a trigger that decides when it starts, a set of steps that decide what happens, and a channel that decides how each step reaches the customer or your team. Quivly's Plays page puts it simply: write the motion once, then run it on every account.
Common examples include:
- Rescue: a churn signal starts a save play, with the reason attached, before renewal.
- Expansion: usage and buying signals route an expansion play to the person who owns the account.
- Onboarding: a stall triggers a nudge, a check-in or an escalation.
- Renewal: a fixed cadence of touchpoints leading up to the renewal date.
The word "playbook" is often used for the same idea. In practice, a playbook is usually a collection of plays, and each play is a single motion you can name, run and measure.
Plays vs. workflows vs. action queues
Three terms get mixed up constantly, and separating them makes plays easier to design.
- The play is the motion. It is the thing you name and reuse, such as "Sponsor re-engagement" or "New seats: approval loop."
- The workflow is the machinery underneath. Quivly describes workflow automation as the graph that runs a play: the trigger, the account lookup and the action.
- The action queue is today's work. Quivly's Actions Feed is the list of play runs waiting on a person, with the draft already written.
Put another way, the play is the recipe, the workflow is the kitchen equipment, and the action queue is the list of orders waiting to go out. When you design a play, focus on the motion first. The plumbing can follow.
Part 1: The Trigger
The trigger is the condition that starts a play. A good trigger is specific, measurable and tied to a moment where action actually changes the outcome. Common trigger types include:
- Health movement: an account's health score drops into a lower band or falls a set number of points in a short period.
- Usage changes: a usage stall, a drop in weekly active users or, on the positive side, an account approaching a seat limit or usage tier.
- Calendar windows: a renewal date approaching or an onboarding milestone coming due.
- Relationship and market signals: a champion leaving, a new stakeholder appearing or news about the customer's company.
- Manual starts: someone on the team decides an account needs the play now.
Write triggers you can test
"Account seems unhappy" is not a trigger. "Seat utilization crosses 85%" is. That example comes from Quivly's description of a typical expansion play, and it works because anyone can check whether it fired correctly. Make every trigger a condition you could verify against your data.
Attach the reason
When a play starts, the person who sees it should know why. A rescue play that says "health dropped because there have been no calls or Slack messages in 30 days" gets a faster, better response than one that just says "at risk."
Part 2: The Steps
Steps are the actions the play takes after it starts, in order. Most plays follow a similar shape:
- Gather context. Look up the account record, health score, recent calls and open support tickets so every later step is grounded in facts.
- Reach out. Draft the first message to the customer or an internal heads-up to the account owner.
- Create follow-up work. Open a task, such as asking the AE to prepare an upgrade proposal or logging an at-risk task in the CRM.
- Escalate if needed. Route to an AE, team lead or executive sponsor when the account is large or the first steps don't land.
- Close the loop. Record the outcome so you can see which plays actually work.
Keep plays short
The example plays on Quivly's page run two to four steps each. Short plays are easier to trust, easier to measure and easier to fix. If a play needs ten steps, it is probably two plays.
Add conditions for high-value accounts
Not every account needs the same treatment. Quivly's example expansion play adds an executive business review invite only when the account is above a revenue threshold. Branching on account value keeps strategic accounts high-touch without making every play complicated.
Part 3: The Channel
The channel is how each step reaches its audience. The same message can land very differently depending on where it shows up. Typical channels include:
- Email for customer-facing outreach, ideally sent from the CSM's own inbox so it reads as personal.
- Slack for internal alerts to a team channel, or for customer conversations where you share a channel.
- In-app messages for product nudges, such as prompting an upgrade when an account approaches a usage tier.
- Calendar invites for check-ins, renewal calls and executive syncs.
- CRM tasks for work that needs an owner and a due date.
Match the channel to the moment. A usage nudge fits naturally in the product. A rescue conversation with an executive sponsor belongs in email or on a call. An internal "this account needs attention" note belongs in Slack or the CRM, not in the customer's inbox.
Four Core Plays and How to Design Them
Rescue
Trigger: health falls into your lowest band, or a sharp drop in usage or engagement. Steps: alert the owner with the reason, draft a sponsor re-engagement email, open an at-risk task and escalate to the AE or executive sponsor for large accounts. Channel: Slack for the internal alert, email for the customer. For a framework on which accounts belong in each band, see how to segment accounts by health.
Expansion
Trigger: an account approaches a seat limit, usage tier or feature ceiling, or shows buying signals such as new stakeholders. Steps: send a personalized note that references the account's actual usage, task the AE with a proposal and invite larger accounts to a business review. Channel: in-app and email for the customer, CRM for the AE handoff.
Onboarding
Trigger: a new account falls behind on an onboarding milestone. Steps: start with a light nudge, follow with a check-in and escalate if the stall continues. Channel: in-app or email for the nudge, a calendar invite for the check-in.
Renewal
Trigger: time to renewal. Quivly's renewal plays use a 90, 60 and 30 day cadence. Steps: one simple split is to review health at 90 days and confirm the stakeholders, hold a value review at 60, and confirm terms and resolve open issues at 30. Channel: email and calendar, with internal CRM tasks at each stage.
Automate or Review? Deciding Who Sends Each Step
Plays don't have to be all-or-nothing automation. The most practical approach is to decide, step by step, which actions run on their own and which wait for a person.
- Automate low-risk, high-volume steps, such as an in-app upgrade nudge or an internal Slack alert.
- Review anything customer-facing on a strategic account, anything involving pricing and anything sensitive, such as a message to a departing champion.
In Quivly, drafts stay in review unless you have allowed an AI Agent to send that step. The example plays log shows both side by side: an in-app nudge marked as automated, and a finance approval draft for new seats marked as needing approval. Start with more steps in review, then automate the ones your team consistently sends unchanged.
How to Launch Your First Play
- Pick one motion your team already runs. Rescue is usually the best place to start because the cost of missing it is highest.
- Write the trigger as a testable condition. Check it against recent accounts to see whether it would have fired at the right time.
- Limit it to two to four steps, each with a clear channel and owner.
- Keep customer-facing steps in review for the first few weeks.
- Measure outcomes per play. Track saves, expansions and renewals tied to each play so you know which ones to scale and which to rework.
FAQ
A play is a single named motion with a trigger, steps and a channel. A playbook is typically a collection of plays covering a stage of the customer lifecycle or a type of account. Designing at the play level keeps each motion small enough to run and measure.
Fewer than most teams expect. Rescue, expansion, onboarding and renewal cover the core of post-sales work. Add new plays only when you see a repeated situation that none of the existing ones handle well.
Some steps should. Internal alerts and low-risk nudges are good candidates for automation, while customer-facing messages on important accounts usually benefit from a quick review. Decide per step rather than per play.
Track the outcome of every run: whether the account recovered, expanded or renewed. Comparing results across plays shows which motions drive revenue and which need a better trigger or different steps. Ready to write your motions once and run them on every account? See how Quivly's Plays start rescue, expansion, onboarding and renewal motions the moment a signal hits, with drafts ready for review before anything sends.
