How to Automate This: A Practical Guide to Deciding What to Automate First in Your Business

Most business owners who start looking into automation ask the wrong first question. They ask, "which tool should I use?" before they have answered a more basic one: "what, exactly, should I be automating?" Get that second question wrong and the tool does not matter. You end up with a fast, well-built system that automates the wrong step, or worse, one that automates a process that was never working properly to begin with.

This guide is the starting point for that decision. It is not a list of software recommendations. It is a way of thinking through what is actually worth automating in a service business, what to leave alone, and in what order to tackle the rest. If you run a business with five to fifty people, most of what follows will apply directly, whether you are in professional services, trades, healthcare admin, recruitment, retail operations, or anything in between.

Start by separating two very different kinds of work

Every business is a mix of two categories of task, and they respond to automation completely differently.

The first category is repetitive, rule-based, and high-volume. Someone does the same thing, in roughly the same order, dozens or hundreds of times a month. An invoice gets generated the same way each time. A new lead gets the same first three follow-up messages. A candidate's CV gets checked against the same basic criteria before anyone looks at it properly. These tasks follow rules. The rules might be a little messy or inconsistently applied by different staff members, but they exist, and a computer can be taught to follow them consistently.

The second category needs genuine judgment. A client is upset and the reason is not obvious from the ticket. A candidate looks strong on paper but something in the interview does not sit right. A pricing decision depends on a relationship, a history, a read of the room. These tasks are not rule-based. They depend on context, experience, and a person weighing several things at once that were never written down as a rule because they cannot be.

The mistake we see most often is business owners trying to automate the second category because it feels like the more valuable use of a system, or trying to remove a human from a step where the human's judgment was the entire point of the step. Automation does its best work on the first category. It takes the repetitive load off your team so the people doing judgment-based work have more time and fewer interruptions to do it well.

A quick test: if you handed the task to five different competent staff members and they would all do it the same way, it is probably automatable. If five competent staff members would reasonably do it five different ways depending on the situation, it needs a person, at least for now.

The mistake that wastes the most money: automating a broken process

Automation only works when you fix the broken process first and train the team to actually use what was built. Bolt technology onto a broken process and you just make the mess move faster.

This is the single most expensive mistake we see, and it is almost never caught before the build starts, because the business owner is not thinking about the process at all. They are thinking about the pain: invoices going out late, leads going cold, candidates falling through the cracks. The instinct is to buy or build a tool that touches that pain point directly.

But a process that is inconsistent, undocumented, or dependent on one person's memory does not become consistent because you added software to it. It becomes an inconsistent process that now runs faster and with less visibility into where it is breaking. If your invoicing process currently has three different people deciding three different things about when an invoice goes out, automating the sending step just means the wrong invoices go out faster and with more confidence behind them.

Before you automate anything, you need a clear, current, accurate picture of how the process actually runs today, not how it is supposed to run according to the induction manual nobody has opened in two years. That picture usually reveals two or three points where the process is genuinely broken: a step that gets skipped under time pressure, a handoff where information gets lost, a decision that different people make differently with no one noticing. Fix those first, even if the fix is nothing more than agreeing on one version of the process in a room with the people who run it. Only once the process is one process, not three, is it worth automating.

A practical framework for deciding what to automate first

Once you have a shortlist of candidate processes that are genuinely rule-based and already reasonably consistent, you need a way to rank them. We use three questions, applied in this order.

1. What costs the most time or money right now?

Look at frequency multiplied by effort, not just how painful a task feels. A task that happens twice a week and takes an hour each time costs more over a year than a task that happens once a day and takes five minutes, even though the daily one feels more constant and more annoying. Add up the actual hours a task consumes across the whole team in a month, not just for the one person who complains about it loudest. If a task is also causing you to lose money directly, through late invoices, missed follow-ups, or lost candidates, weight it higher again. Time and money together should point you toward the two or three processes that matter most, out of everything you could theoretically automate.

2. What is easiest to get right?

Not every high-value process is a good place to start. Some processes touch many systems, involve several departments, or depend on data that is currently scattered across spreadsheets, someone's inbox, and a paper form. These are worth automating eventually, but they carry more risk and take longer to build properly. Look for processes where the inputs are already fairly clean, the number of people involved is small, and the steps are well understood by everyone who does the work. Early wins matter, not because they are the most valuable projects on paper, but because they prove the approach works, build confidence in the team, and give you a working example to point to when you take on something harder.

3. What has the clearest success criteria?

