The five questions I ask before recommending a single automation
Article image
I’ve made the mistake of moving too fast. Early in my consulting work, I’d arrive at a discovery session, hear about a problem, and immediately start mentally mapping the solution. Tool X for this, workflow Y for that, connect it all with Z. It was efficient in the sense that it felt productive. It was wrong in the sense that it often missed the point.
The best automation I’ve ever built for a client wasn’t the most technically impressive one. It was the one that solved the right problem at the right moment for the right team. And to get there, I’ve learned to slow down before I speed up. These are the five questions I ask — not in a scripted way, but in some form, always — before I recommend a single thing.
Question 01
What would happen if this process just… stopped?
This tells me how mission-critical the task actually is versus how painful it feels. Some processes are genuinely load-bearing — the business grinds to a halt without them. Others are habits. Automating a habit is very different from automating a dependency, and the two demand completely different approaches.
Question 02
Who owns this process right now, and do they want it to change?
Automation without buy-in from the people doing the work is usually automation that doesn’t get used. Or worse — it gets worked around. The person closest to the task almost always has information about edge cases and exceptions that doesn’t appear in any brief. Getting them involved early turns potential resistance into genuine ownership.
Question 03
What does “good” look like here — and how would you know if it wasn’t?
Most businesses have an intuitive sense of quality without a formal definition of it. This question forces that definition to the surface before we build anything. It also reveals what the monitoring and exception-handling needs to look like — because automation that can’t fail gracefully is a liability, not an asset.
Question 04
What’s the cost of getting this wrong?
Speed of implementation and tolerance for error are inversely related. A client billing process has almost zero tolerance — errors cost money and damage relationships. An internal reporting summary is forgiving — the team will notice a mistake and ask for a re-run. Understanding the error tolerance shapes everything: the tool choice, the testing requirements, the rollout approach.
Question 05
What would you do with the time this gives back?
This is the question that separates genuine transformation from theatre. If the answer is “I’m not sure” or “catch up on emails,” I’ll push back. Automation should unlock capacity for something specific — something higher-value that the person or team is currently unable to do because they’re stuck on the thing we’re about to remove. If that higher-value activity doesn’t exist yet, we should design it first.
The goal was never to do the same things faster. It was always to free up the people to do the things that actually move the business forward.
These questions don’t guarantee a perfect outcome. Nothing does. But in my experience, the businesses that work through them honestly — before touching a single tool — build automations that stick. They build things the team actually uses, that solve real problems, and that create compounding value over time rather than a short-term fix.
If you’re thinking about where automation fits in your business, this is the kind of conversation I find genuinely useful to have early. It takes an hour. The clarity it creates is usually worth a lot more than that.