# Automation handover doc: the 11-section template The standard: an engineer who didn't build it can deploy, run, fix and change it, from this doc and the delivered materials alone, without a call to the builder. The last part of the standard is a dry run: someone who did not build the system runs it from the doc, and what they trip over gets fixed and logged in section 11. Until that has happened, the doc is a draft, however complete it looks. > **How to use this template.** One doc per automation. Target 2-4 pages. Reader: an engineer who knows the stack but has never seen this system. Write how-to steps and reference tables, not essays. Sections 8-10 (access, boundaries, who owns what) are the ones a handover fails on later: never skip them. Delete all `>` guidance blocks before delivering. Keep a PDF snapshot of each accepted version; the doc itself stays live. | | | |---|---| | System | [name] | | Version / status | v1.0 · [live / rolling out / paused] | | Built by | [builder] | | Owned by | [the client company, as your agreement states] | | Runtime / stack | [n8n workflow / script / Apps Script + where it runs] | | Doc last updated | [date] | | Validated by | [name + date of last doc-driven dry run] | ## 1. What this does and why > 3-6 sentences. The business job, who uses it, cadence, what it replaced, the measured or estimated saving (say which). This is the only "explanation" section; everything after is procedure and reference. ## 2. System map > One diagram (or ASCII flow) showing the path of data end to end. Then the components table. "Runs under" matters: it is what breaks when an account is offboarded. ```text [source] → [processing] → [output] → [recipient] ``` | Component | What it is | Where it lives | Runs under (account) | Admin | |---|---|---|---|---| | | | | | | Upstream dependencies: [systems this consumes, e.g. the output of another automation] Downstream consumers: [who or what receives the output] ## 3. Configuration reference > Every user-editable setting. For each: name, what it controls, valid values, one example. If config lives in a spreadsheet, define every column and state the matching rules (what must match what, case sensitivity, the exact source of truth). Link the live config here. Mirror the "how to edit" basics in a README tab inside the sheet itself. | Setting / column | Controls | Valid values | Example | |---|---|---|---| | | | | | ## 4. Operate: the routine cycle > The recurring procedure, numbered steps, with the expected result of each step ("you should now see X"). State the trigger (schedule or manual), pre-run checks, and how to verify a successful run. If a human approves anything mid-cycle, mark the approval point. 1. [step] → expected: [what good looks like] How to verify a run succeeded: [where to look, what to see] Where errors surface: [log / mailbox / channel] ## 5. Routine modifications: how to change it > The changes a non-builder is expected to make. One numbered mini-procedure per change type. Cover at minimum: add or remove a record, change routing or ownership, change template text, pause and resume, add a new user of the system. ### 5.1 [Add a new X] ### 5.2 [Change Y] ### 5.3 [Pause / resume] ## 6. Failure modes and troubleshooting > Known ways it breaks, ordered by likelihood. Symptom → cause → fix. Include the failure modes found during the build and testing, not just theoretical ones. End with the escalation line: what to try first, who to contact for what. | Symptom | Likely cause | Fix | |---|---|---| | | | | Escalation: config-level issues → self-serve per section 5 · [infra] issues → [owner] · system logic broken → [builder or maintainer] ## 7. Deploy / restore from zero > Assume the runtime is empty and only this doc and the delivered materials exist. Prerequisites (accounts, permissions, tools and versions), then numbered setup steps to a verified first run. This section is the hard test of "deploy" in the standard. If a step needs a credential, point to section 8; never paste secrets here. Prerequisites: 1. [account / permission / tool] Steps: 1. [step] ## 8. Access and credentials: who holds what > Everything needed to operate without the builder, held in the client's name. No secret values in this doc, only locations and owners. | What | Where it's held | In whose name | Who can grant access | |---|---|---|---| | | | | | ## 9. Boundaries and support after handover > What the system does NOT do, inputs it does not accept, volumes and limits it isn't built for, and untested paths. Any support agreed after handover applies within these boundaries. Changes beyond the routine modifications in section 5 are new work, not covered by this doc. This system does not: [list] Untested / known pending: [list] ## 10. Reusable parts: who owns what > List the builder's generic, reusable modules built into this deliverable. Say who owns them and what the client may do with them, in the words of your agreement. | Module | Function in this system | |---|---| | | | Everything not listed above is client-specific content; state who owns it. ## 11. Change log and validation record | Date | Version | Change | By | |---|---|---|---| | | v1.0 | Initial documented state; accepted [date], PDF snapshot [link] | | Dry-run validations: [who ran the system from this doc alone, date, issues found → fixed] --- ## Self-audit before handing over (delete after checking) 1. Deploy: could an engineer rebuild it from section 7 and the delivered materials, with zero calls to you? 2. Operate: does section 4 let them run a full cycle and know it worked? 3. Maintain: does section 6 cover every failure seen so far? 4. Modify: does section 5 cover every change request received so far? 5. Are sections 8-10 complete (credentials named, boundaries explicit, reusable parts listed)? 6. Has someone who didn't build it actually tried? Log it in section 11.