Three questions to ask before you automate anything

Automation has a marketing problem. Every tool promises to save you hours, and almost every one of them can, on the right task. The trouble is that the tool cannot tell you whether your task is the right one. That part is on you, and it is worth getting right, because a badly chosen automation costs more than the manual job it replaced.

So before you connect anything to anything, I want you to run the idea past three questions. They are simple on purpose. If you can answer them honestly, you usually know what to do.

1. How often does this pain actually happen?

Start with frequency, because frequency is where the savings live. A task that lands on your desk every week, or every day, is a task worth systemising. You feel it often, you will feel the relief often, and the time you spend building the fix gets paid back quickly.

A task that happens once a year is a different animal. It might be annoying. It might eat a whole afternoon when it comes around. But by the time you have designed the automation, tested it and remembered how it works twelve months later, you have spent more effort than the manual job ever asked of you. Some things are meant to be done by hand, slowly, once.

Be honest about how often the pain really shows up, not how loudly it complains when it does. We tend to over-value the dramatic one-off and ignore the small weekly grind, and the small weekly grind is almost always the better target. If you are not sure, keep a rough tally for a fortnight. The pattern shows itself fast.

2. What does the process cost you when it fails?

The second question is about the stakes, not the time. Every manual process fails sometimes. A step gets skipped, an email goes to the wrong person, a number gets typed in wrong. The question is what happens next.

For some tasks, a slip costs you a few minutes. You notice, you fix it, nobody else ever knows. Those tasks are low stakes, and low stakes changes the maths: you can automate them with a lighter touch, and you can live with the odd hiccup while you tune things.

Other tasks are quiet until the day they are not. A missed lodgement deadline, a client who does not get chased and walks away, a report that goes out with last month's figures. The hours are the small part of that cost. The missed deadline and the annoyed client are the real bill, and they do not show up on any timesheet.

When a process is high stakes, that is not a reason to avoid automating it. It is a reason to automate it properly, with a review step where a person checks the output before it reaches a client or a regulator. The stakes tell you how much care the build deserves. High stakes and high frequency together is the sweet spot: that is exactly the kind of work worth building a watched, reliable system around.

3. Who will watch the automation?

This is the question people skip, and it is the one that decides whether your automation is still useful in a year.

Software does not sit still. The apps you connect will change their menus, their pricing and their rules. A login expires. A form gets a new field. None of this is dramatic on the day it happens, and that is the danger. An unwatched workflow does not fail with an alarm. It rots quietly, and you find out weeks later when a client asks where their reminder went.

So decide up front who owns it. Name the person. It might be you, it might be someone on your team, it might be me on a retainer. What matters is that when something drifts, there is a clear answer to "whose job is it to fix this?" An automation without an operator is not a finished system. It is a system with a hidden expiry date.

If you cannot answer this question, that is useful information. It might mean the task is not ready to automate yet, or that you need to sort out who is accountable before you build anything at all.

Sometimes the answer is: do not automate this

Here is the part the tool vendors leave out. Sometimes you run these three questions and the honest answer is to leave the automation alone.

Often the reason is that the process underneath is a mess. If a task is confusing, full of exceptions and different every time you do it, automating it just makes the confusion run faster. You end up with a machine that reliably produces the wrong thing. The fix is not a workflow. The fix is to sort out the process first: cut the steps that do not earn their place, agree on how it should actually work, and write it down. Once a process is clean and repeatable, automating it is easy. Before that, it is guesswork.

None of this needs a big project or a consultant in the room. It needs a quiet ten minutes and three honest answers. How often, what it costs when it breaks, and who will watch it. Get those right and you will spend your automation budget on the handful of things that genuinely deserve it, and leave the rest alone with a clear conscience.