Reply playbooks
Reply playbooks provide Inbox guidance for scenarios and sequence rules.
A reply playbook is guidance for Inbox replies. It records a scenario, tone, value proposition, sequence rule, and enforcement rule so a team can handle a recurring reply situation consistently.
Manage Playbooks at /dashboard/settings/playbooks. A reply playbook is not a catalog play, blueprint, or recipe: it guides replies rather than installing a system or creating a worksheet kit.
What a reply playbook contains
| Guidance | How it helps |
|---|---|
| Scenario | Identifies the reply situation. |
| Tone | Sets the voice of the response. |
| Value proposition | Keeps the intended value clear. |
| Sequence rule | Connects the guidance to sequence behavior. |
| Enforcement rule | States the rule the guidance should follow. |
Inspect guidance before replying
Start with the incoming message and the reply playbook that matches its scenario. Check the tone, value proposition, sequence rule, and enforcement rule against the actual conversation before drafting a response.
When it goes wrong
If no card matches, do not force a nearby scenario onto the conversation. Record the gap for the team, then create or update guidance only after you have checked the current card and the intended rule.
A card can guide a reply only when its scenario still matches the real conversation. If the thread has changed, preserve the actual customer context and report the mismatch rather than using a rule written for a different situation. Review the selected card, sender identity, thread, and workspace policy before you retain, revise, or replace guidance. The saved card should explain the resulting rule clearly.
If no card matches, report the gap. Do not force a nearby scenario onto the conversation, because that makes a card look like evidence when it is only guidance for a different case.
Before changing a card, read the existing scenario, tone, value proposition, sequence rule, and enforcement rule. Save a focused change, then read the card again in Settings.
If another editor changed the guidance, preserve the current card and merge the requested rule deliberately. A duplicate card with almost the same scenario makes future selection less reliable.
If the conversation or sender identity is unavailable, state that limitation and read the relevant Inbox state. Do not claim a draft was delivered or that an external provider received a message.
A completed drafting workflow shows the selected card, conversation, and draft in the appropriate app surface. A completed send workflow has the separate send receipt and provider result.
When guidance and the thread conflict, follow the real conversation and workspace policy, then record the playbook gap for later review. Do not change a customer-facing message merely to make a stale card appear correct.
Review the card with the actual thread before saving a revision. The visible scenario and rule give the next teammate a reason for the guidance rather than an unexplained text template.
Draft from the right card
A reply playbook is workspace-scoped Inbox guidance. It helps a team handle a recurring conversation situation consistently without turning guidance into an automatic send.
The scenario identifies the conversation situation. Read the actual incoming message before choosing a card, because a similar phrase can belong to a different customer context or sequence state.
Tone defines how the reply should sound. It guides a draft, but the existing thread and the workspace’s current Context remain the evidence for what the response can truthfully say.
The value proposition records the relevant promised value. Check it against the conversation and product facts instead of pasting it into every response regardless of the sender’s question.
The sequence rule keeps an Inbox reply connected to sequence behavior. A reply in an existing conversation is different from net-new outreach, and a reply ends the lead’s run.
The enforcement rule states the constraint the guidance should follow. Keep that rule visible while drafting so a helpful response does not quietly violate a workspace policy.
Manage Playbooks at /dashboard/settings/playbooks. Confirm the active workspace before changing a card, because playbook cards are not global personal notes.
A reply playbook is not a catalog play or blueprint. Catalog plays are advisory ordered capability plans, and blueprints are installable workspace systems.
Read the matching card and the message thread before drafting. The correct success signal is a draft that follows the card and conversation, not a generated sentence with no link to the scenario.
Drafting is an internal preparation action. It does not send a message, and it should leave the user able to inspect the text, recipient, conversation, and rule before any distinct send action.
Treat sending as separate
A live send reaches a real person and is irreversible. Treat the thread, sender identity, message text, and provider state as facts to check at the send surface rather than as implied by a card.
Architect can use the inbox-replies skill for practice, then discover the exact Unibox capability contract for reads, classification, drafting, or sending. A skill grants no tool authority.
A mutating capability names a mode; the server never defaults to live. Use dry_run where the exact capability supports it to inspect an action against workspace state without an outward effect.
Card guidance has no independent credit cost. The cost policy belongs to the selected capability, and a paid live capability can return a quote that must be rerun with unchanged parameters and max_credits.
Verify the draft before selecting a send capability. Guidance helps an agent prepare a reply, while a real delivery is a separate external effect with its own contract and result.