The Automation Your Client Will Pay For Is Not the One They Asked For

The process to automate first is the one that passes through the most hands, not the one the client mentioned on the call. Those are almost never the same process, and the gap between them is where an MSP's automation practice either earns its margin or quietly gives it away.

Here is how the call usually goes. The client says something like "we need to automate the onboarding emails". You say yes, because it is a real job and you can see how to do it. Three weeks later the emails go out on their own, the client is pleased, you invoice a few hundred pounds, and nothing else changes. The finance person is still rekeying every job into the accounts package. The engineers are still chasing sign-off on a spreadsheet. Everyone is still losing the same Thursday afternoon to the same report.

You automated the thing they could see. The thing they pay for is the thing they cannot.

Why the client names the wrong process

People name the process that annoys them personally, on the day you ask. That is not stupidity, it is proximity. The owner of a twenty-person firm sees the onboarding emails because a customer complained about one last week. They do not see the invoice run because it happens in someone else's inbox, and it has happened that way for so long that nobody thinks of it as a process at all. It is just Karen's Thursday.

There is a second reason. The processes that cost the most are usually the ones that work. A broken process gets complained about and fixed, or at least noticed. A working process that takes nine steps and four people gets no attention, because it works. Nobody has counted the steps. Nobody has ever needed to.

So if you build what the client asked for, you build against a sample of one, chosen by whoever was in the meeting. That is a poor way to pick a project, and it is the way most first automation projects get picked.

What "most hands" actually means

Take a process and count the number of people it passes through between start and finish. Not the number of people who could touch it. The number who do, in a normal week.

A quote that goes from the account manager to the engineer for a sanity check, back to the account manager, to the director for approval, back to the account manager to send, and then to finance when it is accepted, has passed through four people and made six hops. Every hop is a wait, a chance for the thing to sit in an inbox, and a place where the version somebody is looking at is not the current one.

Now compare that to the onboarding emails. One person, one hop, a few minutes each. Automating it saves the few minutes. Automating the quote saves the waits, and the waits are where the days go.

This is the single most useful question to ask about any process you are thinking of automating: how many hands does it pass through, and how many times? The answer sorts a client's work into an order that the client themselves would not have guessed, and it is usually a surprise to them.

How to find it in a week, without doing free consulting

The obvious way to get this picture is to sit down with the client for a day and map everything. Nobody pays for that day. It is the unpaid discovery that every MSP has done and resented, and it is the reason most automation practices never get past the first project. You cannot afford to give away the finding, so you skip it and build the thing they asked for.

The way round it is to stop being the person who does the interviews.

Send five or six people in the client's business a private link. Each of them spends twenty minutes, by voice or by text, answering questions about last Tuesday: not "how does invoicing work" but "walk me through the last time you ran it". The specific, slightly embarrassing answer is the one worth having, because it contains the workaround, and the workaround is the billable work. When someone says "and then I just email it to Dave", that sentence is the project.

That is what abi. Clone for MSPs is built to do. abi. interviews the client's team through a link, no account and nothing to install for them, and builds a live map of how the business actually runs from what people say. Turn on step counts and every process on the map carries the number of hands it passes through. The heatmap shows the expensive ones, and they are rarely the ones anybody complained about.

You are not in the room for any of it. You get the map, the client's own words, and a ranked list of what to fix, without spending a day you cannot bill.

Cost it in the client's numbers, not yours

The second mistake, after picking the wrong process, is pricing the right one badly.

An automation is worth what it saves, and it saves hours. So the case should be in hours a month and pounds a year, at the client's own rates, against the process it changes. "This saves finance about six hours a month, which at what you pay for that role is roughly this much a year, and the build costs this much." That is a quote a director can approve in one meeting. "We can automate your quoting for £1,800" is not, because it has no other side to the equation.

Doing this by hand means asking the client what people cost and doing the sums for each candidate process. On a map that already knows the steps and the hands, the proposed automations sit against the processes they would change, already costed in the client's own rates, with the quick wins ranked. The business case is written before you open the proposal document.

Where this goes wrong, and when to ignore all of it

Sometimes the process the client named is the right one. If the onboarding emails are losing them customers, fix the emails. Revenue leaking beats hours saved, every time, and a client who feels heard on the first job is a client who lets you do the second. Build the thing they asked for, then bring the map to the review and show them what else it found.

If the client's whole operation lives inside one system that already has an automation layer, and the work is mostly configuration, you do not need any of this. Quote the configuration.

And under about ten people, the count-the-hands exercise usually comes back with one answer and it is obvious to everyone. Save the interviews for clients big enough to have processes nobody can see.

Everywhere else, the process worth automating first is the one nobody mentioned. Count the hands, cost the hours, and take that to the client instead of the job they gave you. It is a bigger project, it is a better project, and it is the one they will remember you for.