You need to know, before you start, what "working" looks like. Can you count it? Fewer overdue invoices. Faster first response to a new lead. Fewer candidates who go quiet because no one followed up. A process with a clear, countable outcome is easier to build correctly and easier to prove was worth the investment. A process where success is vague, "better communication" or "smoother operations", is much harder to automate well because you cannot tell if the build actually achieved anything, and neither can the team using it.

Score your shortlist against these three questions and you will usually find one or two processes rise clearly to the top. That is where to start, not with whichever process happens to be the most talked about in the business this month.

Common failure modes, and how to avoid each one

We have rebuilt automations that other providers set up, and the failures cluster around a small number of causes.

Automating without buy-in. If the people who currently do the task were not consulted about how it should work once automated, they will find reasons not to trust it, and they will quietly keep doing the old manual version alongside it, which defeats the purpose entirely and creates two versions of the truth. The people doing the work know where the process actually breaks down in ways that do not show up in a flowchart. Involve them from the start, not as a courtesy but because they have information you need.

Automating the wrong step. Teams often automate the most visible part of a process rather than the part that is actually costing time or causing errors. Sending a follow-up email automatically feels productive, but if the real problem is that leads sit unassigned for two days before anyone even sees them, you have automated a step that was never the bottleneck.

No plan for maintenance. Automated systems are not "set and forget." Pricing changes, suppliers change, a form field gets renamed, a staff member who understood the system leaves. Without someone responsible for noticing when a system needs updating, and without documentation of how it was built, automations quietly degrade until someone notices a customer complaint or a financial discrepancy months later. Every build needs an owner inside the business, not just an external provider on standby.

Treating training as optional. A system that the team does not understand gets used incorrectly, ignored, or blamed for problems it did not cause. This is the exact reason a proper handover matters as much as the build itself. It is also why, if a business wants its whole team genuinely comfortable working with AI and automation day to day, that is a deeper engagement than a single build's handover, and worth treating as its own project.

How the Assess stage applies to this exact decision

Everything above, working out what is rule-based versus judgment-based, fixing the process before automating it, ranking candidates by cost, ease, and clarity of success criteria, is the Assess stage of the Claro Build Framework in practice. Assess exists because recommending a build before understanding what is actually happening in a business produces exactly the failure modes described above. It comes before Design, Build, and Sustain for a reason: everything downstream depends on getting this part right.

For businesses who are not sure where to start, or who suspect several processes need attention and cannot tell which one matters most, we run the Assess stage as a standalone engagement, which we call an Audit. It is a structured look at how work actually moves through your business, done separately from any commitment to build anything. The output is a prioritised, honest picture of what is costing you time and money, what is genuinely automatable, and what needs to be fixed before it is touched at all. Some businesses take that picture and build with us. Some take it and use it on their own. Either way, it replaces guesswork with a clear starting point.

What this looks like across different parts of a business

The principles in this guide apply the same way whatever part of the business you are looking at, but the specific judgment calls differ by workflow. Invoicing has its own particular failure points around approval steps and payment terms. Lead follow-up has its own questions about timing and personalisation versus consistency. Candidate screening involves fairness and legal considerations that a generic automation guide will not cover. Subscription renewals, customer support, and payments each carry their own version of the rule-based-versus-judgment split described earlier, along with their own common mistakes.

This guide is the anchor for a series that goes deeper into each of those specific workflows, covering exactly what to automate, what to leave to a person, and where the common traps sit in each one. If you run teams handling any of these processes, those workflow-specific guides are the next step after this one. You will also find broader context on how automation fits into the rest of your operations in our operations systems guide, on what AI actually is and is not in practical terms in our AI explained simply guide, and on preparing your team for these changes in our team and people guide. If you want to see how this plays out in businesses similar to yours, our industry spotlights cover sector-specific detail, and our case studies show completed builds end to end.

A short checklist before you commit to anything

• Is this task genuinely rule-based, or does it need judgment that would be lost if automated?
• Is the underlying process already consistent, or does it need to be fixed and agreed first?
• Have the people who currently do this work been part of the decision?
• Do you know what "working" will look like in numbers, before you start?
• Does this rank near the top on time or money cost, relative to how difficult it will be to build correctly?
• Who inside the business will own this system once it is live, and who will notice if it breaks?

If you can answer all six honestly, you have found a strong candidate to automate first. If you cannot answer two or three of them, that is not a reason to abandon automation altogether, it is a sign you need to spend more time in the Assess stage before committing to a build.

Deciding what to automate first is not really a technology decision. It is an operations decision, made with a clear-eyed look at how your business actually runs today, not how you wish it ran. Get that part right and the tools you choose afterward become far less risky, because you already know exactly what they need to do. If you're not sure where your own business fits, that's exactly what an Assess-stage conversation is for.