> ## Documentation Index
> Fetch the complete documentation index at: https://docs.forge.shieldtp.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Create and use runbooks

> Turn repeatable helpdesk procedures into testable organization- or account-specific guidance.

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

<Steps>
  <Step title="Define the trigger">
    Describe which tickets the runbook applies to and, just as importantly, which it does not.
  </Step>

  <Step title="State prerequisites">
    Name required context, access, mappings, customer approvals, maintenance windows, and stop conditions.
  </Step>

  <Step title="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.”
  </Step>

  <Step title="Define boundaries">
    State when to ask a person, hand off, avoid a write, or escalate. Include account-specific exceptions.
  </Step>

  <Step title="Test in Studio">
    Use representative tickets, including edge cases. Review the plan, selected tools, evidence, and handoff behavior.
  </Step>

  <Step title="Activate deliberately">
    Keep the runbook in draft while it changes. Publish or activate it only after the owner accepts the tested behavior.
  </Step>
</Steps>

## 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.

<Tip>
  A runbook is not just a prompt. Treat it as an operational procedure with an owner, test cases, change history, and explicit failure behavior.
</Tip>

For reusable guidance outside the helpdesk lifecycle, use [Skills](/knowledge/skills).