How to Scope an Automation Engagement Before You Quote

To scope an automation engagement is to establish, before you put a number on the page, which processes you would change, how many hands each of those processes currently passes through, and what else quietly breaks if you change them. Everything else in a proposal is packaging. If the scope is wrong, a beautiful document just makes the wrong number look more confident.

Most quotes go out with the scope half done. Not through laziness. Through a very reasonable sequence of events: the client describes a problem, the problem sounds familiar, you have solved something shaped like it before, and the estimate you give is really an estimate of the last job. Then week three arrives and somebody mentions the spreadsheet.

Why the quote is usually wrong before it is written

The client is not lying to you. They are describing the process as it was designed, because that is the version that exists in their head and in whatever document they sent over. The version that runs is different, and the difference is where your margin goes.

A quote-to-cash process that the finance director describes in four steps turns out to have eleven, because two of them are a person rekeying a number from one system into another, one is a WhatsApp message to the warehouse, and one is a partner in the business personally approving anything over a threshold he set in 2019 and has never revisited. None of that is in the process doc. All of it is in your build.

So the first job of scoping is not estimating. It is finding out how many steps there actually are.

Start with the count, not the process

Before you decide what to automate, count what exists. For each process in the area you are being asked about, write down the number of distinct hands it passes through, the number of systems it touches, and the number of points where somebody waits for somebody else.

Three numbers. That is the whole exercise at this stage.

The counting is useful for a reason that has nothing to do with the estimate. It is the fastest way to find the processes that are broken rather than slow. A process with four steps and three waits is not an automation problem, it is an approval problem, and you cannot fix it with a webhook. A process with fourteen steps and one wait is a genuine build. Telling those two apart before you quote is worth more than any amount of technical scoping.

What to scope in an automation engagement, in order

There is an order that keeps you out of trouble, and it puts the technical questions last.

The trigger. What starts this process, and how does anyone find out it has started? A surprising number of processes begin with someone noticing something. Those are the expensive ones, because you are not automating a step, you are building the detection that never existed.

The exceptions. Ask what percentage of cases go through the normal path. If the answer is anything under about eighty percent, you are not automating a process, you are automating one branch of it and leaving a manual fallback. That is fine, but it needs to be in the quote, and it needs to be in the quote as a limitation rather than a surprise.

The dependencies. Who else touches the output. This is the one that eats projects. You automate the invoice generation and discover the operations team has been reading those invoices to work out what to schedule, because nobody ever gave them a proper feed.

The owner. Not the sponsor. The person who will actually run the thing after you leave, and whether they exist.

Then the systems. APIs, permissions, rate limits, the usual. This part is genuinely the easy part, and it is the part most scoping conversations start with.

Doing this by hand across a whole client takes the two or three weeks everybody complains about. It is the reason abi. Clone for consultants gives you five client maps free alongside your own: you build the model of how the client actually operates, turn on step counts so every process carries the number of hands it passes through, and the heatmap shows where the time goes rather than where the client assumes it goes. Your own business plus five clients, no card. Letting abi. interview the client's team is the paid part, because that is the only piece that costs money per use.

Price the win, not the build

Once you know the counts, you can express the work in the only unit the client actually cares about, which is hours a month.

An automation that removes a step taken forty times a week at six minutes a step is four hours a week. Say that. Then say what four hours a week is worth at their cost of labour, which they will tell you if you ask, and let the number sit next to your fee.

This is not a pricing trick. It is a scoping discipline. If you cannot express the saving in hours, you have not understood the process well enough to build it, and you should go back to counting rather than forward to quoting.

Where a map does not help you

Here is the part against our own interest.

Knowing exactly how a process runs tells you nothing about whether the client will let you change it. The eleven-step quote-to-cash exists because a partner wants to approve things. You can build a beautiful automation that routes around him and it will be switched off within a month, because the constraint was never technical.

Scoping tools, ours included, are good at the first question and useless at the second. The only way to answer it is to sit in a room with the person who owns the constraint and find out whether they are attached to the outcome or to the ritual. No model does that for you.

There is also a category of engagement where all of this is overkill. If a client has one clearly defined process, one system, and a fixed budget, scope it in an afternoon and quote it. Building a model of their whole organisation to sell a two-week integration is you performing rigour rather than practising it.

The quote that survives contact

A scope you can defend has four things in it: the count of steps as they are today, the specific steps you will remove, the exceptions you are not covering, and the person who owns it afterwards.

That last one is the tell. If a proposal names the future owner and that person has read the proposal, the engagement usually lands. If it does not, you are building something that will run correctly and unattended until the first time it fails, and then quietly stop mattering.

Count first. Quote second. The order is the whole thing.