Most automation projects that go over budget don't go over budget because the code was hard. They go over because the scope was never actually fixed, it was a vague description of a process that turned out to have six exceptions nobody mentioned in the kickoff call. Scoping properly is less exciting than building, and it's the single highest-leverage hour in the whole engagement.
Map the process before you map the code
Before touching an API or a script, we ask the client to walk through the process as it actually happens, not as the org chart says it happens. There's always a gap. The documented process has three steps; the real one has three steps and then someone in finance manually overrides it every time a customer is on a payment plan. That override is the part that breaks the automation if you don't scope for it up front.
- Ask for the exceptions first. 'What happens when this goes wrong' reveals more than 'what happens when this goes right.'
- Get three real examples, not a description. A real invoice, a real lead, a real ticket, with the messy formatting intact.
- Name what's explicitly out of scope in writing, before the quote, not after the first change request.
- Separate 'automate this' from 'fix this process' as line items. They're different projects with different risk.
Fixed scope, fixed price, named exceptions
We quote a defined version of the process: these input formats, this volume, these three exception paths, handled explicitly. Anything outside that is a change order, not scope creep we silently absorb. This isn't about being rigid, it's about both sides knowing exactly what 'done' looks like before the invoice goes out. Vague scope is the root cause of almost every automation project that goes bad.
The discovery week pays for itself
A short, paid discovery phase before the build, where you actually map the process and pull real sample data, feels like overhead to clients in a hurry. It isn't. It's the cheapest insurance in the entire project, because every hour spent finding an exception before the build is worth ten spent fixing it after the automation is already live and quietly getting it wrong.
Put this to work
3 linksRelated reading
AP automation in 2026: what the research says, and what a 20-person business should do about it
New surveys put the share of finance teams still keying invoices by hand at about 2 in 3, and SMB adoption of AI at its highest yet. A read of the 2026 numbers, where they mislead, and a 3-step plan that fits a business without a finance department.
Intake → Model reads → Checks → Review tab → Your Sheet
How to choose an automation partner (without getting locked in)
The cheapest quote often becomes the most expensive system. A short checklist for hiring someone to automate your business, ownership first.
Short cycles → Full source → Your accounts → Runbooks
When automation is worth it (and when it isn't)
Not every manual task should be automated. A simple framework for deciding what to automate first, and what to leave alone.
How often? → Rules-based? → Error cost? → Automate it
Continues · Got a workflow like this?