A workflow can pass a demonstration and still leave its team dependent on the person who built it. That dependency appears when access expires, an integration changes, a run fails, or someone needs to adjust the rules.
Treat the handover as an acceptance test. Can another person operate the system, recognize an exception, and make a bounded change using the access and documentation they have actually received?
Separate the responsibilities
Name the business owner, the day-to-day operator, and the technical maintainer. One person may fill several roles, but the responsibilities should be explicit. Also identify who can approve changes to permissions, spending, or external commitments.
Document access through an appropriate credential-management process. A runbook should point to the approved location and explain the required permissions; it should not contain passwords or API keys. Record who controls billing, renewals, and connected service accounts.
Leave an operating record
A useful runbook starts with the purpose of the workflow and the limits of its authority. It identifies inputs, outputs, important dependencies, and the conditions that should stop execution. It describes a normal run before explaining exceptions.
Keep the record close to the implementation and name its maintainer. Link to configuration rather than copying values into several documents. A diagram is useful when it clarifies the system boundary or the path of a consequential action.
| Question | Evidence to leave |
|---|---|
| Who is responsible? | Named business, operational, and technical owners |
| What should happen? | Expected inputs, outputs, and acceptance conditions |
| What can go wrong? | Recognizable failures and escalation instructions |
| How is it changed? | Configuration location, approval rules, and test procedure |
| How is it stopped? | Disable procedure and recovery or compensation plan |
Rehearse without the builder leading
Have the receiving operator run a representative case with the documentation open. Then rehearse one realistic failure and one routine change. The builder can observe, but should not supply missing instructions from memory.
If the operator gets stuck, improve the system or the runbook and repeat the relevant step. Record the acceptance decision and any unresolved limitations. This is more informative than asking whether the documentation looks complete.
Google’s SRE workbook discusses preparation, training, and operational support for on-call work. A small business workflow does not need to copy an SRE organization, but the underlying lesson transfers: responsibility needs practical preparation, not just a name on a document.
Reference: Google SRE Workbook: On-Call
Include the model in the maintenance plan
For an AI-assisted workflow, record the model and prompt configuration, evaluation examples, approval requirements, and fallback behavior. A model or prompt change may alter behavior even when the surrounding integration still runs.
Keep representative tests for ambiguity, missing evidence, permission boundaries, and failed tool calls. Do not place sensitive client examples in a public repository; use approved, redacted, or synthetic cases as appropriate.
Define what the operator should do when output cannot be trusted. That may mean switching to manual review, disabling one action, or stopping the workflow. A fallback should be executable with the access the team has.
Agree what support continues
Specify any stabilization period, the route for reporting problems, and which changes require a new scope. Do not leave ongoing maintenance implied by the fact that someone wrote the code.
Make the recurring cost visible: hosting, model usage, paid connectors, and operator time. State limitations alongside the system, including dependencies the team does not control.
The accompanying checklist is a starting template, not a certification or a substitute for context-specific testing. Adapt it to the consequences of the workflow. A low-risk internal report and a system making external commitments should not share an identical acceptance threshold.
Sources
Background on preparation and operational responsibility. The handover test and checklist are proposed guidance for smaller workflows.
Working on a similar operating problem?
Related services