How to work out what to automate in your business

Almost everybody does this backwards. They open an automation tool, look at the empty editor, and build whichever job came to mind first. That job is almost never the one costing the most, and there is no way to find that out from inside the editor.

The work of deciding what to automate happens before any software is involved, and it is not complicated. It is mostly counting. What follows is a method you can run yourself, by hand, in about three weeks, with a spreadsheet.

Why you cannot just decide from memory

Ask a founder where their agency loses time and you will get a real answer, delivered with confidence, that is usually about their own week.

That is arithmetic rather than inattention. In a business of ten to thirty people, the founder is doing somewhere under a tenth of the work. The jobs quietly eating the most hours are being done by an account manager or a coordinator, and they are invisible from the top for a specific reason: nobody escalates a task that is merely slow. People escalate things that are broken. A job that reliably takes four hours every Friday and always gets done never comes up in a meeting.

There is a second problem, which is that people are poor at estimating their own time and are wrong in a consistent direction. Anything unpleasant and repetitive gets over-reported when asked about in general, and anything done in ten scattered five-minute bursts gets under-reported to almost nothing. The second category is where most automation value hides.

So the method has to do two things: measure rather than ask, and cover everybody rather than whoever is in the room.

Step one: two weeks of time logging

Make a shared spreadsheet. Five columns is enough:

Two weeks, everybody, fifteen minute granularity. Each of those is a deliberate compromise.

Two weeks because one week is whatever happened that week. A fortnight catches most weekly jobs twice and gives you a chance at the monthly ones. Longer than a fortnight and the logging itself becomes the thing people resent.

Fifteen minutes because five-minute granularity gets abandoned by Wednesday and hour granularity produces guesses. Fifteen is the coarsest unit that still catches the small repeated jobs, which are the ones you are looking for.

Their own words in the What column, which matters more than it sounds. If you hand people a dropdown of categories you invented, you will get your own assumptions back, sorted. Free text means the pattern in the data is theirs, and the phrase five people all used without discussing it is the most valuable thing in the sheet.

Two practical notes. Tell people plainly what this is for and that it is not a performance review, because a time log that people think is being used to judge them produces fiction. And log it as it happens rather than reconstructing on Friday, which is the same problem as asking from memory, just compressed into a smaller window.

Step two: ask everyone, separately

The log tells you where the hours went. It does not tell you which of them felt like waste, and that judgement is worth having from the people doing the work.

So ask, in writing, four questions:

• What did you do last week that you would hand to somebody else tomorrow if you could?
• What takes the longest for what it actually achieves?
• What do you do more than once because something did not carry across properly the first time?
• What would you stop doing entirely if nobody noticed?

Ask about last week specifically, not about how things go in general. People are poor at generalising and good at remembering. “What wastes your time” produces an opinion; “what did you do last Tuesday that you resented” produces an example.

Three things about how you ask matter as much as what you ask.

Separately, not in a meeting. The first person to speak in a group sets the answer and everybody else agrees with it. What you want is convergence between people who did not hear each other, because that is the only kind that is evidence.

Anonymously, if you can manage it. The honest answer to the fourth question is often about a process somebody senior insists on, and that answer does not survive having a name on it. A plain form with no name field is enough. If your team is small enough that answers are identifiable anyway, say so rather than implying a protection you cannot provide.

Keep it short. Four questions, ten minutes. A forty-question survey gets answered thoroughly by your three most engaged people and ignored by everybody else, which gives you a confident and unrepresentative answer.

Step three: count

This is the part that turns a pile of notes into a decision, and it is an afternoon of work.

Group the log entries by what the job actually is rather than by how it was described. “Monthly report for Acme”, “client reporting” and “pulling numbers for the deck” are one job. Then, for each group, work out two numbers:

• Hours a month. Minutes per occurrence multiplied by occurrences per month, across everybody. Annualise it if you want the number to be persuasive to yourself.
• How many people named it independently. Not how many hours they logged. How many separate people brought it up in step two without being prompted.

That second number is the one people skip, and it is the one that turns an anecdote into a fact. One person saying reporting takes ages is a preference you can reasonably discount. Nine of fourteen naming it independently is not something you can argue with, and it is also the number that gets a change approved when you are not the only decision maker.

