Stage-Change Playbooks

Who this is for

Any team - or agent - running deals through a staged pipeline where "what happens next" currently lives in someone's head. The tell: ask two people what should happen when a deal reaches Proposal and you get two answers. Founder-led sales teams hit this the day rep number two starts; agent-operated CRMs hit it immediately, because an LLM has no tribal memory to fall back on.

Use it once you have a working pipeline (if not, start with the B2B SaaS pipeline template) and want stage moves to mean something operationally, not just visually on a kanban.

The principle: a stage move is an event, the playbook is what fires

Stages record buyer state; playbooks are your side of the contract. When a deal arrives in a stage, a defined set of things fires - always the same set, no matter who moved the card or which agent made the call. Three rules keep this sane:

• Playbooks trigger on arrival, not departure. One playbook per destination stage. Departure triggers double the rule count and break when a deal skips a stage. Relm's deal.stage_changed event fires whenever a deal lands in a stage - at creation and on every move made via API, MCP or the dashboard - and carries the deal after the change, so {"field":"stage","op":"eq","value":"proposal"} is arrival semantics for free.
• Every action must be one of four types. A human task (with a deadline in the title), a buyer-facing email, a field update, or an internal signal. If a proposed action is none of these, it is a process document, not a playbook.
• The playbook lives next to the deal. Not in Notion, not in onboarding docs, not in a rep's memory. In the CRM, as an automation the whole team - and every agent - executes identically.

The playbook matrix

For the canonical seven-stage pipeline (Lead, Qualified, Demo, Proposal, Negotiation, Won, Lost). Each row is what fires when a deal arrives in that stage. Adapt wording; keep the shape.

Deal arrives in	Human task	Buyer-facing email	Field update	Internal signal
Qualified	Send discovery recap, confirm budget owner, book demo - due in 48h.	- (recap is personal, send it by hand)	next_step = "Book demo within 48h"	-
Demo	Confirm the budget owner attends; prep one buyer-specific demo path.	Prep note: who to bring, what workflow to see live.	next_step = "Hold demo; ask for the proposal invite"	-
Proposal	Follow up on day 3 if silent; ask who else reviews the terms.	- (the proposal email itself is manual)	next_step = "Follow up on proposal by day 3"	-
Negotiation	Confirm the signer, send the order form, get a signature date on the calendar.	-	next_step = "Get signature date on calendar"	Email the deal desk: check pricing floor and approval chain now.
Won	Kick off onboarding handoff within 24h.	Welcome email - usually owned by onboarding, not sales.	-	Hand off to provisioning/billing/onboarding.
Lost	Record the loss reason within 24h - price, competitor, timing, no budget, went dark.	-	loss_review = "pending"; next_step = "Queue re-engagement at 90 days"	-

Two deliberate gaps. Arrival in Lead has no playbook - lead handling belongs to triage and outreach cadences, not to the deal pipeline. And Won is mostly cross-system: encode the CRM-side handoff task as an automation, then let an agent (or a scheduled job) watch for newly-Won deals via GET /v1/deals?stage=won and trigger provisioning and billing in your other tools. Lost deals closed for timing feed the re-engagement sequence later.

Rules for writing your own rows

• Tasks carry their deadline in the text. "Follow up" is noise; "Follow up on day 3 if silent" is a playbook.
• Automate the generic, keep the personal manual. A demo prep note is the same for every buyer - automate it. A discovery recap quotes the buyer's own words - a template would read as spam. The matrix marks these "-" on purpose.
• One next_step field, always overwritten. One text field every playbook overwrites means anyone - rep, founder, agent - sees the expected action at a glance, and a daily pipeline review can flag deals where it has gone stale.
• Actions must be safe to re-fire. Deals bounce back and re-enter stages. A duplicated task is annoying; a double-sent contract is a problem. Keep buyer-facing sends low-stakes.
• Do not chain playbooks through stage moves. In generic workflow engines, an automation that moves a deal into a stage with its own playbook starts a cascade. Relm rules cannot cascade by construction: a rule's actions write directly to the data layer and never re-emit trigger events, so a move_deal_stage inside a rule will not fire the destination stage's playbook. Either way, each playbook should fire from a human or agent decision, not from another rule.

