Documenting an AI workflow for handover.

Goal

Turn an AI workflow that lives in one person’s head into a runbook another person can follow on their first try.

Who it is for

Anyone in a New Zealand team who set up an AI-assisted task, and managers who need it to survive leave, illness or resignation.

Time

30 minutes.

You need

ChatGPT, Claude, Copilot or Gemini and the fictional handover notes below.

You will produce

A one-page runbook, a list of gaps to fill, and the result of a handover test.

Why document an AI workflow at all?

Because AI workflows fail quietly when their owner leaves. The prompt sits in someone’s chat history, the reference files are on their desktop, and the review rule was “I just check it looks right.” The next person reinvents it, usually worse.

MBIE’s responsible AI guidance puts it in business terms: “Recordkeeping and documentation supports accountability, helping you to understand where and how decisions have been made,” and “It is helpful to clearly document who is in charge of what, so everybody knows their role.”

Handover is not the only moment the runbook earns its keep. The same guidance notes businesses “may need to be able to refer to where AI is being used and how”, for customer questions or audits. A runbook answers both, and it is the first thing to reach for when a tool changes or an output looks wrong.

What goes in a handover runbook?

Twelve headings cover almost every AI workflow. Keep each one short.

Purpose and owner

What the workflow produces, for whom, and who is accountable for it.

Trigger and frequency

What starts it and how often it runs.

Inputs

Where each input comes from, its format, and how to get it.

Tools and accounts

Which AI tool and plan, whose account or shared project, and who administers access.

Prompt and version

The exact text, a version number and the date it last changed.

Reference files

File names, locations and versions the AI uses.

Steps

Numbered actions a newcomer can follow.

Human review

Who checks what, against which source, before the output is used.

Data rules

What must never go into the tool.

Known failure modes

Typical mistakes and how to spot and fix them.

Test cases

Three to five inputs with expected outputs, to rerun after any change.

Change log

Date, change, who, and test result.

Exercise: turn messy notes into a runbook

The practice and notes below are fictional. They are typical of what a busy person writes before leave.

Illustrative handover notes. Fictional accounting practice,
Tauranga. Written by Mere before parental leave.

Monthly mgmt report commentary for our 6 retainer clients.
I export the P&L and balance sheet from Xero as Excel, around the
5th working day. Paste into the Claude project "Mgmt commentary"
(it's in my account, sorry). The prompt is in the project
instructions, I tweaked it in August. It writes the variance
commentary. I check numbers against the export, fix anything
that says "significant" when it's under 5%. Then Hemi signs off
and it goes to the client in the report pack.
Don't put payroll detail in. Sometimes it confuses last year
and this year columns if the export has both. The Harbourside
client wants te reo greetings, ask Hemi.

1. Run the interview prompt in the worked example below with the notes.
2. Read the gaps list. Every [UNKNOWN] is a question to ask the owner before they leave. Count them.
3. Answer three gaps yourself, role-playing Mere, and ask the tool to update the runbook.
4. Fix the account problem. The project sits in a personal account. Write down the action: move it to a shared or business workspace owned by the practice.
5. Add test cases. Ask the tool for three test inputs and expected outputs based on the failure modes, such as an export with both years’ columns.
6. Run the handover test. Give the runbook to a colleague, or paste it into a fresh chat with “You are a new staff member. List every point where you could not complete the task from this document alone.” Fix what they find.

Worked example: the interview prompt

You are documenting an AI workflow so another person can run it.
From the notes below, draft a runbook with these headings:
Purpose and owner, Trigger and frequency, Inputs, Tools and
accounts, Prompt and version, Reference files, Steps, Human review,
Data rules, Known failure modes, Test cases, Change log.

Rules:
- Use only information in the notes.
- Where information is missing, write [UNKNOWN: question to ask].
- Flag any single point of failure (one person, one account).
- Write steps a newcomer could follow without asking anyone.

[paste notes]

Example output (illustrative and abridged; your tool’s wording will differ):

Tools and accounts
Claude project "Mgmt commentary" in Mere's personal account.
SINGLE POINT OF FAILURE: move to a practice-owned workspace.
[UNKNOWN: which Claude plan, and who administers it?]

Prompt and version
[UNKNOWN: exact prompt text; copy from project instructions.
Changed August 2026; what changed?]

Human review
1. Preparer checks every figure against the Xero export.
2. Preparer replaces "significant" for variances under 5%.
3. Hemi signs off before the report pack is sent.

Known failure modes
- Mixes current and prior year when both columns are exported.
  Check: compare three figures per client against the export.

The gaps list is the real deliverable. It tells Mere what to write down before her last day.

Where this goes wrong

• Describing the prompt instead of copying it. “It writes variance commentary” cannot be rerun. The exact text can. Store it in a shared prompt library.
• Ignoring the model. Vendors change and retire models. OpenAI retired GPT-4o in ChatGPT on 13 February 2026. Note what you used, and rerun the test cases when it changes.
• Vague review rules. “Check it” is not a rule. Name the source to check against and what to look for.
• Accounts tied to people. A workflow in a personal account leaves with that person. See managing AI subscriptions and access.
• Privacy left out. If personal information is involved, the Privacy Commissioner’s generative AI expectations include procedures for accuracy and for access and correction requests. The runbook is where those procedures live.

Check your work

• My runbook includes the exact prompt text with a version and date.
• It names the owner, the reviewer and the account the workflow depends on.
• Every [UNKNOWN] has been answered or assigned to someone with a date.
• It contains at least three test cases with expected outputs.
• Someone unfamiliar with the workflow followed it and I fixed what they found.
• It is stored somewhere shared, not in a personal account.

Where to go next

Next in the pathway: managing AI subscriptions and access, which fixes the personal-account problem at its source. To design a workflow before documenting it, see writing a workflow specification and the AI workflow mapping template. The month-end example above follows our guide to month end reporting preparation. Engineers should read versioning prompts and evaluations and AI audit logs. If you would rather someone else ran and maintained production AI workflows, see managed AI operations.

Written by the Levy Street team in Wellington. Last updated 19 October 2026.