The first process worth automating in a small team

Ask a room of small business owners what they'd automate and you get the same answer nearly every time. They name the thing that annoys them most.

It's an understandable instinct and it's usually the wrong pick. The most annoying process is annoying because it's complicated, full of exceptions, and touched by four people who each do it differently. That makes a long first project with a lot of arguing in the middle and very little to show for a month.

We've watched a fair number of automation efforts stall, and the cause is nearly always the same. Not the tooling, not the budget. The wrong first process.

#The test

Four questions. A process needs a yes to all four before it's a sensible first project.

Does it happen a lot? Frequency beats size, and it isn't close. A two minute task done forty times a week costs eighty minutes weekly and a great deal of attention. A two hour task done monthly costs two hours. Owners consistently pick the second one because it feels bigger, then wonder why nothing changed.

Is the decision-making dull? If every instance needs someone to weigh something up, you're not automating a process, you're trying to automate a person's judgement. That comes later, if at all. What you want first is a task where the rules are boring and the same every time.

Is it already written down, or could it be in an afternoon? Not a policy document. The actual steps, in order, including what happens when something's missing. If nobody can write it down, that's not a blocker to note and move past. It's the finding. You don't have a process, you have a habit, and automating a habit produces a very fast way to do the wrong thing.

Does one person own it and want it fixed? This is the one people skip and it's the one that kills projects. An automation without an owner becomes an orphan. It runs for four months, something upstream changes, it starts failing quietly, and everyone routes around it until someone finally turns it off.

#What usually wins

Run that test honestly across a small operation and the answer is almost always one of three things.

Enquiry intake. Something arrives, whether by form, call, email or WhatsApp. It needs to become a record with consistent fields, get routed to the right person, and trigger an acknowledgement. High frequency, dull rules, one owner, and it's the front of everything else. When intake is inconsistent, every report downstream is quietly wrong.

Reminders and confirmations. Appointment confirmations, day-before reminders, the follow-up when a quote goes unanswered for a week. Nobody enjoys sending these, they get skipped when things are busy, and skipping them is expensive. Most no-shows are not people changing their minds, they're people forgetting.

Copying data between two systems. The job lands in one place and someone retypes it somewhere else. This one is worth finding because it hides. It rarely appears on anyone's list of problems, since it's been part of the job so long that it stopped looking like a task. Ask who retypes what, and watch the answers pile up.

None of those are exciting. That's the point. The first project is where you learn how your own business actually runs, and you want that lesson to be cheap.

#Map what happens, not what is supposed to happen

Once you've picked one, sit with the person who does it and watch them do it three times. Do not ask them to describe it. Watch.

The gap between the described process and the observed one is where all the useful information lives. There will be a spreadsheet nobody mentioned. Step four turns out to happen only on Tuesdays. Somebody checks a thing by hand every time because of an error that happened in 2023 and has not recurred since.

Those workarounds are not noise. They're the real process, and they encode knowledge that isn't anywhere else. Automate the official version and you'll break something that the workaround was quietly holding together.

Write down the exceptions as you go. In our experience the exception list is longer than the main path, and about a third of it turns out to be unnecessary once someone finally looks at it properly. Deleting a rule is cheaper than automating it.

#The part that takes the time

Here's what surprises people about a first project. The building is quick. Connecting two systems and moving structured data between them is not hard, and it's not where the weeks go.

The weeks go on decisions nobody had to make before, because a human was absorbing them in silence. What happens on a bank holiday. Who gets it when the usual person is on leave. What counts as a duplicate.

Then the sharper ones. Whether a missing phone number stops the whole thing or lets it through with a flag. How many times to retry before telling someone. Whether a failure should be loud, which annoys people, or quiet, which is how automations die.

A person handles all of that without noticing they are doing it. An automation needs an answer for each one, in advance, in writing. That is the real work, and it is also most of the value. A team that has agreed those rules is running better than one that has not, even if you stopped before building anything.

Budget for it. Two to four weeks for something narrow, most of it spent in conversation rather than in a tool.

One more thing worth deciding early: who finds out when it breaks, and how. Not a log file. A message to a named person, with enough context to act on. An automation nobody is watching is a liability dressed as an asset, and the first sign of trouble is usually a customer rather than a dashboard.

#Where this goes wrong

Two honest failure modes.

The first is automating something that shouldn't exist. Every business has a report nobody reads and an approval step added after an incident that everyone has since forgotten. Automating those makes them permanent, and a fast pointless process is harder to kill than a slow one, because now it's infrastructure.

The second is starting with a tool. Someone buys a platform, then goes looking for something to run on it. You end up shaping the process around what the tool finds easy, which is a bad trade. Pick the process, agree the rules, then choose whatever connects the systems you already have. We build workflow automation across the tools clients already pay for for exactly this reason, and it isn't a compromise. Rip and replace is a second project pretending to be part of the first.

There's also a scale caveat worth naming. If a process runs three times a month, the honest answer may be that automating it isn't worth anyone's time. Write it down properly, make sure two people know how to do it, and spend the effort somewhere with more volume.

#Decide the measure before you build

Pick one number and record it for two weeks before anything changes. Minutes per week on the task, or error rate, or how long a job sits waiting on a person.

Without a baseline you get opinions, and opinions about automation track how everyone felt about the project rather than what it did. A team that enjoyed the process will say it went well. A team that had a difficult month will say it did nothing, and both will be describing the same result.

The number also settles the question of whether to do the next one. That decision is much easier when you can say the last project gave back six hours a week than when you can only say it went fine.

#Where to start this week

Take one week and count. Not estimate, count. Every time someone in the team does something repetitive, they note what it was and roughly how long it took. A shared note is enough.

At the end of the week, sort by frequency rather than by how much people complained. Run the four questions against the top three. Usually one of them is obviously the answer, and it's usually duller than anyone hoped.

Then do that one, properly, before starting anything else. A first automation that works and has an owner earns you the right to do the next one. Three half-finished ones teach the team that this never works here.

If you'd rather have someone walk the process with you, tell us what your week actually looks like. We'll map what's worth automating first and say plainly if the answer is nothing yet. The same thinking applies to the phones, which we covered in why lead response time decides who gets the job.