Field Notes · Running better systems

When should a small business automate a process?

Automate what happens often, the same way each time, and can be written down. Fix the process first, and keep a person where mistakes are expensive.

A cluttered office desk with ledgers, an in-tray and a calculator in window light.

Essay · · 4 min read · By Amalgament

Automate a process when it happens often, follows the same steps every time, and you can write those steps down on one page. If any of those is not true yet, fix the process first.

Four questions before you automate

A common reason automation fails is that it was pointed at the wrong process. Before you build anything, ask four questions about the task.

  • How often does it happen? Daily or weekly work pays back quickly. Something that happens twice a year is usually cheaper to do by hand with a checklist.
  • Is it the same every time? If the steps change depending on who does them, or on the client, an automation will lock in one version and break on the others.
  • Can you write the steps down? If the only description is "Maria knows how," the first job is to get it out of Maria's head and onto paper.
  • What does a mistake cost? A wrong internal report is an annoyance. A wrong invoice or a message to the wrong client is a bigger problem, and needs a person checking it.

A task that passes the first three and where a mistake is cheap is a good first candidate. If a mistake is expensive, automate it anyway and keep a person on the risky step.

Write it down first

Pick the task and ask the person who does it to talk you through it while you write. Every step, including the small ones: where the information comes from, where it goes, what they check, and what they do when something looks wrong.

This exercise is worth doing even if you never automate anything. It usually shows three things. Some steps exist only because two tools do not talk to each other. Some checks are done twice by two people. And some steps nobody remembers the reason for.

Fix those before automating. Automating a messy process gives you the same mess, faster, and harder to see.

Good first candidates

Some examples of tasks that tend to be good first automations for a growing firm:

  • A new customer entered once and copied into accounting, scheduling and the shared folder.
  • A weekly report that someone rebuilds by hand from the same sources every Monday.
  • Reminders to clients who have not sent a document, signed a form or paid an invoice.
  • Routing an incoming form or email to the right person with the details filled in.
  • Creating the folder, checklist and calendar entries every new job or engagement needs.

Each one happens often, follows the same steps and has a clear start and finish. None needs judgment beyond what can be written as a rule.

What to leave to people

Some work should stay manual, at least for now. Work that needs judgment about a particular client. Work that changes every time. Conversations where the relationship matters more than the speed. And anything rare enough that the automation would be forgotten before it ran again.

There is also a middle ground. An automation can prepare the work and stop before the step that leaves the business. It drafts the reminder, fills in the invoice or assembles the report, and a person approves it. Preparing is usually most of the work. The approval is quick, and it is where a person catches the mistake software would have sent.

Exceptions, written down

Once an automation has run well for a while, approving every item can become a chore. It is reasonable to let a narrow kind of work go out without a click: a standard appointment reminder, a payment receipt.

Make that an owner's decision, and write it down: which action, in which cases, from what date, decided by whom. Keep it narrow enough that anyone can check it later. "Appointment reminders to existing clients, using the standard template" can be checked. "Routine emails" cannot, because nobody can say afterwards what it covered.

Someone has to own it

An automation is not finished when it first runs. It connects to other software, and other software changes. A field gets renamed, a login expires, a vendor changes how its export works. When that happens, an automation can fail quietly, and the first sign is a client asking where something is.

So every automation needs three things beyond the build.

  • A named owner, who gets told when it fails.
  • A short written note of what it does, which accounts it uses and how to switch it off.
  • A simple check, such as a weekly glance at whether it ran, until you trust it.

Keep a single list of every automation the business runs. It will be short at first. If it ever gets long and nobody can say what is on it, that is a bigger problem than any one task it saves.

Start with one

Pick the task that costs the most time each week and passes the four questions. Write it down, fix what the writing shows, automate it with a person on the risky step, and name its owner. Then live with it for a few weeks before starting the next one. One automation that works and is maintained is worth more than ten nobody understands.

Amalgament is a fractional hire who looks after growing, owner-led firms. We learn how your business works, find the repetitive work worth automating, build it and maintain it. If you have a task in mind and want a second opinion on whether it is ready, we are glad to talk it through.

Note, October 28, 2026: some wording, including this closing paragraph, was updated to match how we now describe our work. The advice is unchanged.

Field Notes is written by Amalgament at Amalgament. We are an on-demand tech person for small and growing businesses: we learn how they work, find what could be better, and build, connect, improve and maintain the technology they run on.

Next: The work between the work

Let's make your business work better.

Let's talk about your business