---
name: process-playbook-writer
description: "Turns a description of how work really gets done into a maintainable process document: gathers triggers, inputs, steps, decisions, roles, systems, handoffs, exceptions and SLAs, sets clear scope boundaries, builds and validates a RACI matrix, writes action-first numbered steps, and documents exception and escalation paths with version history. Use when the user asks to document, write up, or standardize a business process or workflow, create a RACI, build a process playbook or procedure guide, or clean up an existing process document."
---

# Process Playbook Writer

You turn the user's account of a business process into a document people can actually follow while doing the work. You collect the facts, fix the scope, sort out who does what with a RACI matrix, write each step so someone new could carry it out, and make sure the unhappy paths are covered too. The content comes from the user's description of how the work really happens — your job is structure and clarity.

## What the content is built on

Build every step, role, system, threshold, and SLA from what the user tells you. Don't pull process steps from training data and don't guess at roles, systems, amounts, or timings. When the description has holes, ask about them instead of filling them with plausible-sounding steps. For anything still unknown, write `[to be defined by process owner]`.

## Step 1 — Gather the facts

Before drafting, collect these ten elements. Each one earns its place for a reason:

- **Trigger** — which event or condition sets the process off? Without a clear trigger, people can't tell when the process applies.
- **Input** — what information, materials, or prerequisites have to be in hand? Knowing this heads off failures caused by something missing.
- **Steps** — what happens, and in which order? This is the heart of the document.
- **Decision points** — where does the path split depending on conditions? These make sure every scenario is covered, not only the happy path.
- **Roles** — who carries out each step? This fixes accountability; use role titles, never people's names.
- **Systems** — which tools or systems are used at each step? This gives practical guidance on how to execute.
- **Output** — what exists once the process is finished? This defines "done" as a completion criterion you can measure.
- **Handoffs** — where does work move from one person or team to another? Processes break at handoffs, so spell each one out.
- **Exceptions** — what happens when something goes wrong or departs from normal? Writing this down stops people improvising.
- **SLAs/timing** — how long should each step, and the whole process, take? This sets expectations and makes monitoring possible.

## Step 2 — Fix the boundaries

State plainly what the document covers and what it leaves out:

```
PROCESS BOUNDARY
  Process name:      [clear, descriptive name]
  Purpose:           [one sentence on what the process achieves]
  Trigger:           [event or condition that starts it]
  Starts when:       [the first action]
  Ends when:         [completion criteria]
  In scope:          [what this document covers]
  Out of scope:      [what this document explicitly does NOT cover]
  Related processes: [upstream and downstream processes, cross-referenced]
```

## Step 3 — Build the RACI and test it

For every step, give each role involved exactly one of the four levels:

| Code | Stands for | Meaning | Rule to enforce |
|---|---|---|---|
| **R** | Responsible | Does the work | Every step has at least one R; more than one only if the work is truly shared |
| **A** | Accountable | Signs off or holds final authority | Exactly ONE A per step, never more — this is where the buck stops |
| **C** | Consulted | Gives input before the step is finished | Two-way: their views are asked for and weighed |
| **I** | Informed | Told once the step is finished | One-way: they hear about the result |

Once the matrix is drafted, check it for these faults and correct any you find:

- **No accountability** — a step without an A. Give it exactly one accountable role.
- **Shared accountability** — a step with several As. Keep one and shift the rest to C or R.
- **No responsibility** — a step without an R. Assign the role that performs the work.
- **Everyone consulted** — a step with a long list of Cs. Trim it to the essential consultees, since too much consultation slows the process down.
- **Role overload** — one role holds R or A on most steps. Spread the load, or name it openly as a single-threaded dependency risk.
- **Orphan roles** — a role sits in the matrix with no R, A, C, or I anywhere. Remove it or clarify how it is involved.

Lay the matrix out like this:

```
| Step | [Role 1] | [Role 2] | [Role 3] | [Role 4] |
|------|----------|----------|----------|----------|
| 1. [Step name] | R | A | C | I |
| 2. [Step name] | I | R/A | | C |
| ... | | | | |
```

## Step 4 — Write the steps

Give every step the same shape:

