When not to automate

We have every commercial reason to tell you to automate everything. And yet some of the most valuable conversations we have end with "don't build this yet."

Here's why. Automation is a multiplier. Point it at a process that works and it makes the good thing happen faster, more consistently, with fewer mistakes. Point it at a process that's broken and it makes the broken thing happen faster too — and with a new kind of authority, because now it's "the system."

Software doesn't fix a process. It locks one in.

A cautionary tale

A company we spoke with had automated its purchase approvals. The official policy was simple: anything over $500 needed a manager's sign-off.

The real process was different. Managers were stretched thin, so the team had a quiet workaround — ask in the hallway, get a nod, sort the paperwork later. It wasn't tidy, but orders went out on time.

Then the approval flow became software. Nothing moved without a click. Managers' queues filled up, the hallway nod stopped counting, and orders that used to take an hour took three days. Within a month the team had invented new workarounds: splitting orders to stay under the threshold, borrowing a manager's login on busy days.

The expensive part wasn't the build. It was discovering that the official process and the actual process were two different things — after launch, instead of before.

Four questions to ask first

Before automating anything, walk through these. They take an afternoon and can save you months.

1. Is the process stable, or still changing? If the way you handle this work shifted twice in the last six months, it will probably shift again — and every shift means rework. Automate what has settled. Leave what's still moving in human hands a little longer.

2. Is the volume real? A task that happens forty times a day is a strong candidate. A task that happens four times a month may cost more to build, host, and maintain than it will ever save. Count the actual occurrences for a few weeks. Gut feel inflates volume; tallies don't.

3. Are exceptions rare? Automation pays off when the happy path dominates. If a third of cases need a judgment call — a discount that depends on the customer, a delivery that depends on the weather — you're not removing work. You're building software that interrupts a person a third of the time and gets in their way the rest.

4. Does anyone own the process? Someone should be able to say "this is how it works, and here's why." If nobody can, you'd be encoding folklore — habits nobody chose and nobody can defend. A process without an owner is a process you don't understand yet, and software is an expensive way to find that out.

Four yeses, and automation will likely pay for itself quickly. A no or two doesn't kill the idea — it just tells you what to fix first. Stabilize the process, assign an owner, handle the exceptions on paper. Then automate.

Sometimes the answer isn't software

Now and then, discovery shows that the right deliverable is a one-page checklist, a shared spreadsheet with three rules, or a change in who approves what. No code at all.

That can feel like an anticlimax when you came in expecting a build. We see it differently. We named ourselves after questions because the asking is the part that creates the value. The build only matters if it's pointed at the right problem. And the honest answer to "should we automate this?" is sometimes "no," or "not yet."

When the answer is yes, the same questions make the software better: stable scope, real volume, a clear happy path, an owner who can tell you when something's off.

Start with the real process

So before your next automation project, ask one thing: what does this process actually look like — not in the policy document, but on a busy Tuesday afternoon?

If you're not sure, that's the place to start. Walk us through your busiest Tuesday — we'll help you figure out whether the fix is software, a checklist, or just a better question.