The artifact: five automation rules (JSON)

Each element below is a valid body for Relm's POST /v1/automations - name, trigger_event, ANDed conditions of {field, op, value}, and an actions list using the built-in types create_activity, set_field and send_email. Prerequisites: the seven-stage pipeline above, deal custom fields next_step and loss_review (one POST /v1/fields call each), and a connected email key (POST /v1/connections, BYO Resend) for the two email actions. {{title}} interpolates from the triggering deal; in test mode, sends are simulated. Plan note: Free allows 2 active automation rules per mode and Pro allows 25, so on Free start with the two stages that leak the most deals.

[
  {
    "name": "Playbook: arrived in Qualified",
    "trigger_event": "deal.stage_changed",
    "conditions": [{ "field": "stage", "op": "eq", "value": "qualified" }],
    "actions": [
      { "type": "create_activity", "activity_type": "task",
        "body": "PLAYBOOK Qualified - {{title}}: send discovery recap, confirm the budget owner, book the demo. Due in 48h." },
      { "type": "set_field", "field": "next_step", "value": "Book demo within 48h" }
    ]
  },
  {
    "name": "Playbook: arrived in Demo",
    "trigger_event": "deal.stage_changed",
    "conditions": [{ "field": "stage", "op": "eq", "value": "demo" }],
    "actions": [
      { "type": "send_email",
        "subject": "Ahead of our demo",
        "body": "<p>Looking forward to it. Two things that make demos useful: bring the people who would use this day to day, and reply with one workflow you want to see live - we will build the session around it.</p>",
        "text": "Looking forward to the demo. Bring the day-to-day users and reply with one workflow you want to see live." },
      { "type": "create_activity", "activity_type": "task",
        "body": "PLAYBOOK Demo - {{title}}: confirm the budget owner attends; prep one buyer-specific demo path." },
      { "type": "set_field", "field": "next_step", "value": "Hold demo; ask for the proposal invite" }
    ]
  },
  {
    "name": "Playbook: arrived in Proposal",
    "trigger_event": "deal.stage_changed",
    "conditions": [{ "field": "stage", "op": "eq", "value": "proposal" }],
    "actions": [
      { "type": "create_activity", "activity_type": "task",
        "body": "PLAYBOOK Proposal - {{title}}: follow up on day 3 if silent; ask who else reviews the terms." },
      { "type": "set_field", "field": "next_step", "value": "Follow up on proposal by day 3" }
    ]
  },
  {
    "name": "Playbook: arrived in Negotiation",
    "trigger_event": "deal.stage_changed",
    "conditions": [{ "field": "stage", "op": "eq", "value": "negotiation" }],
    "actions": [
      { "type": "send_email", "to": "[email protected]",
        "subject": "Negotiation: {{title}}",
        "body": "<p>{{title}} just entered Negotiation. Check the pricing floor, approval chain and paper process now - not after the buyer asks.</p>" },
      { "type": "create_activity", "activity_type": "task",
        "body": "PLAYBOOK Negotiation - {{title}}: confirm the signer, send the order form, get a signature date on the calendar." },
      { "type": "set_field", "field": "next_step", "value": "Get signature date on calendar" }
    ]
  },
  {
    "name": "Playbook: arrived in Lost",
    "trigger_event": "deal.stage_changed",
    "conditions": [{ "field": "stage", "op": "eq", "value": "lost" }],
    "actions": [
      { "type": "create_activity", "activity_type": "task",
        "body": "PLAYBOOK Lost - {{title}}: record the loss reason (price / competitor / timing / no budget / went dark) within 24h." },
      { "type": "set_field", "field": "loss_review", "value": "pending" },
      { "type": "set_field", "field": "next_step", "value": "Log loss reason; queue re-engagement at 90 days" }
    ]
  }
]

