Automating a broken process makes it worse, faster

The failure is sequencing, not tooling

When an automation project underdelivers, the post-mortem tends to focus on the platform. The tool was wrong, the integration was weak, the vendor oversold. Occasionally true. More often the process being automated was never specified clearly enough to automate, and the project inherited every ambiguity in it.

An undocumented process survives because people compensate for it. Someone knows that invoices from a particular supplier need a manual adjustment. Someone else knows which field to ignore. That compensation is invisible until it is removed, and automation removes it.

Three tests before automating anything

Before committing to automate a task, it should pass all three.

1. Is it genuinely rules-based?

A task is rules-based if a competent person following written instructions would reach the same answer every time. If two experienced staff members would handle the same case differently and both be defensible, the task depends on judgment. Judgment tasks can be assisted, but automating the decision itself produces confident, consistent, wrong answers.

2. Is the current process documented and correct?

Not "does a procedure document exist" — does the documented procedure match what people actually do? The gap between the two is where automation projects fail. Where the documented process is wrong, fix the process first. Where the real process is undocumented, document it before touching the tooling.

3. Is the volume high enough to matter?

Measure the hours consumed per week, by whom, at what cost. Automating a task that occupies two hours a month is a hobby. The candidates worth pursuing are the ones where trained staff spend meaningful time on mechanical work — data entry, reconciliation, re-keying the same information into a second system, assembling reports by hand.

Design the failure mode before the happy path

Every automated process will encounter cases it cannot handle. The design question is not whether that happens but what happens when it does. Three things need defining up front:

• Confidence threshold. Below what certainty does the system stop and ask rather than proceed?
• Escalation path. Who receives the exception, in what queue, with what context attached?
• Audit trail. What record exists of what the system decided and why, so a disputed outcome can be reconstructed?

Systems built without these fail silently. The errors accumulate for weeks before anyone notices, and by then the affected records are downstream in the financials.

Where automation reliably earns its cost

Across construction, medical, pharmaceutical and fiber optic network operations, the same categories come up:

• Document capture. Invoices, timesheets, purchase orders, field reports — high volume, structured, currently keyed by hand.
• Reconciliation. Matching transactions across systems, with exceptions routed to a person and matches cleared automatically.
• Reporting assembly. Reports that currently require someone to export, merge and format before anyone can read them.
• Routing and handoffs. Moving work between people according to defined rules, so nothing waits in an inbox because the recipient was unaware it arrived.

What these share is that the rules already exist. Automation is not inventing the logic — it is executing logic the business already follows, consistently and without consuming a salary to do it.

The practical sequence

1. Measure where hours actually go, by task, for two to four weeks. Estimates are unreliable here.
2. Document the real process for the highest-cost tasks, including the informal compensation people perform.
3. Redesign — remove steps, eliminate rework, fix the handoffs. A meaningful share of the benefit lands here, before any technology is bought.
4. Automate what remains and is rules-based, with the failure mode designed first.
5. Instrument the result so degradation is visible in the numbers rather than discovered by a complaint.

Fix the process, then automate it. Automating first locks the current process in place and makes it more expensive to change.