Playbook
From Messy Process to Working Automation
Map as performed, veto before costing, shadow-run beside the human, and build the error handler for the trigger failure that carries no execution id.
Automation projects rarely fail at the build. They fail before it, when somebody automates a process nobody owns, and after it, when the thing runs unattended and stops.
This is the whole run: map it as performed, score it, apply the vetoes, cost it, build it, ship it beside a human, and write down what you are not doing yet and what would change that.
Why this exists
Two failure modes cause most of the damage. The first is mapping the documented process, not the performed one. The gap between them is where the exceptions live, and they are what the automation meets on day two.
The second is the silent stop. An automation that fails loudly is a Tuesday. One that fails quietly is found at month end by whoever needed the output, three weeks wrong. So error handling is a build requirement sequenced second, not a hardening phase cut when the date moves.
There is a checkable version of this in n8n. You set an error workflow; an Error Trigger node receives the payload when an execution fails, and Stop and Error fails one deliberately on your own conditions. But the payload has more than one shape. execution.id and execution.url exist only when the execution was saved to the database, and a trigger-node failure sends a different structure — less under execution, more under trigger.
So a handler formatting its alert around the execution URL throws on exactly the failures you most need to hear about, and you are told nothing. Build it against the trigger-failure shape first; treat the richer payload as a bonus.
How to use it
Map by watching once, at the desk, with the person who does the work. Then ask when it last did not go like that, and map that path too. The exception path is the specification; the happy path is the demo.
Apply the vetoes before costing anything. No named owner of the outcome means do not build — an unowned automation becomes the property of whoever notices it broke. An unwritten judgment step means you rebuild the check explicitly, or write in a signed sentence that it is being lost.
A third veto gets skipped. If the system underneath is being replaced within the year, an automation against its interface is disposable by construction. Sometimes still worth doing — decide out loud, before the build, not during the migration.
Cost it in error rate and elapsed time, not only minutes saved. Minutes saved is a small number finance has seen before.
Then build the manual version as a checklist and run it that way for one cycle. If people cannot follow a checklist, a robot will not fix that — it executes the inconsistency faster. Build order after that: happy path, error workflow, exception paths. The error workflow goes second because it never gets built last.
Where it goes wrong
The step skipped most often is the shadow run. The automation does the work and writes its output where nobody acts on it, beside the person’s, and you diff the two daily through a full cycle, month end included. The diff must be reviewed by the person who does the job. You will read a mismatch as a data bug; they will read it as the account that always gets the exception. Usually they are right.
The manual fallback goes untested almost every time. Document how to do the job by hand with it switched off, and test that once before launch. Otherwise it proves impossible during the outage, when the credentials live inside the tool and the queue is three days deep.
This run does not fix a process that is broken rather than manual. Automating a bad approval chain gets you a faster bad approval chain plus the political cost of endorsing it. If the map shows three approvals nobody can justify, that is the finding — take it back before building.
And write the not-yet properly. “Not yet, revisit when weekly volume passes the number on the sheet, or when the replacement lands” is a decision. “Not yet” alone is a stall, re-argued every quarter by somebody who was not in the room.
Copy and Clear become available when the worksheet is ready.
FROM MESSY PROCESS TO WORKING AUTOMATION -- RUN SHEET
Seven stages, in order. Stages 2 and 3 can kill the project; that is
what they are for. Do not open the build tool before stage 5.
PROCESS: OWNER OF THE OUTCOME: DATE:
- MAP IT AS PERFORMED
- Watched do it, at their desk, screen open, end to end.
Date: Elapsed time observed:
1 system: minutes:
2 system: minutes:
The exception path:
trigger: what they did:
how often:
For each, ask: what do you notice while doing this?
- Where documented and performed differ:
This gap is the real requirements list.
- Volume: per week. Trend: rising / flat / falling
- SCORE
A 1 on STABILITY or INTERFACE caps the whole thing. Driving a
screen on a system that changes quarterly is a subscription.
- THE VETOES -- apply before costing anything
automation belongs to whoever notices it broke. Not a plan.
write "we accept losing this check" and have sign it
on . Those are the only two options.
The check nobody wrote down:
Rebuild plan:
Sometimes worth it. Decide out loud now: build / wait
approvals nobody can justify get faster, not fewer.
- COST IT -- in errors and elapsed time, not only minutes
min per run x runs/week x weeks = hrs/year
Error rate today: % Cost of each error: $
Elapsed time today: hrs After: hrs
Who waits during that, and what stops:
Build cost: days Who builds it:
Run cost: $/month tooling + hrs/month attending to it
WHAT KIND OF SAVING IS THIS?
- BUILD -- in this order
people cannot follow it, stop: an automation executes the
inconsistency faster.
FIRST. A failure in the trigger node sends a different
shape: less under execution, more under trigger.
exist. Those require the execution to be saved to the
database, and they are absent exactly when the trigger
itself failed -- the failures you most want to hear about.
TEST: break the credential, fire the trigger, confirm a
readable alert arrives. Done by
business conditions, so bad data raises the alarm instead
of flowing through quietly.
- Alert reaches a human who is awake and empowered:
the most common failure and it looks exactly like calm.
- SHIP SAFELY
Output written where nobody acts on it, beside the human's.
Diff daily, for one full cycle, INCLUDING a month end.
Started Ends
Diff reviewed by THE PERSON WHO DOES THE JOB:
Mismatches found: Explained:
How to do the job with it switched off:
Tested by . Untested fallbacks are discovered to
be impossible during the outage.
- Kill switch: how to stop it inside a minute:
- Named owner on the runbook: . Backup: .
- THE HONEST NOT-YET
What stays manual on purpose:
Why:
REVISIT WHEN -- a condition, not a date:
- weekly volume passes
- the replacement lands
- the exception rate falls under %
Written by on .
A not-yet with a condition is a decision; without one, a stall.