The question always comes up in the second meeting, almost word for word: “right, so where do we start?”. By then the team has already made a mental list of everything it would like to get rid of, and that list usually runs to somewhere between fifteen and thirty items. The problem is not a shortage of candidates. The problem is that the order in which you tackle them decides whether the project builds confidence inside the company or dies in month three.
Worth saying early, because it saves arguments: the first process you automate should not be the most important one. It should be the one that proves fastest that this works.
Why starting with the biggest pain usually backfires
Any management team's instinct is to attack the sharpest pain. If monthly invoicing eats three days of manual work, monthly invoicing looks like the obvious way in. In practice, the process that hurts most is almost always the most tangled one: more exceptions, more departments involved, and a dependence on decisions nobody has ever written down anywhere.
Automating that first means spending six or seven weeks delivering nothing visible, resolving edge cases and negotiating with areas that do not trust the project yet. By the time it ships, half the company has lost interest and the other half has developed a suspicion that automation is slow and expensive. It is an excellent way to ensure the second project never happens.
How we decide what goes first
In a company with recurring administrative processes, the order can be reasoned out fairly coldly. These are the criteria we apply, and they count in combination rather than individually:
- Frequency over duration. A four-minute task happening eighty times a week returns far more than a two-hour task happening once a month. Human intuition fails precisely here, because we remember long tasks and forget repetitive ones.
- A verifiable result. If at the end you cannot show a number that used to be a different number, the project cannot be defended to whoever paid for it.
- Few people involved. Every area drawn in adds a round of sign-off and a risk of stalling. The ideal first project lives inside a single team.
- Decent APIs on the tools involved. This is invisible from the boardroom but it moves the cost by a factor of three. Connecting two documented systems takes days. Extracting data from a closed program that only exports PDFs can cost more than everything else combined.
When a process meets all four, we automate it. When it meets two, we postpone it. There is not much more mystery to it.
What if the process itself is badly designed?
This is the least asked question and the one that saves the most money. A considerable share of the administrative processes in any company exist not because somebody designed them, but because somebody improvised them on a Tuesday six years ago and nobody has looked at them since.
Automating a process nobody has reviewed does not improve it. It freezes it and makes it harder to change.
Before connecting anything we ask why each step exists. In a fair number of cases the answer is that it was done that way for a client who is no longer around, or to meet a requirement that has since changed. Those steps do not get automated: they get removed, which is free and faster. Only when the trimmed-down process still makes sense is it worth building on top of it.
The size of the first project
Our first engagement at a new company rarely runs beyond five weeks. That is not about price but about learning: during that first process we find out how the team actually works, which systems lie in their own documentation, who really decides, and how fast the organisation responds. All of that makes the second project far easier to estimate than the first.
There is another, less technical reason. A short delivery that works changes the internal conversation. People stop debating whether automation is worthwhile and start debating what to automate next, which is a much more productive argument and one the company joins with ideas of its own.
What we leave for later
Some kinds of process systematically go to the back of the queue, even when the theoretical saving is large. Anything involving judgement calls that have never been codified, for instance, or anything touching payroll and hiring, where a mistake has consequences you cannot fix by reprocessing a file. We also wait on processes that depend on software the company is already thinking of replacing, because building on top of something due to disappear is throwing away the budget.
And there is one case worth naming explicitly: when nobody inside the company is going to own the delivered system. There we do not postpone, we simply decline. Automation shifts the dependency, it does not remove it, and an ownerless dependency is a future problem with an unknown date attached.
How this exercise works in practice
It does not require a long audit. Two forty-minute conversations with the people who actually run the operation, rather than those who describe it from above, produce a reasonably reliable ordered list. The useful questions are concrete: what did you do yesterday that you had already done the day before, what information do you copy from one place to another, what report do you prepare by hand and who for.
The first project comes out of that. And out of the first project comes, almost always, a better list than the one you started with.
If you want to see how we take this on as an engagement, it is set out in process automation, and the ranges per project type are published on the pricing page.