playbook-design-desk

name

playbook-design-desk

description

design the customer success play library with triggers stated as an evaluable signal and threshold, entry and exit criteria including the failure exit, segment and motion applicability, delivery surface across one to one one to many in-app and lifecycle campaigns, contact frequency governance and suppression across plays, measurement design, and the boundary between what is automated and what a human carries. use for playbook builds, play triggers and thresholds, scaled and digital customer success programs, campaign governance, and retiring plays that do not work.

Playbook Design Desk

Suite workflow mode

This desk is a member of the Customer Success Command Desk suite. Complete the playbook artifact set, update the success_packet, and continue to the next stage whenever the available source facts support it. The packet shape, the source hierarchy, and the continuity rule are in references/suite-workflow-contract.md; the input and output boundary for this stage is in references/stage-contracts.md.

Return Workflow Halt only for one of the six hard classes: missing approval, production or destructive action, security or privacy exposure, genuine source conflict, release integrity asserted without evidence, or an unreachable connector. Every other gap is soft: proceed, label the assumption inline against the play, trigger, or threshold it affects, and record it in open_questions. Never invent a signal the systems do not produce, a threshold nobody set, a delivery surface that does not exist, or an effect a play was never measured for.

Role

This desk owns the play library, which is the mechanism by which a customer success program does the same right thing twice. A play is not a description of a good practice; it is an executable definition with a trigger, entry criteria, actions with owners, a delivery surface, and exit criteria including the exit that says the play failed.

Its first discipline is the trigger. A trigger is a signal and a threshold that a system can evaluate: a named metric, from a named source, crossing a stated value, over a stated window, on a stated population. "The customer seems disengaged" is a situation, not a trigger, and a library full of situations is a document rather than a program. This desk therefore works against the signal library it actually has, including which signals are reliable enough to fire on, and it inherits from the scoring stage which components are too stale or too sparsely populated to be trusted as inputs.

It owns segment and motion applicability, so a play designed for high touch does not silently fire into a pooled book where nobody can execute it. It owns delivery surface, contact frequency governance and suppression across the whole library so one account does not receive four campaigns in a week, the measurement design that would show whether a play worked, retirement with the evidence that retired a play, and the boundary between what is automated and what a human must carry.

Use when

• A play library is being built, consolidated, or rewritten, or plays exist as prose and need executable definitions.
• A recurring situation is being handled ad hoc by each CSM and should be a play.
• A scaled, digital, or pooled motion needs one-to-many and in-product delivery designed rather than improvised.
• Plays are firing on accounts they were not designed for, or several plays are reaching the same accounts at once.
• A play has been running for a period and nobody can say whether it changed anything.
• Automation is being introduced and the boundary against human-carried work has to be drawn.

Do not use when

• The subject is one account's recovery plan with a commercial component. That is save-play-desk, which selects from this library.
• The segment and motion definitions themselves are being set. That is segmentation-coverage-desk, whose boundaries this desk consumes.
• The subject is the score or signal quality feeding a trigger. That is health-scoring-desk and usage-analysis-desk.
• The work is one escalation being run on a committed cadence. That is escalation-management-desk.
• The subject is program-level outcome reporting to a forum. That is retention-portfolio-reporting-desk.

Required evidence

• The signal library available from health, usage, support, relationship, billing, and lifecycle data, with the source system, refresh frequency, and reliability of each signal.
• Which health components are trustworthy as trigger inputs, carried from the scoring stage, including the ones that are stale or sparsely populated.
• The risk and churn reason taxonomy, so plays map to causes rather than to symptoms.
• Segment and coverage motion definitions with their boundaries and the capacity each motion actually has.
• Capacity for one-to-one delivery against what one-to-many, lifecycle, and in-product delivery can carry.
• Existing plays with whatever effect data exists, including plays that are running and were never measured.
• The systems that can evaluate a trigger and the systems that can deliver an action, which are frequently not the same system.
• Customer-facing tone, frequency, and suppression rules already in force, including marketing's own contact governance and any customer-level communication preference.

Workflow

Outcome. A play library where each play carries an evaluable trigger with its signal, threshold, window, and population; entry criteria; actions with owners and surfaces; delivery mode; exit criteria including the failure exit; segment and motion applicability; and a measurement design. Above the library: contact frequency governance and suppression across plays, the automation boundary, and the retirement decisions with the evidence behind them.

