Playbooks

Operational playbook collection for agent products — customer success, onboarding, expansion, churn save, internal support. Each piece is a standard operating procedure for a specific role under specific trigger conditions.

Task completion drops 2-3 weeks before login frequency

Agent product early churn signals surface 2-3 weeks before SaaS equivalents — task completion rate drops typically precede login frequency drops. Operations teams monitoring only login frequency, the SaaS habit, see the signal only when the customer is already preparing to leave.

Agent product playbooks therefore must be reworked in three places:

  • Trigger conditions use agent-specific signals (task completion rate, HITL intervention rate, workflow count) rather than generic usage
  • Intervention actions include product-side adjustments (recommend appropriate tasks, adjust tier) rather than purely sales conversations
  • Measurement metrics align with the three-layer framework in metrics/overview

Five core playbooks

Customer onboarding playbook

30-day milestones from contract signing to first successful task. The most critical playbook — “activation quality” determines downstream retention. See onboarding.

Expansion playbook

Trigger conditions and processes for expanding activated customers to more seats, workflows, capacity. Built on the three expansion paths in growth/expansion. See expansion.

Churn-save playbook

Early signal identification and intervention strategy for declining usage. Agent product churn signals appear 2-3 weeks earlier than SaaS — task completion rate drops typically precede login frequency drops. See churn-save.

Internal support runbook

Standard ticket-handling procedures; escalation criteria to engineering. Agent product ticket categories include types SaaS lacks: “agent output error”, “task stuck”, “bill far higher than expected”. See support-runbook.

Incident response playbook

External communication templates for system-level failures (inference errors, token exhaustion, upstream model unavailability). See incident-response.

Writing convention

Every playbook should contain five fixed sections:

  1. Trigger conditions — when this playbook activates (specific metric thresholds, not vague “user activity declining”)
  2. Roles and responsibilities — who executes which step (customer success, sales, support, engineering boundaries)
  3. Operational steps — chronological action list, each step with completion criterion
  4. Escalation path — when to escalate to the next layer (sales manager, CS lead, engineering lead)
  5. Measurement metrics — what metrics to evaluate success after executing this playbook

Playbooks are not case studies. Each is a directly executable operating procedure for frontline operations under specific trigger conditions — written closer to SOP than to narrative.

Cross-section connections

Was this page helpful?