Skip to main content
Runbooks capture how your organization handles a class of tickets. They give engineers and AI Engineer a shared procedure, make account-specific exceptions explicit, and create a reviewable path from draft guidance to controlled automation.

​
Choose the scope

Use an organization runbook when the procedure should apply broadly. Use an account runbook or account customization when a customer has different systems, contacts, maintenance windows, escalation rules, or other operational constraints. Avoid copying a broad runbook for every account. Keep the common procedure shared and record only the meaningful difference at account scope.

​
Build a useful runbook

1

Define the trigger

Describe which tickets the runbook applies to and, just as importantly, which it does not.
2

State prerequisites

Name required context, access, mappings, customer approvals, maintenance windows, and stop conditions.
3

Write observable steps

Each step should produce evidence a reviewer can inspect. Prefer “confirm the device is enrolled and record the last check-in” over “check the device.”
4

Define boundaries

State when to ask a person, hand off, avoid a write, or escalate. Include account-specific exceptions.
5

Test in Studio

Use representative tickets, including edge cases. Review the plan, selected tools, evidence, and handoff behavior.
6

Activate deliberately

Keep the runbook in draft while it changes. Publish or activate it only after the owner accepts the tested behavior.

​
Review and maintain

Use versions and diffs to understand what changed. Re-test after:
  • the PSA or a connected system changes;
  • a required tool or account mapping changes;
  • a customer procedure changes;
  • ticket outcomes reveal a recurring failure;
  • you expand from review-only to autonomous execution.
A runbook is not just a prompt. Treat it as an operational procedure with an owner, test cases, change history, and explicit failure behavior.
For reusable guidance outside the helpdesk lifecycle, use Skills.