Why one page

Long documentation doesn't get read or updated. One page per workflow, in plain language, is enough for most small-business automations. If it doesn't fit, the workflow may be doing too much.

The template

Copy these headings for each workflow.

1. Purpose

One or two sentences: what problem does this solve, and for whom? *"Sends an acknowledgement to every website quote request and assigns it to the sales owner."*

2. Trigger

What starts it, exactly. *"A successful submission of the Quote form on the website."*

3. Systems and data

Which apps are involved, which account each runs under, and which data fields pass through. Note anything sensitive.

4. Steps

A numbered list of what happens, in order, in plain language. Include filters and branches.

5. Owner and alerts

Who owns the workflow, who receives failure alerts, and who is the backup.

6. How to pause or stop it

Exactly where to click or what to do. This is the section people need in a hurry.

7. Known limits and exceptions

What it doesn't handle, and what happens to those cases. *"Inquiries with no email address are not acknowledged; they appear in the shared inbox only."*

8. Test cases

The test cases used at launch (see how to test an automation) and when they were last run.

9. Access and credentials

Which accounts and keys it uses — *never the passwords or keys themselves*. Where they're stored, who can change them, and when they expire if known.

10. Change log

Date, what changed, who changed it, and why.

Keep it alive

  • Update the runbook in the same sitting as any workflow change.
  • Review all runbooks briefly every quarter, or when a staff member leaves.
  • Add a line to the change log after every failure: cause and fix.
  • Check the "how to pause" instructions still work.

Runbooks and handovers

Runbooks matter most at handover: when a contractor finishes, an employee leaves or you change platforms. Pair the runbook with the access record from safe vendor access and offboarding, and the business keeps control of its own systems.

Questions

Where should the runbook live?

Somewhere your team already looks and that isn't tied to one person's account — a shared drive folder or internal wiki. Link to it from the workflow itself if the platform allows notes.

Who should write it?

Whoever builds the workflow writes the first version. The process owner should read it and confirm it matches how the business actually works.

Next step

Start with one workflow worth fixing.

Bring the real steps, the tools you already use and the place the handoff gets stuck. We review feasibility, access and approval points before quoting — no instant integration promise.

See Business Automations for what we scope, or prepare a custom quote brief.