How I scope an automation project in one call
Thirty minutes, one real task, four questions. What I ask before quoting an automation project, what I refuse to automate, and what the written quote contains.
Most automation projects that go wrong were wrong before any code was written. The task was described from memory, the hard cases were left out, and the quote was for something that does not exist. One call, done properly, prevents most of that.
Ask to watch, not to be told
I ask the person who does the task to share their screen and do it once, with real data, while I watch. Not the manager's description of it. The task itself.
Described from memory, a report is "download from the portal and paste into Excel". Watched, it is: log in, wait for a one-time code, pick a period, export, fix the three rows where the date format is wrong, look up two vehicles that changed department, paste, check the total against last month, and email it to someone who replies with corrections.
The steps that only appear when watching are the ones that decide the price.
Four questions
How long does it take, and how often? Minutes per run, runs per month. This gives hours.
How often does it go wrong, and what does a mistake cost? A wrong total on an internal sheet is an annoyance. A wrong figure on a client invoice is a refund and a difficult conversation.
What are the exceptions? The customer who is billed differently. The branch that closes on a different day. Every process has them, and each one is either a rule in the system or a case left for a person.
Who owns it afterwards? Someone has to notice when it stops and know who to call. If nobody will, the automation will rot.
Rank by hours times risk
Multiply the hours by how much a mistake hurts. Sort the list. The task at the top is often not the one the client came with.
The impressive task, the one with the clever part, is frequently small. The boring weekly reconciliation that nobody mentions is frequently the largest number on the page. I write the ranking down and send it, because it is the most useful thing to come out of the call even if no work follows.
What I say no to
- A process that changes every month. Automating a moving target costs more than doing it by hand.
- A task done twice a year. Write a checklist instead.
- A task whose rules nobody can state. If the answer to "why this row and not that one" is "you just know", it needs a person, or it needs the rule agreed first.
- Getting data out of a system without permission to use it.
Each no is written in the quote with the reason. A client who knows why something was left out trusts the rest of the list.
What the written quote contains
- The tasks to automate, in order, each with what triggers it and what it produces.
- The exceptions that are handled, and the ones left for a person.
- What I need: a dedicated account, sample files, a contact for questions.
- Where it runs and who has access.
- A delivery date.
- What happens after delivery: thirty days of fixes, then support by agreement.
Nothing is quoted on the call. The figure comes in writing after I have thought about the exceptions.
Run it beside the manual process
The first two cycles, the automation runs next to the person doing the task by hand. The two results are compared line by line. Differences are either a bug in the automation or, quite often, a mistake the manual process had been making for months.
Only when they match does the manual version stop. That overlap is the cheapest insurance in the whole project.
Why one call is enough
It is enough because it is narrow. One task, watched once, four questions. A second call is sometimes needed for a second task. A workshop is almost never needed.
The method in more detail is in Audit the process before you automate it. The offer is business process automation, and how to start is on the hire page.