Ask a room what to automate and you get the same list every time: the admin, the data entry, the thing everyone hates on a Friday afternoon. It is an honest list and it is sorted by irritation. Irritation and money are not the same axis, and the gap between them is why so many AI projects end up technically fine and commercially pointless.
The sort that matters is different. It has three questions in it, and you can run all three yourself in an afternoon without buying anything.
Start with revenue, because saved hours rarely turn into money
The usual case for automation is time. Twelve hours a week back across the team, and the pitch writes itself. The problem is what happens to those hours afterwards.
Saved time only becomes money two ways. Either you remove the cost, which means the hours were concentrated enough in one place to change what you spend on payroll, or you resell the freed capacity, which only works if there is demand already waiting for it. Four hours a week spread thinly over six people is neither. Nobody is let go, nothing new gets sold, and payroll on the 30th is identical to last month. The hours are real. They are just not visible anywhere a business measures itself.
Run the arithmetic backwards and it gets harder. Take whatever a system would cost you over a year and ask what it would have to be worth for that to be an obvious yes rather than a maybe. Now try to reach that number in saved hours alone, at a fully loaded hourly rate, in one function. The headcount that implies is usually more people than actually work in that function. That does not mean the system is a bad idea. It means time saved is the wrong number to be arguing about, and any serious buyer will notice.
Revenue does not have this problem. One extra job won, one enquiry caught that would have gone cold, one dormant customer back on the books: those show up in the bank, they are countable, and they are argued about by nobody.
Hours reclaimed still matter. They are just evidence that the thing is working rather than the reason to buy it. Report them, do not lead with them.
The three tests
Put any candidate job through these before it goes near a build. A job that fails one is not a bad job, it is a job to do second.
Does it repeat?
A system earns its keep through frequency. Something that happens forty times a week is a system; something that happens twice a quarter is an afternoon of someone's time and should stay that way. Frequency is also what makes it reliable: a job running constantly gets its edge cases found in week one, while a job running quarterly finds them in front of a customer.
Can you count what it produced?
If the output cannot be counted, you cannot tell whether it worked, and something you cannot evaluate gets cancelled eventually for reasons that have nothing to do with its value. Enquiries answered, quotes issued, bookings made, records revived: countable. "Improved communication" is not, and neither is "better visibility".
Does a missed one cost money?
Not whether missing it is annoying. Whether missing it costs. An enquiry that arrives at 7pm on Friday and gets a reply on Monday morning has a price attached, and you can usually estimate it from your own close rate. The weekly report going out on Wednesday instead of Monday probably does not.
Pass all three and you have found the first thing to automate. Pass two, and it is worth doing later, once the system already knows the business and adding a job is cheap.
Where it pays
In practice the work that clears all three tests keeps landing in the same few places. Not because they are fashionable, but because they are all the same shape: small jobs, attached to a deadline, that only produce revenue when they happen every single time.
The dormant list deserves its own note, because it is the one that behaves differently. New outbound relationships warm over weeks. A dormant list produces inside days, from people who already know the name. It is the only one of these that can pay for itself in the first month, which is exactly why it is worth checking before anything else.
Where it does not pay
This half matters more, because it is where the money gets spent on nothing.
- Judgment carrying accountability. Pricing a deal, hiring, the call to the customer who is already unhappy. A system can prepare all of it and should. It cannot own the decision, and any arrangement where it appears to own the decision is one nobody in the business will actually trust.
- Work whose rules have never been written down. If how you qualify someone, or when you discount, lives only in one person's head and has never been said out loud, that is not a blocker but it is a real cost. Getting it out of their head is the first job, and it takes longer than the build.
- Anything where the bottleneck is downstream. If you can serve twenty a month and you are getting twenty-five enquiries, more enquiries is not the lever, and a system that doubles them makes the problem worse. The lever is further down the line: throughput, scheduling, or what happens to the five you already turn away.
- Work that is allocated rather than won. Where a third party decides who your customers are, there is no enquiry to catch and no follow-up to make. This one is worth checking early because it is invisible from the outside and it rules out the whole approach.
- Jobs nobody owns today. If a report has no reader now, automating it produces a report nobody reads, faster. The absence of an owner is usually a signal that the job does not matter, not that it is waiting for a system.
The question that settles it
When a candidate job survives all of the above, one last question does the rest of the work:
If this ran perfectly for a month and nobody looked at it, what would be different in the bank at the end of the month?
If the answer takes one sentence and has a number in it, that is the first thing to build. If it takes a paragraph, it is a good idea that is not ready yet, and the honest move is to say so rather than to build it and hope the case shows up later.
That is the whole test. It is deliberately blunt, because the expensive mistake in this category is not picking the wrong tool. It is building something competent that nobody can point at a number and defend six months later.