The Integration That Should Have Been a Person

Almost everything written about automation is about what to automate. The more useful list is the opposite one, partly because it saves money and partly because a supplier who tells you where not to bother is easier to believe about everything else.

1. When two people would answer differently

The first test is not technical. Ask two experienced people how they handle a case and see whether the answers match.

If they do not, and both are defensible, you have an unresolved decision rather than a process. Automating it does not settle the disagreement. It encodes one version, hides the other, and produces output that half the business quietly disagrees with.

Fix the decision first. An hour in a room, and frequently that hour delivers most of the value the automation was supposed to.

2. When it runs monthly or less

Frequency governs the economics more than complexity does.

A process running twelve times a year rarely repays a build, and by the fourth run the process will have changed. Worse, nobody develops a habit around something that infrequent, so when it does run somebody has forgotten how the system works and does it by hand anyway.

Document those properly instead. The documentation is the actual win and costs a fraction.

3. When being wrong is expensive and invisible

Systems do the same thing every time. They are poor at noticing that the same thing has become the wrong thing.

If an error would surface immediately, that is manageable. If it would surface three months later inside a client relationship or a compliance context, the cost is disproportionate to whatever was saved.

The answer is not to avoid automating, it is to keep a person at the point of consequence. Not reviewing everything, which defeats the purpose, but reviewing above a threshold you set by what a mistake costs rather than by volume.

4. When the relationship is the product

Some contact exists to demonstrate that a person is paying attention. Automating it removes the only thing it was doing.

A check in call after a difficult month. The message acknowledging that something went wrong. The conversation where a client is talked out of something they want. Those are not information transfer, and a well written automated version is worse than nothing because the client can tell.

The distinction is whether the message carries information or attention. Automate the first freely. Leave the second with people.

5. When you are automating around a broken process

The most expensive mistake on this list.

A business has a step that exists because two departments disagreed years ago, or because somebody once made a mistake and a check was added. Nobody has questioned it. Automating it makes the workaround permanent and considerably harder to remove, because now it is encoded rather than merely habitual.

Before automating any step, ask what would happen if it simply stopped. A surprising number of answers are nothing, and deleting a step is cheaper and faster than automating it.

What this leaves

Run those five filters over a list of candidates and what survives is usually a small number of unglamorous processes that happen every day, follow the same shape, and nobody enjoys.

Lead routing. Document chasing. Status updates. Report assembly. Onboarding sequences. Invoice matching. Those are where automation pays, and they are consistently the last things anybody suggests because they are not interesting.

Where AI moved one of these lines

Worth updating one of the traditional answers, because it changed recently.

The old rule was that anything involving a judgement call could not be automated, which is why so many workflows automated the easy part and stopped at the bottleneck. That is no longer true. Small judgement steps, is this a complaint or a question, does this document contain what it should, which of these four people should this reach, are now inside the reach of a system.

What has not changed is everything above. A judgement your business has not agreed on, a process that runs quarterly, an error that would go unnoticed for months, a relationship that needs a person, or a step that should be deleted. Those are the same as they were, and capability does not touch any of them.

The question to ask before any build

What would happen if this process simply stopped for a month?

If the answer is chaos, it is worth automating. If the answer is that somebody would eventually notice, it is worth examining. If the answer is nothing, you have found something better than an automation opportunity.

The seasonal exception

One category sits awkwardly between the rules above: work that is infrequent but expensive when it happens.

Year end. An annual compliance submission. A tender response. These run once or twice a year, which fails the frequency test, and consume a great deal of senior time, which argues for building something.

The resolution is usually to automate the assembly rather than the process. Nobody should build a system for producing a tender. Somebody should make sure the material a tender needs is already gathered and current, so the work becomes writing rather than hunting.

That distinction is worth applying generally. Automating the gathering is nearly always safe. Automating the decision requires everything above to be true.

Pilot the boring one first

Businesses tend to start with the process that hurts most, which is usually the most complex, which is where these projects fail.

Start with something small enough to be running within weeks. It builds the internal confidence that makes the difficult one possible, and it teaches you where your own systems are awkward before that knowledge is expensive.

The second automation in a business is always considerably faster than the first, and the first should be chosen to make that true.

AI Optimize will tell you when a process should be deleted rather than automated, which is more often than most suppliers admit. That work sits under Workflow Automation.