When not to automate.

Agencies that build automation are not well positioned to advise against it, which is exactly why the advice is worth something when it comes from them. A partner who tells you a project is not worth doing is more useful than one who quotes for everything.

There are recognisable cases where automating a process costs more than it returns, or where it produces a system nobody trusts. They are worth spotting before the quote rather than after the build.

The volume is too low for the maintenance.

The arithmetic clients do is time saved per run multiplied by runs. The arithmetic that matters includes the cost of the system continuing to exist.

An automation is not a one-off purchase. It needs monitoring, it breaks when a vendor changes something, it needs someone to look when it fails, and it occupies a small amount of attention permanently. A process that runs four times a month and takes ten minutes is forty minutes of work. Almost nothing survives that comparison once the maintenance is counted honestly.

The threshold is not a number, because it depends on how much the task interrupts someone and how bad the consequences of doing it late are. But if the total time spent is measured in an hour or two a month, and the process is not blocking anything, say so.

The process is about to change.

Automating a process encodes it. If the client is midway through changing their CRM, restructuring the sales team, or reviewing the service they are automating around, the encoding will be wrong before it is finished.

This is worth asking about directly, because clients do not volunteer it. “Is anything about how this works likely to change in the next six months” reveals a surprising amount, and the answer is often a migration nobody mentioned.

Wait, or build the smallest possible version that can be discarded.

Nobody can say how it currently works.

If three people describe the process three different ways, there is no process to automate. There is a set of individual habits that have been producing acceptable results.

Automating in that state does one of two things. Either you encode one person’s version and the others discover the system does the wrong thing, or you spend the project running the discovery that should have happened first, on a budget that assumed building.

The right deliverable here is the documented process, not the automation. It is a legitimate piece of work to sell, it is cheaper than the build, and it frequently reveals that the process itself is the problem.

The work is judgement, not steps.

Some tasks look repetitive from a distance and are not. A person deciding which supplier to chase, which complaint needs a phone call, or which application is worth a second look is applying context that exists nowhere in the data.

The test from earlier applies: could a competent new employee follow written instructions and get it right every time? Where the honest answer is no, and where the input has no structure to work from, automating produces confident wrong answers rather than time saved.

The useful version is usually smaller. Automate the gathering, leave the deciding. Put everything the person needs in front of them, in one place, with the routine checks already done, and let them make the call in ten seconds instead of five minutes.

The failure is worse than the manual work.

Some processes have consequences that make automation a poor trade regardless of the time saved.

Sending money. Deleting records. Anything client-facing where a mistake is visible externally, like an email sequence to a customer who has just complained. Regulated communications where a wrong send is reportable.

None of these is impossible to automate, and plenty of businesses do. But they need approval steps, dry runs, caps on how much can happen before a human confirms, and rollback paths, and that work often exceeds the value of the automation for a small business doing it twenty times a month.

Ask what happens if this runs wrong four hundred times before anyone notices. If the answer is serious, the project is bigger than the client thinks.

The data is not good enough yet.

Automation exposes data quality problems that manual work absorbs silently. A person reconciling records notices that two entries are the same company written differently and merges them without thinking. A workflow creates two records.

Where the client’s existing data is inconsistent, duplicated or incomplete, the cleanup is the project. Automating on top of it produces a system that reliably propagates errors faster than before, and the client will attribute the resulting mess to the automation rather than to the data it was given.

The signals, in one place.

Signal	The better first step
A couple of hours a month, not blocking	Leave it manual, revisit at volume
A migration or restructure is coming	Wait, or build something disposable
Three people describe it three ways	Sell the process documentation
The task is judgement on unstructured input	Automate the gathering, not the deciding
A wrong run is expensive or externally visible	Scope the approvals and caps honestly
The existing records are a mess	Quote the cleanup as its own piece

Saying no is a commercial position.

There is a short-term cost to telling a client that the thing they asked for is not worth building. There is a larger cost to building it, watching it deliver nothing, and being the supplier associated with that.

Clients remember the supplier who talked them out of spending money considerably longer than they remember the one who took it. It also changes the next conversation: an agency that declines work on the grounds of value is believed when it says something is worth doing.

The way to do it is not to refuse. It is to say what you would do instead. A smaller version, a different starting point, the documentation first, or nothing at all with a note about what would need to change for it to make sense later.

The version that usually is worth building.

In most of these cases something is still worth doing, and it is smaller than the original request.

Automate the part that is genuinely mechanical, gather what a person needs to decide the rest, and stop. Make the manual step faster rather than absent. That system costs a fraction of the full build, it does not break in ways that matter, and it leaves the judgement with the person who has the context.

If a client has asked for something and you suspect it is not worth building, send us what they asked for and we will tell you honestly whether we think it is. Sending one of these is still worth it, and we will usually point you at the smaller version that is. Send us the details.