The pilot-build sequence
One narrow automation at a time — from a candidate on your audit list to a working, monitored system
2 min read
-
Candidate selection. Pick the single highest-scoring item from Auditing your own operations — the highest volume, clearest rules, lowest error-cost — not the most interesting or most ambitious one. The first automation you ship should be boring. Ambitious comes later, once you've built the process-specification muscle once.
-
Process specification. Write the current process down as an explicit, step-by-step rule set, including every exception you can think of — this is where the translation skill The mechanism names as the real bottleneck gets used, and where most sourced 2026 automation failures actually originate: not a tooling gap, but a process that was never fully written down before someone tried to automate it. If you can't finish this step without repeatedly writing "it depends," the process needs fixing before it needs automating.
-
Build. Pick the tool from Tools and vendor stack that actually fits the process's complexity — a simple two-step trigger-action belongs in Zapier; anything with real branching logic, or a cost sensitivity that matters at your volume, belongs in n8n or Make. Build the narrowest version that handles the specification from step 2, nothing more.
-
Shadow-run. Run the automation in parallel with the existing human process — without cutting the human process yet — for a defined window: either a fixed period (a week is typical) or the first 20–100 real transactions, whichever comes first. Compare the automation's output against what the human process actually produced. This window is what surfaces the failure modes that survive clean internal testing but only show up against real, messy input. [Directional] — the "first 20–100 real transactions surface most surviving failure modes" pattern is consistent across sourced 2026 automation post-mortems.
-
Cutover, with a monitoring window and an escalation path. Once shadow-run accuracy clears the error-cost threshold you set for this process, cut over — but keep a defined path for the automation to hand off to a human whenever its own confidence is low, rather than forcing every case through unattended. KPIs and kill switches covers how to tell, after cutover, whether that escalation path is being used at a healthy rate.
-
Log the first month. Hours saved, error rate, and actual cost — tool subscription plus API metering plus any contractor fee, amortized. This is the number that justifies (or doesn't) building the next automation, and it's your own real evidence for ROI and payback's formula, not a marketing multiplier borrowed from someone else's business.
Up next
Tools and vendor stack
2026 pricing snapshot for an operator's own build — verify at build time, these shift often
2 min