What to automate first in a small office, and what to leave alone

Small offices tend to get this backwards. The task that gets automated first is usually the most annoying one, and the most annoying tasks are nearly always the ones that need judgement, which is precisely why they are annoying.

Meanwhile the genuinely mechanical work carries on being done by hand: the copying, the chasing, the filing, the same email sent forty times a week with two words changed. Nobody complains about it because it is dull rather than difficult, and so it never gets looked at.

Write the task down as a set of steps. If you can write it so that somebody new could follow it exactly, with no if it seems like moments, it is a candidate. If your instructions keep needing the words usually, depends, or use your judgement, it is not, at least not yet.

That is the whole test, and it is more reliable than any list of tools. The question is never whether software can do a thing. It is whether the thing is the same every time.

Once a task passes that first test, three questions tell you whether it is worth doing.

Multiply the first two answers and you have the size of the prize. The third tells you how much care to take. In a small office these are the ones we tend to reach for, roughly in this order, because they are mechanical, frequent and safe to get wrong loudly rather than quietly.

This list matters more than the first one, because automating these is how small firms end up with a system nobody trusts, which is worse than having no system at all.

The dangerous failure is not the automation that breaks. That gets noticed within a day, because somebody shouts. The dangerous one is the automation that quietly stops.

The web form that has not delivered an email since the hosting changed. The sync that silently skipped every record with an apostrophe in the name. The reminder rule somebody switched off during a busy week and never switched back on. All of these can run dead for months, because nothing errors and the absence of an event is invisible.

So build the check at the same time as the automation, not afterwards. Something that reports how many ran today, and something that says so when the answer is zero. A monthly note in the diary to send yourself a test enquiry and watch it arrive is cruder, and still far better than nothing.

Before you automate a task, do it deliberately by hand for a fortnight, writing down exactly what you did each time. Two useful things come out of that. You find the steps you did not know you were taking, which is where automations usually break. And you find out whether the process is actually right, because automating a bad process mostly makes it permanent.

It also gives you the before figure. If you cannot say how long the task took and how often it happened beforehand, you will have no way of knowing whether the change was worth the money. You will only have a feeling, and feelings about your own systems are unreliable.

The version of this that fails is a project: a review of everything, a list of twenty automations, and a plan that dies at number three when somebody gets busy. The version that works is one task, done properly, running for a month, with someone still checking it after the novelty has worn off.

Pick the most repeated thing in your week, not the most annoying. They are rarely the same task, and the hours are almost always hiding in the repeated one.

There is a separate conversation to be had about AI tools specifically, where the same rule applies with one addition: be careful what your staff paste into a free tool that keeps a copy. That is worth deciding deliberately rather than discovering later.

If you want somebody to go through the list with you and say plainly which items are worth doing and which are not, that is what our automation work and an audit are for. We would rather tell you that three of your ten ideas are not worth the money than quietly sell you all ten.