A real automation has a clear input, a clear output, and an unambiguous exit. A half-built workflow has steps that ‘usually’ work and a person quietly cleaning up at the end. The second one is far more common — and far more expensive over a year — than most teams realise. Here’s how to tell which one you’ve got.

Three signs your ‘automation’ is actually half-built

First: someone, somewhere, has a calendar reminder to check it. Real automations don’t need a 9am Monday reminder titled ‘Make sure the Monday report ran.’ If yours has one, it’s not automated. It’s automated-with-a-watcher, which is two-thirds of the cost of doing it manually.

Second: there is a documented ‘what to do when it fails’ procedure that involves steps a human takes. Real automations either succeed or alert. They don’t degrade quietly into ‘usually works.’ Third: nobody can describe what ‘done’ looks like for a single run. If you ask ‘how do you know the automation finished cleanly today?’ and the answer is ‘we’d notice if it didn’t’, it isn’t done; it’s monitored by accident.

Why this happens (and why no-code makes it worse)

Half-built workflows are usually built sincerely. Someone spent a weekend wiring up Zapier or Make.com or a low-code platform. The happy path works. The first edge case appears two weeks later — a malformed input, a 500 from an upstream API, a customer with a mid-month plan change — and rather than handle it, they add a manual review step. Six months in, the review step is the workflow.

No-code platforms accelerate this pattern because they make the happy path almost free and the unhappy path almost impossible. Adding ‘try/catch with retry, dead-letter queue, and alerting’ is awkward in a visual builder. Adding ‘send the failed runs to a human in Slack’ is two clicks. Predictably, the second pattern wins.

The exit criterion test

We use a single test to distinguish automation from half-built: can you state the exit criterion in one sentence, including the failure case? Real automations exit one of three ways: ‘the action completed successfully and was logged’; ‘the action could not complete and the system alerted the on-call channel’; ‘the action was deliberately skipped because the input did not match a known case, and the input was logged for review.’

Half-built workflows fail this test. The exit is something like ‘someone will check.’ That isn’t an exit criterion; it’s a coping mechanism. If you can’t write the exit criterion, you don’t have automation. You have a relay race with extra steps.

How we redesign half-built workflows

Three steps, in this order. First: name every place a human currently intervenes and ask why. Most are recoverable in code. Some are genuinely judgement calls and should stay (and should be made into proper review tasks rather than ad-hoc tap-on-the-shoulder events). Second: introduce real failure handling — a dead-letter queue, alerting, retries with sensible backoff, idempotency where it matters.

Third: write the exit criteria, in plain English, in a runbook. If the workflow can’t satisfy them, redesign until it can. This is usually 60% of the work in a redesign engagement: not new code, but giving the workflow proper edges. Once it has them, ongoing operational cost drops to roughly zero.

Get in touch

We do these redesigns as part of internal tools and automation. Typical engagement: 1 week to audit an existing half-built workflow, 1–2 weeks to redesign it. Usually pays back in 3–6 months from the recovered human time alone, before you count the avoided incidents.

If you have a workflow that ‘mostly works but someone has to check it’, that’s the workflow. Drop us a line with a one-paragraph description and we’ll tell you on a 30-minute call whether it’s worth redesigning.