What We Automate and What We Refuse To

We automate a lot. Content checks, publishing, image handling, link audits, quality gates that refuse to let work out of the door.

There is also a category we deliberately do not automate, and the boundary is not where people expect. It is not about technical difficulty, and it is not about importance.

It is about whether a wrong answer produces a signal.

The rule

Automate anything where being wrong is visible. Keep a person wherever being wrong is silent.

A check that refuses a file with a broken link is safe to automate. If it gets it wrong, somebody immediately notices — the work is blocked, and a human looks at it.

A check that decides whether a claim is adequately evidenced is not, because the failure mode is silent approval. Nothing is blocked, the piece goes out, and the error surfaces weeks later in front of a reader.

The asymmetry is the whole thing. A false refusal announces itself. A false approval does not.

What that means in practice

Three categories we keep automated, and three we do not.

Automated: anything mechanical and checkable. Character limits, image dimensions, link resolution, file existence, schema validity, duplicate detection. These have right answers that a machine can establish, and a wrong result blocks visibly.

Automated: anything that fails closed on unknowns. Our ad-copy checker refuses an unrecognised placement rather than skipping it. The refusal is occasionally annoying and always visible.

Automated: the tedious and reversible. Formatting, repointing links, generating variants. If it goes wrong you fix it and re-run.

Not automated: whether a claim is true. A machine can confirm a number appears in a cited source. It cannot confirm the source supports the claim being made about it, that the number has not been rounded favourably, or that the scope has not been quietly widened. We use a model as a reviewer that can object — and an objection is a signal, so that is safe. What we do not do is let it approve.

Not automated: whether something should be said at all. Tone, timing, whether a piece names a client, whether a finding is ours to publish. These have no correct answer to compute.

Not automated: anything that spends money or sends a message to a person outside the business. Not because a machine would do it badly, but because the consequence is external and immediate, and the cost of one wrong action is far higher than the cost of a person clicking approve.

★ Insight ───────────────────────────────────── The test that makes this operational: if this automation were wrong every time for a month, when would we find out? If the answer is “immediately”, automate it. If it is “when a customer tells us”, keep a person. Most automation decisions get made on how much time the automation saves, which is the wrong axis — a control that saves an hour a week and fails silently for a quarter is not a saving. ─────────────────────────────────────────────────

The refusal is the product

The most valuable thing our gates do is not the work they do. It is the work they stop.

A publishing gate that has never refused anything has provided no evidence about anything — and we had exactly that this month, a duplicate check that approved everything because it was reading a file that one category of item never writes. Zero blocked read as a clean pipeline and meant nothing at all.

Which produced a standing rule: a new check ships with one recorded case of it refusing something it should refuse. Not a unit test. An actual run, on the actual path, with the output kept.

Where most small businesses get this wrong

Two directions, roughly equally common.

Automating the judgement and keeping the typing. A business will happily let a tool decide which leads are worth following up, and then have a person manually copy data between two systems. That is precisely inverted: the copying is mechanical and checkable, and the prioritisation has a silent failure mode — you never find out about the customer you did not call.

Refusing to automate anything because one attempt went badly. Usually the attempt was in the second category, failed silently, and the conclusion drawn was about automation in general rather than about that boundary.

The category people most often get wrong

One specific case, because we see it constantly in small businesses: automating the follow-up but not the record of it.

An automated sequence emails a prospect four times over a fortnight. Nobody logs whether a human ever spoke to them, so the sequence keeps running alongside a live conversation, and the prospect receives a nurture email the day after a real discussion about pricing.

The automation is working perfectly. The failure is that it has no visibility of the thing that should stop it, and the failure is silent — nobody reports being annoyed, they simply stop replying.

The fix is not less automation. It is a stop condition the automation can actually see, which usually means one field somebody updates. That is the pattern generally: the expensive part of automating a process is rarely the automation; it is giving the automation access to the facts that should change its behaviour.

The question worth asking

For anything in your business currently done by a person, and anything you are considering automating:

If this were done wrong, how would we find out, and how long would it take?

Fast and visible: automate it, and stop spending people on it.

Slow and silent: keep the person, and spend the automation budget on making the failure visible instead — a check, a reconciliation, an alert that fires on the condition rather than on the absence of one.

That second option is the one nobody considers, and it is frequently the best value available: not automating the work, but automating the discovery that the work went wrong.

---

Ganda Tech Services runs web, cloud, mobile and content operations for a group of Australian brands. Automation and systems work is handled through Cloud Geeks.