Guide · Operations
What to Automate First in a Small Business
Choosing what to automate is a harder problem than building the automation, and it is the one that decides whether the effort pays back. The useful rule is not to automate what is hard — it is to automate what is repeated, unchanging, and already understood. Most of the disappointment in this area comes from automating a task that should have been deleted instead.
By Carlos Boluda · Updated · 8 min read
Delete, simplify, then automate — in that order
The fastest automation is removing the step. Before building anything, ask whether the task needs to exist at all: who reads that report, what happens if that form is not filled in, when did anyone last look at that spreadsheet.
A surprising number of recurring tasks in small businesses are left over from a situation that no longer applies — a client who left, a process built around a member of staff who has gone, a check introduced after a problem that was fixed years ago.
Automating one of those is worse than leaving it manual. A manual task that nobody needs eventually stops happening. An automated one runs forever, silently, and you now maintain it.
The three numbers that decide it
For each candidate task, write down three things: how often it happens, how long it takes each time, and what it costs when it goes wrong.
Frequency matters more than duration. A two-minute task done every day is over eight hours a year; a two-hour task done twice a year is not worth touching no matter how tedious it is. People consistently choose the annoying rare task over the trivial daily one, and it is the wrong choice.
The third number is the one that upgrades a task from optional to urgent. Forgetting to follow up on an enquiry costs a job. Sending an invoice to the wrong address costs a month of cash flow. Where the error is expensive, automate even if the time saving is small — you are buying consistency, not minutes.
Never automate a process you have not run by hand
If you cannot describe the task as a list of steps with every exception named, you do not understand it well enough to automate it, and what you will build is an automation of the version you imagine.
Exceptions are where this goes wrong. The process is fine until the customer pays in two instalments, or the appointment is for someone else, or the order has one item out of stock. Those cases exist in the head of whoever does the job and rarely in the description of it.
Run the task manually with a written checklist for a couple of weeks first. Every time you deviate from the checklist, write down why. Those deviations are the actual specification.
The maintenance cost nobody counts
Every automation is a small piece of software that depends on other people's services, and those services change on a schedule you do not control. Interfaces get updated, logins expire, a provider changes a format, a rule changes.
This means an automation is not a one-off cost. It is a subscription paid in attention, and the bill arrives at the least convenient moment, because things break when volumes are high.
The practical implication is to prefer boring tools over clever ones, prefer fewer automations over more, and prefer buying something maintained by someone else over building something maintained by you. The cheapest automation is the one a vendor keeps working while you do other things.
Make failures loud
The dangerous failure is not the automation that breaks visibly. It is the one that stops quietly and is not missed for six weeks, by which time the follow-ups that did not go out are cold and the records that did not sync are wrong.
Anything running unattended needs to tell you when it did not run. A message when it fails, and ideally a short confirmation when it succeeds, so that silence itself becomes a signal rather than an assumption.
Then check it deliberately. A monthly look at whether the thing is still doing what it was built for takes ten minutes and catches the quiet failures before they compound.
Where most small businesses should actually start
The same three tasks come up repeatedly, and they are rarely the exciting ones: capturing enquiries so they cannot be lost, reminding customers about appointments, and asking for a review when the job is done.
All three are high frequency, entirely repetitive, and expensive to get wrong — a lost enquiry is a lost job, a forgotten appointment is a lost slot, an unasked review is a customer who would have said something good and was never given the chance.
None of them require building anything. All three exist as products that someone else maintains. Start there, live with it for a month, and only then look at whatever is next on the list.
Scoring a candidate task
| Question | Automate | Leave it |
|---|---|---|
| How often does it happen? | Daily or weekly | A few times a year |
| Does it change each time? | Identical every time | Needs judgement |
| What does an error cost? | A lost job or a bad payment | A minor annoyance |
| Do you understand every exception? | Yes, written down | Not yet — run it by hand first |
| Does the task need to exist? | Yes, someone uses the output | Delete it instead |
| Does a maintained product do it? | Buy it | Building is the last resort |
| Will you notice if it stops? | It alerts you | Do not run it unattended |
| How long does it take now? | Short and constant | Long and rare |
How to decide what to automate
- 01
List every recurring task for two weeks
Write them down as they happen, not from memory. Memory over-reports the annoying rare tasks and under-reports the small daily ones that actually consume the time.
- 02
Cross out the ones nobody needs
Ask who reads the output and what breaks if it stops. A manual task nobody needs dies on its own; an automated one runs forever and you maintain it.
- 03
Score what is left on frequency, variability and error cost
Frequency beats duration. A two-minute daily task outweighs a two-hour annual one, and people almost always pick the wrong one of those.
- 04
Run the winner by hand with a written checklist
For two weeks. Every deviation you write down is an exception your automation would otherwise have broken on.
- 05
Look for an existing product before building
Booking, invoicing, reminders and enquiry capture are all solved and maintained by someone else. Building is the last resort, not the first instinct.
- 06
Build in an alert for failure
Anything unattended must tell you when it did not run. The expensive failure is the silent one nobody notices for six weeks.
- 07
Live with one automation for a month before adding another
You will discover the exceptions you missed. Adding three at once means three simultaneous unknowns when something goes wrong.
- 08
Review every automation once a month
Ten minutes checking that each one is still doing what it was built for. This is where quiet failures get caught before they compound.
Frequently asked questions
What should a small business automate first?
Usually three things: capturing enquiries so none are lost, reminding customers about appointments, and asking for a review after the work. All three are frequent, entirely repetitive and expensive to get wrong, and all three exist as maintained products rather than things you have to build.
How do I know if a task is worth automating?
Score it on three things: how often it happens, whether it is identical every time, and what an error costs. Frequency matters most — a two-minute daily task consumes more of the year than a two-hour task done twice. Where errors are expensive, automate even if the time saved is small.
Is it better to build or buy automation?
Buy, for almost everything a small business needs. Booking, invoicing, reminders and enquiry capture are solved products maintained by someone else. Building means you maintain it, and the underlying services it depends on change on a schedule you do not control.
What is the most common automation mistake?
Automating a task that should have been deleted. A manual task nobody needs eventually stops happening on its own; an automated one runs forever and becomes something you maintain. Ask who uses the output before building anything.
Why do automations break?
Because they depend on other people's services, which change without consulting you — interfaces get updated, credentials expire, formats change. Every automation is a subscription paid in attention rather than a one-off task, which is why fewer and more boring is usually better.
How do I stop an automation failing silently?
Make it report. A message when it fails, and a short confirmation when it succeeds so that silence itself is a signal. Then check each one deliberately once a month. The costly failure is the one nobody notices for six weeks.