Now sort by hours a month. You will usually find the top of that list is not what you expected, and that two or three jobs account for most of the total.

Step four: work out which of them can actually be handed over

A job at the top of the list is not automatically a good candidate. Run each of the top few through five questions.

Can you name what starts it? Every Tuesday. Every new client. Every time a proposal has been out three days. If you cannot finish the sentence “this should happen whenever…”, the job is not ready to be automated, and quite often that means the process itself is undefined rather than that the software is not up to it.

Is the shape the same every time? The details change, the sequence should not. If half the instances go a different route, those halves are two different jobs and should be counted separately.

Could you describe it to a new starter in a few sentences? If it takes twenty minutes and a list of exceptions, the exceptions are the job. That does not make it impossible, but it does mean the interesting part is judgement, and judgement is where automation gets expensive and fragile.

Is getting one wrong recoverable? An awkward email you can apologise for, versus a payment you cannot take back or a message to a client that damages a relationship. Both can be automated eventually. Only one should be first.

Is anybody paying you for this part? Clients pay for judgement, creative work and being looked after. They do not pay for chasing, formatting, copying between systems or assembling the same document again. That last category is exactly what should go first, and it is usually where the hours are.

What to leave alone

A shorter list, and worth being strict about.

Anything whose exceptions are the job. If the reason a human does it is that every case is a bit different, automating it produces something that is right most of the time, and you will spend more time checking it than you saved.

Anything rare. A job that runs twice a year saves you almost nothing and, worse, will break silently between runs while nobody is looking at it. The maintenance outlasts the benefit.

Anything you have not done by hand enough times to describe. Automating a process you have not settled is how you end up with something nobody can change because nobody remembers what it was supposed to do.

Anything you are automating instead of fixing. This is the one that hurts. If the monthly report takes half a day and nobody reads it, automating it means nobody reads it instantly and for free. The half day comes back and the waste becomes permanent, because it has stopped being annoying enough for anyone to question. Ask whether the job should exist before you ask whether it can be handed over.

Then do exactly one

Take the job at the top that passed the five questions and automate that one. Watch it for a month before you build anything else.

The reason is not caution for its own sake. The first automation is really a test of whether the process was understood, and you find out by watching it run against real work. Businesses that end up with forty half-working automations that nobody dares touch all got there the same way, by building the second before understanding the first.

A month later you will also have the only measurement that matters, which is whether the hours actually came back. Sometimes they do not, because the job was replaced by the work of checking the job. That is worth knowing before you have done it eight more times.

The three that come up nearly every time

Run this properly and the results are yours, but in a small business the same three tend to surface. If you want a starting hypothesis to test against your own data:

Chasing things nobody replied to. Quotes, proposals, invoices, requests for assets. Almost always underestimated, because it happens in scattered two-minute pieces that nobody logs, and almost always worth real money, because the follow-up that never got sent is a deal that quietly did not happen.

Onboarding. The same folder, the same welcome pack, the same five accounts, the same kickoff questions, once per new client. Highly repetitive, well defined, and usually being done from memory by whoever is free, which is why it is also inconsistent.

Recurring reports. Collecting numbers from several places into the same layout every month. The collecting is mechanical. The commentary at the top is not, and that split is exactly why the job has resisted automation until recently.

If you would rather not do all that

Everything above works with a spreadsheet and no software, and the method is the method whether you run it yourself or not.

It is also, in fairness, the job we built Nrth Star to do. The audit runs the same shape of process, meaning the conversation, the anonymous survey across the team, the counting, and the ranked list with a number and a headcount against each item. It then builds and maintains the automations for the things you pick off that list. It is free, it connects to nothing, and there is no card involved, so it is a reasonable way to get the ranked list even if you go and automate the items yourself.

But the honest version of the advice is this: the counting is the part that decides everything, and it is the part almost nobody does. Whether you do it in a spreadsheet over a fortnight or hand it to somebody else, do not skip it and start clicking. The tool you choose matters far less than picking the right job to point it at. What the tools can and cannot do is worth knowing second, not first.