Automate the task that is repetitive, rule-based, frequent and low-judgement — usually reminders, follow-ups, re-typing the same record into a second system, or routine reporting. Leave anything that needs judgement, carries regulatory risk, or changes every time it runs. The first automation should remove a known weekly cost, not demonstrate a tool.
Key takeaways
- Score candidate tasks on frequency, judgement, error cost, data readiness and who is affected — then start with the highest score, not the most interesting idea.
- The best first automation usually sits around an existing system rather than replacing it, which keeps the rollout short and avoids retraining anyone.
- Tasks that need judgement, handle exceptions, or carry regulatory risk should stay manual until the rule can be written down and reviewed.
- An automation nobody measures is indistinguishable from one that quietly stopped working.
Who this is for: Owners and operations leads at small businesses and professional practices deciding where automation is worth the investment.
Start with the task, not the tool
Most automation projects begin the wrong way round: someone sees a tool, likes it, and then goes looking for something to point it at. The result is usually a working automation attached to a problem nobody was actually paying for.
The useful starting point is a task your team already does by hand, repeatedly, that somebody could describe end to end without hedging. If the process cannot be written down in plain sentences, it is not ready to automate — it is ready to be documented.
- Who does this task, and how often does it actually happen?
- Can the rule be written down without the phrase it depends?
- What happens today when it goes wrong, and who notices?
- Where does the information already live — a system, a spreadsheet, or somebody's memory?
A scoring method for picking the first automation
Score each candidate task from 1 to 5 on the five factors below and add them up. A task scoring above 20 is usually worth automating first; anything below 12 is normally better left alone or documented properly before anyone builds anything.
| Factor | Scores 1 | Scores 5 |
|---|---|---|
| Frequency | Happens a few times a year | Happens several times a day |
| Judgement required | Every case is different | The rule is identical every time |
| Cost of getting it wrong | Serious, or hard to reverse | Minor, and easy to correct |
| Data readiness | Lives in notebooks and inboxes | Already in a system with an export or API |
| Who is affected | Nobody would notice an improvement | Someone loses hours to it every week |
What usually scores highest
Across most small businesses and practices, the same handful of tasks come out on top — not because they are exciting, but because they are frequent, rule-based and currently done by a person who has better things to do.
- Appointment reminders, recall cycles and confirmation messages
- Chasing the same documents from every new client or customer
- Re-typing one record into a second system that does not talk to the first
- Routine reports somebody rebuilds by hand every week or month
- Generating invoices, receipts and confirmations from data that already exists
- Routing an enquiry to the right person instead of leaving it in a shared inbox
What to leave alone, at least for now
Automation is good at repetition and bad at nuance. A process that quietly relies on somebody making a call each time will not survive being turned into a rule, and forcing it usually creates a worse problem than the one you started with.
- Anything where the right answer depends on context a system cannot see
- Exception handling — the cases that already need a human are the ones that will keep needing one
- Regulated communication or record-keeping that has not been reviewed by someone qualified
- One-off processes, however painful, since they will not repay the build
- Any process nobody has written down, because you would be automating an assumption
Automate around the system your team already trusts
The instinct is often to replace the old software at the same time. That turns a two-week improvement into a migration project, and it asks the team to learn a new system while their existing workload continues.
Reading from the current system and writing back to it is usually the shorter path. The clinical, financial or operational software stays exactly as it is, the automation sits around the outside, and nobody has to change how they work in order to benefit from it. If the existing system genuinely cannot be integrated with, that is a real finding — but confirm it before deciding to replace anything.
Where automation projects usually go wrong
The failure modes are consistent enough to plan around.
- 1Automating a broken process, so it now runs badly at speed and at scale.
- 2Building the automation nobody asked for because it was the most interesting one to build.
- 3Skipping the exception path, so the first unusual case stops the whole thing.
- 4Sending automated messages without a clear opt-out or a record of consent.
- 5Launching with no measurement, so a silent failure goes unnoticed for months.
A one-hour session to choose your first automation
Run this with the people who actually do the work, not only the people who manage it.
- 1List every manual task the team repeated in the last week — no filtering yet.
- 2Score each one against the five factors in the table above.
- 3Take the top three and write each process out as plain steps, including what happens when it goes wrong.
- 4Check where the data already lives and whether the existing system can be read from and written to.
- 5Pick one, agree what number will prove it worked, and agree who checks that number monthly.
How to use this guide with your team
Automation is an operations decision before it is a technology one. Walk the process with the person who performs it today, in the order they actually perform it, including the exceptions they handle without thinking about them.
Write the rule down in plain sentences before anyone builds anything. If the description needs the phrase it depends more than once, the process is not ready to automate — it is ready to be documented and agreed.
Decide in advance what evidence will show the automation is still working, and who checks it. An automation that fails quietly looks identical to one that is running, sometimes for months.
Practical next steps
Use the following actions as a short working session. Record decisions, owners and unresolved questions so the article becomes an implementation aid rather than passive reading.
- 1List the manual tasks repeated in the last week.
- 2Score each on frequency, judgement, error cost and data readiness.
- 3Write the highest-scoring process out as plain steps, including failure paths.
- 4Confirm the existing system can be read from and written to.
- 5Agree one measure of success and one owner who checks it.
Frequently asked questions
Do we need new software to automate a process?
Often not. If the information already lives in a system that can be read from and written to, the automation can sit around it. New software becomes necessary when the existing system genuinely cannot be integrated with — which is worth confirming rather than assuming.
How do we know an automation is still working?
Agree one number before you build it — messages delivered, slots refilled, hours returned, records synced — and give one person responsibility for checking it on a fixed schedule. An automation nobody measures looks identical whether it is running or silently failing.
Sources and further reading
Last reviewed: September 8, 2026