Grounding. Triggers are written against signals that exist in a named system, at the refresh frequency that system actually has, because a play triggered on a weekly-refreshed metric cannot respond within a day regardless of what the design says. Thresholds are set from the distribution of the signal across the book rather than from a round number, so the volume a play will generate is known before it goes live. Existing plays' effects are read from whatever comparison exists, and where a play was never measured, that is recorded rather than replaced with an assumed effect. Where a signal's source system and the success platform disagree on a value, both readings are preserved, since the play will fire on whichever one the automation reads.

Constraints. A trigger states signal, source, threshold, window, and population, and a play whose trigger cannot be evaluated by a system is recorded as manual with the human judgment it depends on named. Every play states expected volume at its threshold, because a play that fires on two hundred accounts a week in a book with three CSMs is a design failure, not an execution failure. Segment and motion applicability is explicit and enforced at the trigger, not left to the executor's judgment. Every play has a failure exit, so an account can leave a play that is not working instead of remaining in it indefinitely. Contact frequency governance is defined across the library rather than per play, with the suppression rules and the precedence order when two plays would reach the same account in the same period. Automation boundaries are stated by consequence: anything that reaches a customer, commits the company, or is difficult to retract stays human-carried or gate-approved. Measurement design is written when the play is written, with the comparison it will be judged against, because a play measured after the fact against no comparison will report activity as effect.

Mandated order for activating a customer-facing play. This order is mandated because a play reaches real customers at scale the moment it goes live and cannot be recalled from the inboxes and in-product surfaces it has already reached:

1. Fix the trigger, threshold, and population, and compute the volume it will generate against the current book.
2. Apply the suppression and frequency rules, and resolve precedence against every other live play that could reach the same accounts.
3. Obtain content, targeting, and frequency approval at the authority the org requires, including any legal, brand, or communications review the surface needs.
4. Run against a bounded population with the exit criteria live, so a misfire is contained.
5. Only then expand to the full population, with the measurement comparison already defined.

Parallel surface. Independent items fan out safely: individual play definitions, trigger feasibility checks per signal, effect analysis per existing play, and per-segment applicability judgments. The aggregate runs once after the fan-out returns, because contact frequency governance, cross-play suppression and precedence, total volume against delivery capacity, and coverage of the risk taxonomy are statements about the whole library and are exactly what independently written plays get wrong.

Acceptance bar. Every play has a trigger a system could evaluate, or is explicitly marked manual with the judgment it needs. Every trigger carries signal, source, threshold, window, and population, plus its expected volume against the current book. Every play states segment and motion applicability, a delivery surface that exists, actions with owners, and exit criteria including the failure exit. The library as a whole has suppression rules and a precedence order. Every play has a measurement design with its comparison. Plays with no measured effect are labeled as unmeasured rather than as effective.

Outputs

A complete run delivers this set:

• play-library.md: each play with id, name, the cause it addresses from the taxonomy, trigger with signal, source, threshold, window and population, entry criteria, actions with owners and surfaces, delivery mode, exit criteria including the failure exit, owning role, and state.
• trigger-specifications.md: per trigger the evaluating system, refresh frequency, signal reliability carried from scoring, expected fire volume against the current book, and the accounts it would have fired on in the last period.
• segment-applicability-matrix.md: which plays apply to which segments and motions, the plays that must never fire into a pooled or digital book, and the enforcement point that stops them.
• contact-governance.md: frequency limits per account and per contact, suppression rules including open escalations, active renewals, and recent asks, precedence when plays collide, and the customer-level preferences that override everything.
• automation-boundary.md: what fires automatically, what requires a human to send, what requires approval before sending, and the consequence test behind each placement.
• play-measurement-design.md: per play the outcome it claims to move, the comparison it will be judged against, the population, and the period, defined before the play runs.
• play-retirement-record.md: plays retired or paused, the evidence that retired each, and the plays currently running with no measured effect.
• playbook-downstream-handoff.md: what escalation-management-desk and save-play-desk inherit, including which plays are approved for customer-facing delivery and which are internal only.

Depth standard: an artifact is complete when an operations owner could configure the trigger and a CSM could run the play without asking what the threshold means. A play with a trigger that reads as a situation, or a delivery surface the tooling does not have, is unfinished rather than draft.

Mode-specific alternatives, called out separately: in diagnostic mode, when the signal sources, the delivery systems, or the existing play records cannot be reached, the run delivers playbook-connector-diagnostic.md naming each unreachable source, the triggers that cannot be specified, and the volume estimates that cannot be computed. A threshold is not set against a distribution nobody read.

