Most of what you want automated is not worth automating

The request nearly always arrives in the same shape. There is one job somebody in the office cannot stand, usually retyping something out of one screen and into another, and the question is whether we can make it go away.

Usually we can. Whether we should is a different question, and for a decent share of these jobs the answer is no.

That is an awkward thing for a firm that gets paid to build automations to put in writing. It is also the most common conclusion we reach, so it may as well be said first.

The sum is small enough to do on the back of an envelope

Three numbers decide it, and only the first two ever get mentioned.

01Count how many times the job was actually done last month, from records rather than impressions
02Time it once, properly, with a clock rather than from memory
03Work out what happens on the occasions it goes wrong, and how often that is

The first two multiply into hours a year, and the result is usually smaller than anyone expects. A ten-minute job done twice a month is four hours a year. Build something for it and you are perhaps forty hours of payback away, by which point the supplier will have changed their form twice and you will have rebuilt it once. The same ten-minute job done forty times a month is eighty hours a year, and now we are having a different conversation.

The gap between those two cases is the whole decision, and it has nothing to do with how irritating the job is. Frequency is not a feeling. It is a number, and most people are wrong about it in both directions.

The third figure is the one that changes answers

Time saved is the easy number and the least interesting. What tips a marginal job over the line is what a mistake costs.

A job done twice a month where a slip means an invoice goes out with the wrong figure on it, or a delivery goes to the address of the customer above, can be worth building for on those grounds alone, even though the hours saved would never justify it. The automation is not buying time there. It is buying the removal of a category of error, and that is a legitimate purchase.

The reverse applies too, and people like it less. A frequent job whose mistakes are caught immediately by the next person down the line is worth less than the hours suggest, because the process already has a check in it and you would be automating the check away along with the typing.

The jobs worth automating are rarely the annoying ones. They are the frequent, identical, consequential ones, and those are usually boring enough that nobody has ever complained about them.

You cannot automate something that is not the same twice

This is the part that catches everyone, and it comes before any question of software.

Ask someone to write down the job step by step and a surprising proportion of the time it turns out that two people do it differently, or that there is an "it depends" sitting at step four which nobody has ever resolved. That is not a failure of documentation. It is a genuine decision that has never been taken, and it has been absorbed for years by whoever happens to be doing the job that day.

Nothing can be built on top of that. So the first piece of work is almost always writing the thing down, and a fair number of jobs are fixed at exactly that point, for nothing. The steps get agreed, the exception gets a rule, and the job stops being annoying without a line of code.

We have talked more clients out of building than into it on the strength of that exercise, and it is a better outcome than the alternative, because the alternative is an automation that encodes a disagreement.

Every automation you build is a small permanent liability

Once it exists, it needs an owner.

It runs quietly, which is the point of it. It also fails quietly, which is the problem. A supplier redesigns a form, a password expires, a spreadsheet gains a column, and the thing stops doing its job without announcing that it has. Because nobody checks on something that has worked faultlessly for a year, you tend to find out from a customer.

So every automation carries a standing question: who would notice, and how soon. Answering that properly costs something, and it costs it every year. Which is why three good ones beat fifteen, and why a firm with fifteen has usually stopped trusting any of them.

What we build, and what we do not

The clearest case we have had for building was our own Help Desk. An off-the-shelf ticketing tool could not express a payroll partner's escalation ladder, which changed by time of day and day of week, and could not age a deadline in working days only. That job was frequent, identical and consequential on all three counts, so it got built.

Set against that, one client's IT strategy review cut their software spend by 70%. Nothing was automated at all. Several tools were doing the same job in different corners of the business, and consolidating until every licence earned its keep was the entire piece of work. The most valuable thing we did there was not build anything.

3: Numbers that decide it: frequency, duration, cost of error
70%: Software spend cut for one client by building nothing

If the answer does turn out to be yes, the next question is whether to buy something or have it made, and the test for that is separate from this one. If the job currently lives in a spreadsheet that has quietly grown users, that is its own conversation and worth having first.

The good news in all of this is that the discipline is free. Counting takes an afternoon, writing the process down takes a morning, and both of them are worth doing whether or not anybody ever builds you anything.

If you want a second opinion on one of these, the first conversation costs nothing, and "write it down and leave it alone" is an answer we give more often than the other one.

We work with businesses across Knutsford, Alderley Edge, Wilmslow, Altrincham, Stockport and Warrington, and remotely for clients anywhere in the UK.