Most automation projects that disappoint were aimed at the wrong thing. Not built badly — aimed badly. Someone picked the task that annoyed them most in the week the budget was approved, and the task that annoyed them most is rarely the task that costs the most.
Here is the method we use in the first week of every engagement. You can run it yourself, without us, and if you do it honestly you will get a better answer than most agencies would hand you.
Step one: time the work for one week
Not estimate. Time it.
Give every person whose day includes repetitive work a simple sheet with four columns: what the task was, when they started, when they finished, and how many times they did it. One week is enough. Two is better if the work is lumpy — month-end finance work will not show up in the first week of the month.
The reason to measure rather than ask is that people are consistently wrong about this, and in a specific direction. Tasks that are unpleasant feel long. Tasks that are frequent and short feel like nothing at all, because each individual instance is trivial. But forty instances of a three-minute task is two hours a week, which is two and a half working weeks a year, and nobody ever notices it happening.
Step two: multiply hours by repetition
For each task you now have hours per week. Multiply that by how many times it is done, and sort the list descending.
What usually rises to the top of a Kenyan SME's list is one of three things:
Enquiry handling. Answering the same questions on WhatsApp — price, availability, location, delivery. It is short each time and it happens constantly, and it also has a second cost that does not appear on the sheet: the enquiries that go unanswered until morning and buy somewhere else.
Quotation to invoice. The quote is typed, sent, approved somewhere, then retyped as a job, then retyped again as an invoice. Three transcriptions of the same information, each with a chance of a mistake, and a wait in the middle for whoever signs.
M-Pesa reconciliation. Someone matching payment messages to invoices by eye. It is slow, it is error-prone, and its errors are found at audit rather than at the time.
Step three: check the rules are stable enough to write down
This is the filter that separates a good candidate from a bad one, and it is the one most often skipped.
A task can be automated when you can state its rules in advance without saying "it depends". If your best salesperson can tell you exactly which four questions establish whether an enquiry is worth pursuing, that can be automated. If the answer is "you just get a feel for it", it cannot — not yet. Write the rules down first and see whether the person agrees with what you wrote.
Some tasks fail this test permanently. Judgement work, negotiation, anything where the right answer depends on knowing the person. Automating those produces something that is technically working and practically distrusted, and a system the team does not trust gets worked around within a month.
Some tasks fail it temporarily, and the fix is not software. If three branches do the same job three different ways, the honest first step is to agree on one way. That is a management change, it is free, and quite often it removes most of the pain on its own.
Step four: prefer the boring one
Given two candidates with similar numbers, take the one that is duller.
Dull tasks have stable rules, obvious correct answers, and errors that are easy to spot. They also tend to touch fewer people, which means fewer conversations before anything can change. Automating a dull task well builds the credibility you will need for the interesting one later.
The opposite instinct — start with the most visible, most exciting project — is how a business ends up with an impressive system nobody uses and no appetite for a second attempt.
What this looks like in practice
A distributor off Mombasa Road runs the exercise and finds the top three are: field sales reports typed up each evening, quotations waiting on a director's signature, and stock queries answered by phone.
The stock queries are the most annoying, and everyone says so. But timed, they are twenty minutes a day. The quotation delay is only ten minutes of typing — except the waiting adds an average of two days to every deal, and that shows up in orders lost to a competitor who quoted the same day. The field reports are ninety minutes an evening across four people.
The right first project is the field reports: highest hours, stable rules, one team affected. The quotation approval is the right second, because it needs a decision about signing authority that the business has to make itself. The stock queries — the loudest problem — are third, and by then the data to answer them automatically already exists because of project one.
The uncomfortable outcome
Sometimes the exercise says: do not automate this. Simplify it.
A process with nine approval steps does not need nine automated approval steps. It needs someone to ask why there are nine. We would rather tell you that in week one than build you a faster version of a bad process and invoice for it. If the discovery session ends with a recommendation to change a policy instead of buying software, that is a successful discovery session.
Then measure again
Whatever you build, compare it against the numbers from step one. Not against how it feels — against the sheet.
That comparison is the entire argument for the second project. Without it, automation is a matter of opinion, and opinion does not get budget approved twice.