Where to start automating a business that already works
Almost everything written about small business automation is addressed to a business in trouble. Yours is not. It pays its people, it has customers who come back, and the reason nothing is written down is that it never had to be.
That changes the question. You are looking for the order to do things in, because you can only afford to be wrong about the small ones.
Why does the usual advice not fit a business that already works?
Because it hands you a menu when what you need is a sequence. Every guide on the subject lists departments, invoicing, scheduling, marketing, payroll, and leaves you to guess which one comes first and what each one depends on.
The advice also assumes the obstacle is that you do not know what software can do. In a working business the obstacle is usually the opposite: the thing you would automate exists only as a habit, and habits have no edges a program can grip.
The oldest mistake in this field is older than the subscription model: taking the way things are done, leaving it exactly as it is, and using software to do it faster. The habit gets mechanised, edges and all, and the disappointing result gets blamed on the tool.
One thing in your favour before any of this starts. A business of five people can change how it works in an afternoon, and can see the result by Friday. That is the single biggest advantage a small business has in this subject, and it is the one that large companies pay consultants to imitate.
If your question is whether a particular process should be automated at all, that is a different article: when not to automate has the five tests. This one assumes you have decided to start and cannot work out where.
What has to exist before software can help?
A process has to have an address. Software cannot act on something that lives only in one person's head: he knows, on a Tuesday, that the roofing supplier goes late in August, and that is the entire system.
There is a ladder underneath all of this, and most businesses are further down it than they think.
| Rung | What it means | What it usually looks like |
|---|---|---|
| 1. In one head | One person knows. Nobody else can do it or check it | "Ask Dave, he'll know" |
| 2. Written down | It exists on paper, wherever its author left it | The day book, the notebook in the van, a wall planner |
| 3. Shared | Other people read it as part of the job | A WhatsApp group, a shared Gmail inbox, a spreadsheet on one desktop |
| 4. Structured | Same fields every time, so two entries can be compared | A sheet with columns nobody improvises in |
| 5. Automated | Software does a step of it | A reminder that goes out without anyone remembering |
Each rung only holds if the one below it does. Buy a system for a business sitting on rung one and you get an expensive rung one, because staff go on asking the person who knows. Plenty of businesses are stuck on rung three, which feels modern and is not: a WhatsApp group is shared, and nothing in it can be counted.
Getting from the first rung to the second takes about an hour a week and no software at all. Three steps:
- Sit with the person while they work and write it down yourself. Asking them to write it produces the version they think you want.
- Write down decisions, not actions. "Order more when the second shelf is empty" is a rule a system can hold. "Phone the supplier" is not.
- Show them a draft with something wrong in it. People who cannot describe a process from memory will correct a wrong description in seconds.
How common is any of this? Nobody has measured it properly for businesses of this size, and saying so is better than repeating one of the invented figures that circulate. The safe assumption is that most working businesses have most of their processes on rung one or two, and that the ones on rung three or four got there by accident, because a tool happened to impose a format.
The middle rungs have a trap of their own: records that are kept and never read back. A defects log that is filled in every day and looked at by nobody is on rung four and pays nothing. Records only pay when somebody reads them back, so the question to ask of every log in the building is who reads it, and when.
How do you find out where the hours actually go?
Carry a notebook for five working days and mark every interruption. That is all there is to the method, and it beats any list of automation ideas you will be given, because it produces evidence about your business instead of somebody else's.
Two columns. In the first, every time you are interrupted, write what it was in four words. In the second, mark whether you were the only person who could have answered. At the end of the week, count.
Read the tally as a frequency table, not as a to-do list. What you are looking for is the same four words appearing eleven times. That repeat is the candidate, and it is almost never the thing that annoys you most. The annoying task tends to be rare and dramatic. The expensive one is small enough that you have stopped noticing you do it.
The total is usually bigger than owners guess. Add up the tally at the end of the week, then put the number next to the hours you spent that week on selling and on the work customers pay for. In most small businesses the admin column is the larger one, and nobody chose that.
That comparison is also the answer to "what do I do with the time". If admin is running at anything like the hours you spend selling, the hours you claw back have somewhere obvious to go, and if you have no plan for them the automation buys you a tidier week and nothing else.
Which process should you automate first?
Order by what depends on what, not by the size of the prize. The most valuable automation in your business is usually not the one you can do next, because it needs something that does not exist yet.
An example. Automated appointment reminders are a good idea in almost any business that books time. They need one calendar that everybody uses and one place where a customer's mobile number lives. If the numbers are spread across a phone, a wall diary and the back of a delivery note, then you have a contact-details project with a reminder's name on the invoice, and quoting it as a reminder job is how four weeks becomes four months.
So the first move is usually dull. One place for customer details. One calendar. One inbox the whole business can see. None of that is automation. Without it, automation has nothing to stand on.
The counter-question is fair: is the dull thing worth doing on its own? Often yes, because a shared contact list pays for itself in the week somebody is off sick. The arithmetic for the automation that follows is a separate matter, and we set it out in what automation costs a small business.
What should you deliberately leave alone?
Three categories, and none of them is about whether automation would work. Leave them because getting them wrong costs more than getting them right saves.
Money leaving the business. Payments, bank details, payroll. The failure mode here is money going to the wrong place quietly, with nobody noticing until the quarter closes.
Anything a customer meets on their worst day. Complaints, cancellations, and the call where you have to tell somebody the job slipped. A well-timed message on that day reads as being handled by a machine, and you will not hear about it. You will just stop hearing from them.
Whatever is currently fine. If a process works, has no queue behind it and nobody complains about it, leave it. Changing it spends your one unit of goodwill on something nobody asked for.
The first thing you change should be visibly better within a fortnight, or the second thing will be harder to get agreed.
What do you do about the paper?
Type up only what somebody asks about again. Everything else can stay on paper until it earns its place, and a fair amount of it should stay on paper forever.
The test is simple. If a note is written, read once and never consulted again, digitising it buys nothing. If a note is written and then looked up later, usually by somebody other than its author, that is the note that wants a system.
Retyping deserves more suspicion than it gets. Reading your own typing back is not a control: the eye sees what it meant to type. The only checks that catch retyping errors are the ones that involve a second source, either a second entry to compare against or a total that has to agree with something else.
Spreadsheets deserve the same suspicion. A spreadsheet nobody has ever checked tells you what somebody typed, and you are trusting it to tell you what happened. Pick any workbook the business relies on and trace three of its totals back to the cells they are built from; it is rare to get through all three without finding a formula that stops one row short.
So the evening ritual of re-typing the day's paper notes into a spreadsheet is a good candidate for a first project, and not because of the twenty minutes. Those twenty minutes are where the mistakes get made.
How do you change something without stopping the shop?
Run both versions at once, for a fixed period, and decide in advance what would make you stop. Small businesses rarely get a pilot phase because nobody offers them one, and it is the cheapest thing on this list.
In order:
- Pick one process and one change. Two changes at once and you will not know which one caused what.
- Keep the old way running. The paper book stays on the counter. Nobody is told to abandon it.
- Set a date to compare. Two weeks is usually enough for something daily.
- Write down now what "it worked" means. Not "it went well". Something like: the till and the sheet agree at the end of the day, and nobody had to ask me anything about it.
- Write down what would make you stop. A customer affected, an evening spent fixing it, anyone quietly going back to paper on their own.
- Keep the way back. Turning it off should be a decision, not a project.
Point five is the one people skip. A change with no stop rule gets defended instead of reversed, and the business ends up carrying both systems for a year.
The other reason for parallel running is that automation does not announce its own failures. A workflow that stops firing looks exactly like a quiet week, which is a subject of its own in why automations fail silently.
What about the person whose memory is the system?
Start with something that makes their week easier, and never open with the word documentation. In most businesses of this size the blocker is not the software and not the budget. It is a person who is entirely right to be suspicious.
Usually it is the founder, the parent, or the office manager of twenty years. What they hear in "let's write down how you do this" is a valuation of their job, and they are not being paranoid. In a business of five people, a large share of what any one of them knows is known by nobody else, and the smaller the business the larger that share.
The risk underneath this is real and rarely discussed at the counter. Ask yourself which person the business could not open without on Monday if they were in hospital on Sunday night. Most owners can name them in a second, and most have never written down what that person carries. The knowledge that does the most damage when it walks out is the kind nobody documented, and there is no reliable way to measure how much of it there is. So the honest version of this is not a number. It is that the most valuable asset in the business is uninsured, uncounted, and goes home at six.
What works in practice is order. Take something that costs them time and gives them nothing: chasing a delivery, retyping the day book, answering the same question about opening hours for the fourth time that morning. Automate that first, badly if necessary, and let them see the week get shorter. The conversation about writing things down is much easier to have with somebody who has already got an evening back.
What the first three months actually look like
Roughly: one week watching, one week deciding, then one change at a time with a fortnight of parallel running each. That is two or three processes touched in a quarter, which sounds slow and is faster than the alternative.
Do you need to hire anyone for that? Not for the watching, the writing down or the tidying up, which is most of the work and all of the part only you can do. Outside help earns its place at the build, and it earns it faster when the person you hire is handed a written process instead of a conversation.
It is also the part everybody underestimates, and not for technical reasons. When a change of this kind runs late, the delay is almost never in the software. It is in who decides, who resists, and how the process has to be redrawn before a tool can hold it. Expect the delay there, and plan the calendar around people rather than around the build.
If you do only one thing from this article, do the notebook week. Five days, two columns, and at the end of it you are holding evidence about your own business rather than somebody else's average.
If you would rather not spend the first month working out the order on your own, that is what our audit is for. It costs $299 and takes three business days. It ends in a written map of your processes, with the value, difficulty and payback of each one marked, including the ones we think you should leave alone. The map is yours whether or not you hire us, and the fee comes off the project if you do. That is the process audit.