Automate the process, not the mess

You have a spreadsheet that lives in three places. Your team enters data into it, someone else copies it somewhere else, and a third person checks it before it goes to the accountant. It takes about six hours a week, and everyone agrees it's tedious.

So you think: let's automate this.

Then you build a tool that automatically copies data from place one to place two, and sends alerts when it's done. The tool works perfectly. But now the data arrives faster than anyone can check it. The person who was supposed to validate it didn't realize they were still supposed to, so bad entries slip through. The accountant calls with questions. The whole thing falls apart, except now it's automated and therefore harder to see where it broke.

This is what happens when you automate a process that was already broken. You don't fix the mess, you just speed it up.

The real cost of automating the wrong thing

A property manager in Surrey had a tenant request workflow that looked simple on paper. Tenants emailed a request. The office staff logged it into a system. A supervisor reviewed it. Work got done.

Except in reality, some requests got logged twice because the tenant didn't know if their email went through. Some got lost because the supervisor was on vacation and nobody knew who was covering. Some sat for two weeks because the definition of "urgent" was different for everyone.

When they automated the logging step, they created a tool that perfectly captured every duplicate request and every orphaned one. The automation worked. The process didn't. They ended up with a faster, more visible disaster.

The fix took three weeks of untangling before they could automate anything. They had to decide: do tenants submit once or can they resubmit. Who covers for the supervisor. What urgent actually means. Only then did the automation help.

This is the pattern we see most often. A team has a process that feels broken. They assume the solution is speed. Usually, the solution is clarity.

What to look for before you automate

Before you hand any work to AI or any other automation tool, ask yourself these questions:

Does everyone do it the same way? If three people do a task three different ways, automating will lock in one way and break the other two. A dental clinic in Kelowna had three hygienists who each had their own system for prepping patient files. When they tried to automate prep, it worked for one hygienist and created extra work for the other two. The real fix was agreeing on one prep method first.

Is anyone skipping steps on purpose? Sometimes a step exists on paper but gets skipped because it doesn't matter or takes too long. A plumber in Richmond had an invoice approval step that was supposed to catch mistakes, but the owner was approving them without reading them because she trusted the estimator. Automating the approval step didn't help because the real decision was already made. She had to either care about the approval or remove it.

Does the person doing it know why? If someone does a task but can't explain why, that's a sign the process has drifted. An accounting firm in Burnaby had staff copying data into a secondary system that nobody actually used. They kept doing it because it was always done that way. The automation they wanted to build would have preserved a pointless task. They had to kill it first.

What happens when something goes wrong? If the process has no backup plan, automation will make failures faster and more visible. A distributor in Calgary automated their order entry and then had no way to handle the 2% of orders that had unusual requirements. The automation worked, but it created a new bottleneck. They had to build a human override step first.

How to fix the process before you automate

Take a week. Do this in order.

Day one: Watch it happen. Have someone spend a full day observing how the work actually gets done. Not how it's supposed to happen. How it actually happens. Write down every step, every pause, every place where someone decides what to do next. Don't judge it yet. Just see it.

Days two and three: Talk to the people doing it. Ask them why each step exists. Ask them what they'd change if they could. Ask them what breaks most often. Write it down. You'll find out that some steps are there for reasons you didn't know about, and some steps exist for no reason at all.

Days four and five: Redesign on paper. Based on what you learned, draw the process as it should work. Remove steps that don't matter. Combine steps that can be combined. Add decision points where someone needs to choose. Keep it simple enough that you can explain it in five minutes.

End of week: Get agreement. Show your redesigned process to the people who do the work and the people who depend on the output. Ask them if this is how it should work. Listen to the objections. Fix them. Get them to agree that this is the right way, not just a faster way.

Now you have a process worth automating. Now you know what to hand off to a tool and what to keep a person doing.

Where to start

• Pick one process that takes 5 to 15 hours a week and involves at least two people. Have someone spend two days documenting how it actually works right now, step by step.

• Gather your team for an hour and ask: "What would make this easier?" and "What steps could we remove?" Write down their answers. You'll find at least one thing that nobody needs anymore.

• Draw the process as you think it should work, show it to the people who do it, and ask them if it's right. Fix what they tell you. Don't automate until everyone agrees the process itself makes sense.