Automation has a reputation for saving time, and it often does. But I have also seen automation projects that made things worse: a script that quietly duplicated invoices for a month, a bot that stopped working when a website changed its layout and nobody noticed for a week, an elaborate system built to speed up a step that should not have existed at all.

The difference between those outcomes and the good ones is almost never the technology. It is the thinking done before anyone writes code. This checklist is the one I work through with clients before we automate anything. You can use it yourself, with or without a developer.

1. Can you describe the process in plain steps?

Write down what happens, from the trigger to the end result, in simple numbered steps. Who does each one? What do they look at? What do they decide? Which system do they open?

If this is difficult, that is useful information. A process that nobody can describe cannot be automated reliably, and an automated version of a confused process is just a faster way to be confused. Do the writing with the person who actually performs the task, not only with their manager. The real process, with its workarounds, lives with them.

2. Should this step exist at all?

Before speeding up a step, ask whether it is needed. Many manual tasks exist only because of an old system, an old rule or a report that nobody reads. Removing a step is cheaper and more reliable than automating it. This is the single most valuable question on the list, and it is the one that most often gets skipped.

3. Is it repetitive, rule-based and frequent enough?

Good candidates share three traits. They happen often, or take a lot of time when they do. They follow rules that you could write down. And their inputs arrive in a digital form: a file, an email, a database record, a form submission.

Poor candidates depend heavily on judgement, vary every time, or happen once a year. A task done rarely is usually not worth automating, unless it is high risk and easy to get wrong.

4. What does “correct” look like?

Define success in a way you can check. For a data import: every row accounted for, totals matching the source. For a report: the same figures that a careful person would produce. For an email filing task: every message in the right folder, with exceptions flagged.

Without a clear definition, you cannot test the automation, and you cannot tell later whether it is still working.

5. How clean is the data?

Automation amplifies whatever it is given. If customer names are spelled five ways, dates are in mixed formats and some fields are free text, the automation will either fail or produce confident nonsense. Look at a real sample, not a tidy example, and note the mess. Sometimes a cleaning step is the first piece of automation to build. Sometimes the right first step is to fix how data is entered.

6. What are the exceptions?

Every process has awkward cases: the customer with two addresses, the invoice in a different currency, the file that arrives half complete. Ask the people who do the work, “What goes wrong?” and “What do you do when it does?” Make a list.

For each exception, decide: should the automation handle it, or hand it to a person? The best automation handles the common cases fully and passes the rest to a human with enough information to resolve them quickly. Trying to automate every exception is how projects grow out of control.

7. Where must a human stay in the loop?

Some actions are costly to get wrong: sending money, deleting records, messaging customers, changing prices. For these, consider an approval step. The automation prepares everything; a person reviews and clicks confirm. This keeps most of the time saving while limiting the damage of a mistake. You can loosen the control later, as trust grows.

8. How will the systems be connected?

Think about how the automation will reach the systems it needs.

  • An API is the best option: stable, documented, designed for programs. See our notes on API and systems integration.
  • Database access or file exports work well for reading data, but check that you are allowed to use them.
  • Automating the user interface, where software clicks through screens the way a person would, is a last resort. It works, but it is fragile and needs more monitoring.

Also consider who owns each system. Some vendors restrict automated access, or charge for API use. It is better to know before you build.

9. What happens when it fails?

It will fail eventually. A password expires, a supplier changes a file format, a server restarts at the wrong moment. The question is whether you will find out.

Decide in advance:

  • How will failures be reported, and to whom?
  • What does the automation do when it is unsure: stop, retry or skip?
  • Is it safe to run again? A well-built job can be re-run without creating duplicates.
  • Is there a log that shows what was done, and when?

Silent failure is the real enemy. A job that fails loudly is an inconvenience. A job that fails silently is a risk.

10. Where do the credentials and sensitive data live?

Automation usually needs logins or keys. They should be stored securely, outside the code, with the minimum access needed. Use separate accounts for automation where possible, so you can see what it did and switch it off without affecting a person. If personal or confidential data is involved, check what you are obliged to do with it, and tell the developer at the start.

11. Who will look after it?

Someone must own the automation after it is built: know what it does, where it runs, and who to call when it stops. Ask for short documentation covering how to run it, how to check it, and how to change it. If the original builder disappears, the next person should be able to take over. Our maintenance and support service exists for exactly this reason.

12. Should AI be involved?

Large language models can help with tasks that rules cannot, such as reading messy documents, classifying requests or drafting text. They also introduce uncertainty: they can be wrong in ways that look convincing. If you use AI in a process, keep a human review for anything important, and test it against real examples before trusting it. We discuss this in our AI integration work.

13. Start small, and prove it

Pick one process, automate the core of it, and run it alongside the manual version for a while. Compare the results. Fix what differs. Then widen the scope. This builds confidence, and it shows quickly whether the idea is worth continuing. A small, reliable automation that people trust is worth far more than an ambitious one that nobody believes.

In short

If you can describe the process, justify each step, define a correct result, handle the exceptions, keep a person in charge of risky actions, and know who owns it afterwards, automation is likely to pay off. If several of those are missing, the best next step is a conversation, not code.

That conversation is what our free initial consultation is for. Describe the process, and we will tell you honestly whether it is worth automating and how we would approach it. Read more about our business process automation service, or get in touch.