Automating without losing control

Automation has a property nobody mentions while selling it: it amplifies. A sound process handled automatically produces the same result faster; a broken one produces its mistakes faster, in greater number, and surfaces them later.

The sort that decides everything fits in one question asked at each step: if this step gets it wrong, can somebody undo it? Steps where the answer is yes automate freely. Steps where the answer is no wait for a human hand, and no amount of time saved justifies moving that line.

This article describes how to do that sort, what breaks when it is skipped, and the fifteen-minute measurement that will tell you whether the project is worth its cost before anybody has billed you for anything.

A useful automation is eighty percent ordinary plumbing: connect two tools, move a field, write a rule, fire at a set time. None of that needs a model, and all of it existed long before anyone talked about AI.

The model earns its place in one specific spot: reading free text written by a human. An enquiry in a private message, an unstructured email, an invoice that arrived as a photo. That is where it does something no rule does, and it is the only place it is worth its cost.

Elsewhere it costs without adding. Calling a model to compare two numbers, to check a field is not empty, or to copy a value from one table to another is spending hard currency on an operation three lines of rule do free and without ever getting it wrong. We have an interest in not telling you that, and we are telling you.

The same distinction also separates three products the market sells under one word, and an agent, a chatbot and an automation are not monitored the same way — which decides a purchase more often than the choice of model does.

That distinction has a direct effect on the invoice, and it is easy to check. Ask to see, for each step of the proposed automation, whether it calls a model and how many times per run. A chain calling a model at four steps out of five is almost always badly designed, and the fix — replacing three of those calls with rules — divides the monthly cost without removing anything from the result.

The line between the two columns takes the form of a wait. At that step the system prepares everything — the quote is drafted, the message is written, the order is complete — and stops. A person looks and approves, or corrects.

That wait is often presented as the system’s weakness when it is its guarantee. A supplier proposing to remove it "for smoother flow" is proposing to move the line, and the question to ask is who carries the cost when the step gets it wrong. The answer is always the client, never the supplier.

There is an honest counterpart: approval has to be fast, or it becomes the bottleneck and somebody will eventually ask to bypass it. An approval that requires opening three screens will be bypassed within the month. It has to fit on a phone, in one gesture, with what is needed to decide.

You also have to decide what happens when nobody approves. An approval sitting for three days because the person is on leave blocks everything downstream, and the blockage is silent. The rule to set is a deadline: past an agreed delay, the item escalates to somebody else or returns to manual handling, with a notification. Without that rule, the queue becomes the new place things get lost. That place is managed, and the exception queue has checking rules of its own.

The honest measurement costs a week and you can do it alone: take the task that annoys your team most, and record each day the time actually spent on it. Not the estimate — the record. The gap between the two runs in the same direction every time, and it is large.

We put no chart in this section, and not for the usual reason. The figure exists and is solid at each client; it is simply not transferable. Entering invoices, triaging enquiries and reconciling lists share neither unit duration, nor frequency, nor exception rate, and an average across them describes none of the three. Publishing that average would give you a number you could not apply to your own case.

What the record does allow is a decision. If the task takes ten minutes a week, the integration will not pay back for years, and the tool at the other end will have changed its interface by then. If it takes six hours, the question does not arise. The line is somewhere in between and the record finds it.

The record has a second use nobody anticipates: it shows the variance. A task averaging forty minutes but running between ten minutes and three hours depending on the day is not the same task as one stable at forty minutes. The first contains many edge cases, and they are what will decide the project's real cost — not the average, which dissolves them exactly as it dissolves everything else.

We watch the process, we fill in the two columns with you, we build one automation at a time and put it live before starting the next. A month later we measure again, and anything that saves no time is removed rather than kept out of politeness.

The figure we will not carry over is the gain observed at another client. We have those numbers, they are recorded cleanly, and they do not concern you: they describe one specific task, in one specific business, with an exception rate of its own. A supplier who opens with "our clients save so many hours a week" has given you information about their clients and none about you, and they know it. We would rather have you run the one-week record, even if it delays the sale, and even if the record sometimes concludes there is nothing worth automating.

We also have a limit of competence to name. If the sort reveals that the process itself is the problem — that it accreted over years, that three people run the same check, that step four exists to compensate for step two — we do not redesign it. That is organisational work, not integration work, and it is done with somebody whose trade it is, or internally with the people concerned. We will say so, hand you the process page that shows it, and stop there. Automating a process in that state amounts to setting it in stone.