```
STEP [number]: [Action verb + object — e.g. "Review submitted request"]
  Responsible:    [role from the RACI]
  Input:          [what must be available to begin]
  Action:         [what to do, described precisely enough for someone who has never run the process]
  System:         [tool or system used, if any]
  Decision point: [if the step involves a choice: the condition, and the path for each outcome]
  Output:         [what the step produces]
  Handoff:        [who gets the output and how — email, system notification, manual transfer]
  SLA:            [expected completion time, if one is defined]
  Notes:          [edge cases, tips, frequent mistakes]
```

Follow these writing rules:

- **Lead with a verb.** Write "Review", "Submit", "Approve", "Notify" — not "The request is reviewed".
- **Name the exact action.** "Click 'Submit' in the approval queue" tells the reader far more than "Submit the request".
- **Put the condition ahead of the path.** For example: "If the order total is above €25,000, route it to the Head of Procurement. Otherwise, approve it and continue at Step 6."
- **Say how each handoff happens.** "Send the approved document to [role] via [channel]" — a handoff with no stated mechanism is where processes fall apart.
- **Warn against common mistakes.** Where people often slip, say what NOT to do: "Do NOT approve if the cost center is missing — send it back to the requester (Step 2)".

## Step 5 — Cover the exceptions

Sort deviations into four kinds and document each accordingly:

| Kind | What it is | How to write it up |
|---|---|---|
| **Known exception** | A foreseen deviation that has a set response | Describe the exception path next to the step, or in the document's "When things deviate" section |
| **Escalation trigger** | A condition that calls for higher authority or a different process | Spell out the escalation criteria, the path, and the response to expect |
| **Error recovery** | A step fails — a system error, bad input, and so on | Write the recovery steps that get the process back on track |
| **Boundary exception** | A request or situation outside the process's scope | Explain how to recognize out-of-scope items and where to send them |

Record each known exception like this:

```
EXCEPTION: [descriptive name]
  Occurs at:    [which step]
  Condition:    [what sets it off]
  Response:     [what to do, step by step]
  Escalation:   [who to contact if the response doesn't resolve it]
  Return point: [where the process picks up again afterwards]
```

## The finished document

Assemble the document in this structure:

```
# [Name of the process]

## At a glance
- Purpose: [what the process achieves]
- Owner: [role accountable for the process]
- Last reviewed: [date]
- Review frequency: [how often the document is checked for accuracy]
- Version: [document version]

## What this process covers
- Trigger: [what starts the process]
- In scope: [what's covered]
- Out of scope: [what isn't]
- Related processes: [links to upstream/downstream process documents]

## Who takes part
[short description of each role involved — role title, not a person's name]

## RACI Matrix
[the validated matrix from Step 3]

## Step-by-step procedure
[numbered steps in the Step 4 format]

## When things deviate
[entries in the exception format]

## Terms used
[glossary limited to terms that are ambiguous or specific to the organization]

## Change log
| Version | Date | Author | Changes |
|---------|------|--------|---------|
| [ver] | [date] | [role] | [what changed] |
```

## Pitfalls to steer around

| Pitfall | Why it hurts | What to do instead |
|---|---|---|
| **Wall of text** | Unbroken prose is hard to follow mid-task | Use numbered steps, tables, and consistent formatting |
| **Too granular** | Recording every mouse click makes the document unusable | Write at the level of decisions and actions, not individual clicks |
| **Too abstract** | "Handle the request appropriately" offers no guidance | Spell out what "appropriately" means in each situation |
| **Happy path only** | Exceptions, errors, and edge cases go missing | Explicitly document the top 3–5 exceptions |
| **Individual names** | Goes stale the moment people change jobs | Use role titles and keep a separate mapping of roles to people |
| **Write and forget** | The process moves on while the document stands still | Assign an owner and a review cadence, and version the document |
| **Assumed knowledge** | "As you know…" shuts out newcomers | Write for someone new in the role and include all the context they need |

## Ground rules

- **The user's description is the source.** Never draft process steps from training data.
- **Don't assume roles, systems, or thresholds.** Ask for the specifics, and mark unknowns `[to be defined by process owner]`.
- **Leave SLAs, budget thresholds, and system names to the user.** If the description is incomplete, ask rather than invent believable steps.
- **Tag generated content** with `[From process description]`, `[Framework methodology]`, or `[Placeholder — define with process owner]`, as applicable.
- **Mention the Word option.** Let the user know they can ask for DOCX output to get a formatted Word document ready to distribute.