When automation makes your problem worse, and how to fix it first

You've got a process that's eating 8 to 12 hours a week. Someone is manually entering data, chasing approvals, or shuffling documents between tools. It feels like the perfect thing to automate. So you build a tool to do it faster.

Then the tool moves the bad data faster. It approves the wrong things on schedule. It files documents in the wrong folder every time, just more reliably.

Automation doesn't fix a broken process. It scales it.

Why broken processes break faster when automated

A process is broken when it includes steps that don't matter, logic that contradicts itself, or handoffs that lose information. When a person does the work, they catch these things. They skip the pointless step. They ask for clarification when the instruction is backwards. They notice the data is wrong and fix it before it goes further.

When a tool does the work, it does exactly what you told it to do. No judgment. No common sense. No mercy.

A dental clinic in Kelowna automated their patient intake form. The form asked for the patient's preferred contact method, but the automation always sent reminders by phone, regardless of the answer. The tool worked perfectly. It was just working on a process that didn't make sense. After three weeks of missed appointments and frustrated patients, they had to rebuild the automation and fix the form.

A property manager in Surrey automated rent collection emails. The process included a step where the manager manually reviewed each email before sending it. When they automated away that step to save time, the tool sent duplicate emails to tenants who had already paid, and sent eviction notices to accounts that were on a payment plan. The automation was fast and consistent. The process was wrong.

How to tell if your process is ready to automate

A process is ready to automate when:

• Every step serves a real purpose. You can explain why it exists, and the answer isn't "that's how we've always done it."
• The logic is consistent. If a customer is marked as "do not contact," they are never contacted, no exceptions.
• Information flows cleanly. Data doesn't get lost, re-entered, or contradicted between steps.
• A person doing the work can complete it without asking for clarification or making judgment calls.
• You've tested the logic with real examples, not just the happy path.

If you can't check all of those boxes, the process isn't ready. Automating it will be more expensive than fixing it first.

The work to do before you automate

Take 2 to 4 weeks to map and clean the process. Here's what that looks like:

Map it as it really works. Sit with the person doing the work. Watch them do it once. Ask them to walk you through what they do, why they do it, and where it gets stuck. Write down every step, including the ones they skip or do out of order. Most processes have 30 to 50% invisible steps that only the person doing it knows about.

An accounting firm in Burnaby thought their invoice filing process took 15 minutes per invoice. When they mapped it, they found that the accountant spent 5 minutes searching for the right client folder because the naming system was inconsistent. That step didn't exist on paper. It existed in reality.

Remove steps that don't matter. Go through the map and ask: Does this step change the outcome? If the answer is no, delete it. If the answer is "it's required for compliance," keep it. If the answer is "the boss likes it," dig deeper. Maybe the boss wants visibility; maybe you can give it to them a different way.

A logistics distributor in Calgary had a step where the dispatcher printed each route and initialed it before the driver left. It took 3 minutes per route, 15 to 20 times a day. The initials were meant to confirm the route was correct. But the driver was already checking it. The step was insurance against a mistake that the next step already caught. They removed it and saved an hour a day.

Fix the logic. Look for contradictions, missing conditions, and unclear rules. If the process says "send a reminder if the invoice is overdue" but doesn't define what overdue means, define it now. If it says "get approval from the manager" but doesn't say what happens if the manager is away, decide that now.

A 12-person software company in Gastown had a process for approving expenses. It said "manager approves, then finance approves." But if finance rejected it, it went back to the manager, but the manager didn't know that finance had a reason. The information was lost. They added a step: finance documents the reason for rejection and sends it to both the manager and the requester. The process got longer by 2 minutes per expense, but it stopped rejecting the same expense three times.

Test it with real examples. Take 10 recent cases and walk through the cleaned process. Does it work? Does anything get stuck? Does any step produce the wrong result? If it does, you've found the break before you automated it. Fix it now, while it's still cheap.

Where to start

• This week, pick one process and map it. Spend 90 minutes with the person doing the work. Ask them to show you, step by step, what they actually do. Write it down. Don't fix it yet. Just see it.

• Next, identify one step that doesn't matter. Look at your map and ask: if we removed this step, would the outcome change? If the answer is no, mark it for removal. You probably find at least one.

• Then, list the places where the logic breaks. What happens if the data is wrong? What if someone is away? What if the customer says no? Write down the gaps. These are the things that make the process fragile. Fix them before you automate.