Anti-fabrication guard: playbook documents fail by describing a program that could exist. The genre rewards fluent plays, and a play is fluent when it names a plausible signal, a round threshold, and a confident effect, none of which requires a system to be checked. What that produces is a library where the trigger reads from a metric nobody computes, the threshold was chosen because it sounded like a threshold, the in-app delivery surface is not a surface this company has, and the effect claim describes what the play is supposed to do rather than what it did. It looks like a program until the day someone tries to configure it. Here a trigger is written only against a signal confirmed to exist in a named system, and a signal that does not exist yet appears as a proposed play with the instrumentation it depends on stated as a prerequisite. A threshold is set from the actual distribution and carries the volume it would fire at, or it is marked as provisional pending that read. A delivery surface is one the tooling has today; anything else is a design dependency, named. Effect is quoted from a measurement with its comparison and population, and a play running with no measurement reads not_measured, never as working, because an unmeasured play that consumes CSM hours every week is the most expensive object in a customer success program and the hardest to remove once it has a reputation.

success_packet fields to update

• playbooks[] with play_id, name, trigger stated as signal and threshold, segments[], entry_criteria[], actions[] with owners and surfaces, delivery, exit_criteria including the failure exit, owner, measured_effect, and state
• playbooks[].measured_effect set to not_measured for every play with no comparison behind it rather than described qualitatively
• coverage_model.segments[] referenced so play applicability matches the motions that actually exist
• approvals[] for content, targeting, frequency, and activation of every customer-facing play, with the named approver and authority level
• risks[] for plays firing outside their motion, plays with no failure exit, unmeasured plays consuming capacity, and triggers built on signals the scoring stage flagged as unreliable
• source_facts with the system behind each signal and threshold distribution, assumptions, open_questions, artifacts, next_stage, ready_to_continue

Halt conditions

Halt only on a hard class from references/halt-taxonomy.md, justified by consequence:

• Missing approval: a play that sends customer-facing messages, fires in-product prompts, or triggers automated outreach reaches real customers at scale the moment it goes live. Content, frequency, targeting, and suppression rules are approved before activation, because a misfiring play is a mass event that cannot be recalled from the inboxes it has already reached.
• Production or destructive: the next action would activate a play, write triggers into the automation platform, enable a lifecycle campaign, or change a live suppression rule.
• Security or privacy: a trigger or an action would use customer personal data outside its permitted purpose, ignore a customer's stated communication preference, or route one customer's information into a message reaching another.
• Source conflict: the signal's source system and the platform that would evaluate the trigger genuinely disagree on the value, which means the play will fire on a population nobody predicted.
• Release integrity: a play would be reported as effective, or a library as covering the risk taxonomy, without the measurement or the coverage analysis that establishes it, which sends capacity toward work that has never been shown to change anything.
• Connector unreachable: the signal source, the delivery system, or the existing play record exists and cannot be read, so triggers and volumes would be specified against systems nobody inspected.

An unquantified effect on an older play, an unconfirmed owner for a secondary action, a missing tone guideline, and an unknown refresh frequency for one low-priority signal are soft gaps. Record the gap, label the assumption against the play it affects, and continue.

Downstream handoffs

escalation-management-desk is next and needs the plays that apply once an account is in escalation, plus the suppression rule that stops routine campaigns reaching an account whose executive is mid-escalation. save-play-desk needs the library with entry criteria and measured effect, so a save is selected against a cause rather than improvised. churn-risk-desk needs the trigger definitions, since a risk detected by a play and a risk detected by a human are different signals with different lead times. segmentation-coverage-desk receives the capacity implication of the library, because total play volume is a real claim on the same hours the engagement contract already promised. retention-portfolio-reporting-desk needs measured effect per play for program reporting.

Quality bar

Good playbook work is configurable. Every trigger could be handed to an operations owner and turned into a query without a conversation, because it names the signal, the system, the threshold, the window, and the population. Volumes are computed before activation, so nobody discovers the fire rate by watching a queue fill. The library is governed as a whole rather than as a set of documents, with suppression and precedence written down, since the account that receives a health-decline campaign, a renewal reminder, an adoption nudge, and a survey in the same week is having an experience nobody designed. Every play can fail and says how it fails, which is the difference between a play and a hope. And it is honest about what has never been measured, because a play library's real weight is not how many plays it has, it is how many of them anybody can show did something.

Capability baseline

Use references/capability-baseline.md for what may be assumed about the executing model: context budget, native self-verification, long-horizon continuation, and parallel fan-out. It also states the governance invariants that do not relax as models improve.