I-Team Collage
Why this question comes up
Somewhere between ten and two hundred people, every company hits the same wall. The founder or the operations lead notices that half of their week is spent on work a person should not be doing: copying details from documents into a system, answering the same twenty questions, moving data between tools that do not talk to each other. The reflex is to hire someone for it. Sometimes that is right. Often it is a salary spent on copy-paste.
We use three questions to decide. They take about ten minutes per task, and they work for a bookkeeping firm as well as for a software company the month after launch.
Question 1 — Does it happen every week?
Frequency is what makes automation pay. A job that happens once a quarter is not worth building software for, however painful it is; a job that happens every day, or fifty times a day, is worth almost any build cost. Count occurrences per week, not hours. A ten-second task done four hundred times a week is a better candidate than a two-hour task done twice a month.
How to answer it: look at last week's calendar, inbox and ticket queue and tally the repeats. If you cannot find the same job at least five times, stop here — leave it to a person.
Question 2 — Could someone write the rules down in an afternoon?
This is the test most people skip, and it is the one that separates a good automation from an expensive disappointment. If an experienced colleague can explain how they do the job well enough that a new hire could follow it — "take the invoice number from here, check the supplier against this list, post it unless the total is over five thousand" — then software can follow it too. If the explanation keeps turning into "it depends" and "you get a feel for it", the job needs judgement, and judgement should stay with a person.
Two things confuse this test. First, a job can be mostly rules with a few judgement calls at the edge. That is fine, and it is in fact the usual case: the software handles the ninety per cent that follows the rules and hands the rest to a person. Second, "reading a document" or "understanding a customer's question" used to count as judgement. It no longer does. Extracting the fields from an invoice, or working out which of twenty standard questions a ticket is asking, is now a solved problem — as long as the rules for what to do after reading are written down.
How to answer it: ask the person who does the job today to write the steps as a numbered list. If they finish in an afternoon and the list has fewer than a handful of "it depends" branches, it passes.
Question 3 — Does a mistake cost more than the time it takes?
Some repetitive work is cheap to get wrong: a mistyped internal note, a slightly late reminder. Some is expensive: a supplier's bank details copied with one wrong digit, a customer told the wrong renewal date, a compliance form filed with last year's figures. The expensive ones are where automation earns most, for a reason people find counter-intuitive: software does not get tired at four o'clock, and it checks the same thing the same way on the thousandth document as on the first.
For one finance team we work with, the job — reading contracts and invoices and copying the details across — took about ten hours a day. The hours were the visible cost. The invisible one was a changed account number that was easy to miss. Today the software pulls the details out, checks bank details against official registers, and hands a person only the cases that look off. One hour a day, and ninety-nine in a hundred details correct.
How to answer it: think of the last time the job went wrong. What did it cost to fix, in money or in an apology? If that number is bigger than a month of the hours spent doing the job, it passes.
Scoring
- Three out of three — automate it. This is the job to start with. It will pay for itself and it is the one the team will thank you for.
- Two out of three — automate it, but keep a person reviewing the edge cases for the first month. Most document, ticket and data-transfer work sits here.
- One out of three — leave it alone, or hire. Software will not save you money on a rare task that needs judgement.
Before you hire: run the test on the job description
The most useful way to use this is on the job description you were about to post. Take the list of duties and score each one. The usual pattern: a good share of the duties on an "operations assistant" listing score three out of three. The rest — the supplier conversations, the judgement calls, the customers who are upset — are exactly the work that deserves a good person's full attention.
That is usually the answer: not "hire" or "automate", but hire for the judgement work and automate the rest, so the person you bring in does the work you hired them for.
How to be sure it will work before you pay for it
The test above tells you whether a job should be automated. It does not tell you whether a particular piece of software will do it correctly. For that we use a second, harder test: before any code is written, the people who do the job today label a set of real examples with the right answers — fifty invoices, two hundred tickets, whatever the job is. That set becomes the acceptance test, and the numbers it has to hit go in the contract. If it does not pass, it is not finished. We have written up what such a test looks like, with a worked example.
If you would like to run the three questions on your own week with us, that is what the free 30-minute call is for. Bring the job description.