Template: CS next action

Recommend the next action a customer-success team should take on an account, grounded in the account's own signals, and hand off the ones that need a person. This page is one of the use-case templates — a starting point, not a finished route. The machine-readable source is node_modules/modelrig/templates/cs-next-action.json.

Does this task fit?

CS next-action fits the shipped teach → calibrate → grade → optimize loop when four conditions hold. (1) Your accounts and playbooks are stable enough that a recommendation that made sense last quarter still makes sense this quarter. (2) Your CS team can write down what a good next action is for a given account state, which is the grading guide below. (3) An experienced CSM can grade a batch of past recommendations against what actually happened or what they would have done. (4) You manage enough accounts that calibration and optimization pay back. This template gives you an action taxonomy shell and a grading guide to fill in. It makes no claim that a model should decide account strategy — it is a starting point for turning your playbook into a graded, improvable route, with a human on the accounts that matter.

Starter schema

Replace every TODO with your own taxonomy; the enum slots ship without values on purpose, so an unfilled template refuses to look finished.

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$comment": "STARTER SCHEMA. Replace every TODO with your own playbook before use. Enum slots ship without values on purpose — add the actions and urgency levels your CS team actually uses.",
  "title": "CsNextAction",
  "type": "object",
  "additionalProperties": false,
  "required": [
    "recommended_action",
    "urgency",
    "needs_human"
  ],
  "properties": {
    "recommended_action": {
      "type": "string",
      "description": "The single next action to take on this account. TODO(enum): add an \"enum\": [ ... ] listing YOUR playbook actions (e.g. the plays your team already runs), so the model chooses from your set rather than inventing one.",
      "$comment": "TODO(enum): add your playbook actions as the enum for this field."
    },
    "urgency": {
      "type": "string",
      "description": "How soon the action should happen. TODO(enum): add an \"enum\": [ ... ] with YOUR urgency levels.",
      "$comment": "TODO(enum): add your urgency levels as the enum for this field."
    },
    "rationale": {
      "type": "string",
      "description": "One or two sentences naming the account signals that motivate the action (usage trend, support load, renewal date, sentiment). The grader checks that the rationale is grounded in real signals."
    },
    "needs_human": {
      "type": "boolean",
      "description": "True when the account is high-stakes or the signals are ambiguous and a CSM should decide. Pairs with the escalation band in the grading guide."
    }
  }
}

Starter grading guide

The starter criteria run as written — sharpen each one in your team's own words as you grade. They are in the exact jsonb shape the set_task_settings write path validates — binary checks, each with a one-sentence pass and fail. There is no pass_threshold here: that lives in the route's grade: block.

action-fits-signals — Action fits the account's signals

• Pass: the recommended action is the one your playbook calls for given the account's stage and signals.
• Fail: The action does not match the account state — a renewal push at onboarding, a nurture play on an account that is actively churning.

grounded-rationale — Rationale cites real signals

• Pass: The rationale names specific signals present in the account data rather than generic advice that would fit any account.
• Fail: The rationale is boilerplate, or cites a signal the account data does not contain.

stays-in-remit — Recommendation stays within CS remit

• Pass: the action is something CS can actually do; it does not commit pricing, contract terms, or promises outside the team's authority.
• Fail: The action oversteps — promising a discount, a roadmap commitment, or anything that needs another team's sign-off.

safe-default-when-unsure — Ambiguous accounts get a safe default or a human

• Pass: when the signals are thin or conflicting, the recommendation is a low-risk action or needs_human, not a confident high-stakes move.
• Fail: A high-stakes action is recommended on an account whose signals do not support it.

The guide's escalation band starts at epsilon: 0.1: a grade within that distance of the route's pass threshold is treated as judge-uncertain and sent to a human. It is a starting band — tune it as your grader calibrates.

Golden checklist

Roughly twenty examples that cover:

• One clear example per action in your playbook — the account state where that action is plainly right.
• The two or three account states your team most often disagrees on, so the guide learns your house rules.
• A high-value or at-risk account where the safe move is to hand off to a human — the golden shows needs_human set.
• A brand-new account with almost no signal yet — the golden shows a low-risk default rather than a confident play.
• An account whose signals point two ways (growing usage but falling sentiment) — the golden fixes which signal wins.
• A case where a tempting action would overstep CS remit — the golden shows it declined in favour of an in-remit action.
• Aim for roughly twenty goldens total, weighted toward the ambiguous and high-stakes accounts rather than the easy ones.

Escalation starter

Start by escalating to a human whenever the model sets needs_human, and always for your highest-value or clearly at-risk accounts regardless of the recommended action. The machine-side band lives in starter_guide.escalation.epsilon: a grade within that distance of your route's pass threshold is treated as judge-uncertain and routed to a CSM. The 0.1 here is a starting band — keep it wide until an experienced CSM has graded enough recommendations to trust the grader, then narrow it.

Apply it

By hand: replace the TODO action taxonomy with your own playbook actions and urgency levels; sharpen each starter criterion in your team's words, keeping the in-remit guard that stops the model committing pricing or contract terms; gather the goldens the checklist describes; set the escalation band.

From a coding agent: the template feeds through the tools that already exist — create_route drafts the route bundle from the starter schema (files only, never your source), and set_task_settings (the task-settings scope) authors the grading guide as-is — the starter criteria run as written; sharpen them to your own rules as you grade. No new tool is involved. See the use-case templates overview for the full two-path walkthrough.