Scoping an Automation Project: 15 Questions Before Anyone Quotes a Price

An automation quote given after a twenty-minute conversation is a guess, and both sides discover that halfway through. What creates the gap is not unprofessionalism but questions that were never asked - almost always the same questions, and almost always in the same three areas: data, exceptions and maintenance.

Five questions about the process

1. What happens today, step by step, including who performs each step.
2. What the trigger is - what starts the process, and exactly when.
3. What the end result is, in terms you can verify.
4. Who uses the result, and what they do with it.
5. What happens when it finishes - a record, a notification, or nothing.

The first question sounds redundant and is the most important. A step-by-step description of the current state reveals, on average, two or three steps nobody mentioned in the first conversation because they are "obvious" - and those are precisely what produce the estimating gap.

Five questions about the data

The last row is the surprising one. In many projects cleaning and matching the data is larger than the build itself, and its true size only becomes clear when you look at actual data rather than a description of it. So it is worth requesting a sample before quoting, and the full cleanup logic is in customer master data cleanup.

Five questions about exceptions and maintenance

• What happens when a value is missing - stop, skip, or alert?
• What happens when the other system is down - retry, how many times, and then what?
• What known exceptions exist today, and who handles them?
• Who gets alerted when something fails, and on which channel?
• Who maintains it after handover, and what is included?

The first two separate an automation from a script. A process with no defined failure behaviour will fail silently, and that is the most expensive state - discovered weeks later, after the data has already drifted out of sync.

What the volume question really decides

"How many records" sounds like a technical question with no business consequence, and it is one of the questions that moves price more than any other. A process handling 50 records a day can run with complete simplicity: one after another, no queues, no elaborate failure handling.

The same process over 50,000 records is an entirely different project. Now the other side's rate limits matter, batching is required, resuming from the failure point rather than restarting matters, and monitoring has to show progress. None of those requirements is excessive at that volume, and all of them are excessive at the small one.

So the volume question belongs in the first conversation, alongside a companion question: is the volume expected to grow, and how fast. Building precisely for today and not for next year is a legitimate decision - provided it was decided rather than happened by accident.

What to write in the scoping document

Five sections are enough: the current process, the intended process, the data sources, the exception list with its behaviour, and what is out of scope. The last is no less important than the first - "what will not be built" is what prevents the argument at the end.

Anyone commissioning a project without such a document pays for it anyway, only later and in the form of change requests. The broader decision between buying a tool and building is in build versus buy for automation.

What happens when part of the answer sits in a system you do not run

A large share of automation projects touch a system the business does not operate itself - the invoicing software, the courier system, or a large customer's system. In those cases there is an extra question that decides more than all the others: who provides the access, and on what timeline.

The common gap is that the business assumes access exists, while in practice it requires contacting the vendor, sometimes a plan upgrade, and sometimes a wait. A project planned for two weeks that waits ten days for a key is not a project that ran late - it is a project that did not ask.

So three things are worth establishing before work starts: whether an interface exists, who is authorised to approve access, and how long it took last time. The third answer is the most useful, because it is the only one based on experience rather than on a promise.

What to ask the supplier, not only yourself

• What is unclear to you after reading the scope?
• What is the biggest risk in this project, in your view?
• What are you assuming that was not stated explicitly?
• What happens if the data turns out worse than we thought?
• What is included in the first month after handover?

The second question is the practical test. A supplier who answers "no risk" or points at nothing has not analysed the project; a supplier who points at the data, at a system with no interface, or at an undefined exception has actually read the scope.

What if there are no answers yet?

That is common and legitimate, and the right response is not to guess but to record. Every unanswered question becomes an explicit assumption in the document, with its consequence: "assuming the data arrives as a daily file; if an interface is required, that is an addition".

Written assumptions change the nature of the later conversation. When an assumption turns out to be wrong, there is a document showing what the estimate rested on - and that is a conversation about adjustment rather than blame. Businesses that do not record assumptions have the same conversation as an argument.

Sources

• Business automation for small businesses in Israel
• Make - error handling in scenarios