The Won handoff is intentionally absent from the in-CRM rules: run an agent (or a scheduled job) that polls GET /v1/deals?stage=won and drives onboarding and billing in your other tools, so cross-system work reacts to the move without living in the CRM. For more single-purpose rules beyond stage moves, see the 10 CRM automation recipes.

Apply it with your agent

If your agent speaks MCP, point it at https://api.relmcrm.com/mcp with a bearer key and paste:

Connect to the Relm MCP server. Then:
1. Call relm_describe_schema and check my default pipeline's stage keys.
   The rules below expect qualified, demo, proposal, negotiation, won,
   lost. Add any missing stages with relm_manage_stage, or adapt the
   condition values below to my keys.
2. Create deal custom fields next_step (text) and loss_review (text)
   with relm_create_field if they do not already exist.
3. Create the five automations from the JSON above with
   relm_create_automation, one rule per element, keeping names, triggers,
   conditions and actions exactly as written. Replace
   [email protected] with my inbox. If I hit my plan's automation
   limit, create the Proposal and Lost rules first and tell me.
4. List all automations and read each back so I can verify.
Run on my test key first; only repeat on live after I confirm.

Over REST, create the fields once, then POST each rule. Rehearse with a relm_test_ key - test mode is free and invisible to live data - then re-run with relm_live_:

curl https://api.relmcrm.com/v1/automations \
  -H "Authorization: Bearer relm_test_..." \
  -H "Content-Type: application/json" \
  -d '{"name":"Playbook: arrived in Qualified","trigger_event":"deal.stage_changed","conditions":[{"field":"stage","op":"eq","value":"qualified"}],"actions":[{"type":"create_activity","activity_type":"task","body":"PLAYBOOK Qualified - {{title}}: send discovery recap, confirm the budget owner, book the demo. Due in 48h."},{"type":"set_field","field":"next_step","value":"Book demo within 48h"}]}'

An unknown trigger_event or action type returns the valid options in the error body, so an agent self-corrects in one retry. Full reference in the docs; if the agent is new to operating a CRM end to end, start with what a CRM for LLMs is.

FAQ

What is a stage-change playbook?

A fixed, written answer to "a deal just moved to stage X - now what?" It names the human task, the buyer-facing email, the field update and the internal notification that fire on that move, and it lives in the CRM as an automation rule, not in a rep's head. If the answer differs depending on who you ask, you have tribal memory, not a playbook.

Should playbooks trigger on entering or leaving a stage?

On arrival. Trigger on the stage-change event and match the destination stage - one playbook per stage the deal lands in. Departure triggers double your rule count and create ambiguity when a deal skips stages. In Relm, deal.stage_changed carries the deal's state after the move, so a condition like stage eq proposal is exactly arrival semantics.

How do I stop stage-change automations from firing twice or looping?

Three habits: match only the destination stage so each rule fires once per arrival; keep stage moves out of a playbook's own actions - a move should come from a human or agent decision; and keep each action safe to repeat - a task with a clear title and a field set to a fixed value do no harm on a re-fire. In Relm, rule actions write directly to the data layer and never re-emit trigger events, so one rule can never fire another - rule-to-rule loops are impossible by construction.

What should fire when a deal is Won?

Mostly things outside the CRM: provisioning, billing, an onboarding kickoff. Encode the CRM-side pieces (handoff task, internal announcement) as an automation, then let an agent or a scheduled job watch for newly-Won deals via GET /v1/deals?stage=won and drive that work in your other tools. Won is the one transition where the important actions happen outside the CRM.

Can I use these playbooks without Relm?

Yes. The matrix is CRM-agnostic - implement each row as a HubSpot workflow, a Pipedrive automation, or a Zapier trigger on stage change. The five JSON rules map one-to-one onto any engine with a trigger-condition-action shape. Relm is simply the fastest path: five POST /v1/automations calls, or one paste into an MCP-connected agent. The Free plan includes 1,000 requests a month and 2 active automation rules - enough to pilot your two highest-leverage stages; Pro raises the cap to 25.