How to Find the AI Use Cases Worth Doing in Your Small Business

Most AI use cases fail the same test: they sound impressive and save nobody any time. The ones with real ROI are boring. They are the tasks your team repeats every week, that follow the same shape each time, and that someone is currently doing by hand. Find those, work out what each one costs you a year, and you have a ranked shortlist. You can do this in an afternoon, without hiring anyone.

Here is how we run it.

Start with the week, not the tools

Do not begin by looking at AI products. Begin by writing down what actually happens in your business between Monday and Friday.

Sit with each person for twenty minutes and ask one question: what did you do this week that you have done every week this year? Write the answers in a list. You are not looking for their hardest work. You are looking for the repetitive middle: the chasing, the copying, the formatting, the reminding, the reporting.

Five questions make the conversation concrete, and they work on anyone regardless of role:

• What three tasks took the most repetitive time this week?
• How many times did you do each one?
• Where did the information come from: email, a spreadsheet, the CRM, a folder?
• How do you decide what to do next, a rule or a judgement call?
• What tells you the task was done properly?

An afternoon of those conversations will surface dozens of candidate AI use cases. A bookkeeping practice tends to surface bank reconciliation, chasing late payers and building monthly client reports. An agency surfaces campaign reporting, brief formatting and weekly client updates. A recruitment desk surfaces CV formatting, interview scheduling and chasing feedback. A trades business surfaces quoting from a site visit, scheduling the crew and chasing payment on completed jobs.

Most owners are surprised by this list. The work that eats the week is rarely the work anyone talks about. Look for clusters too, because three small tasks that share the same inbox often become one automation rather than three.

Which tasks are actually worth automating

Not every repetitive task is a good candidate. Four tests, in order.

It happens often. Something you do fifty times a month is worth more than something you do twice, even if the twice is more painful. Frequency compounds. An hour saved once is not the same as an hour returned fifty times.

It follows a pattern. If you can describe the steps to a new hire in a few sentences, software can follow them. If the answer is "it depends, you have to know the client", that part stays with a person.

The information already exists somewhere. In an inbox, a spreadsheet, a CRM, a folder of documents. If the knowledge only lives in someone's head, that is a different project and a longer one.

You can tell whether it worked. "The shortlist goes out same day" is checkable. "Better customer experience" is not. Pick something you could put on a dashboard: on-time rate, follow-ups missed, hours returned.

The AI use cases that pass all four are worth costing out. A task that passes two is worth revisiting later.

Tasks that usually pass, and make the strongest AI use cases: invoice capture and matching, triaging inbound leads into the right person's queue, first-pass candidate screening against a fixed set of criteria, and turning activity across your tools into a weekly client update.

Tasks that usually fail: pricing a difficult job, talking a client down, deciding who to hire. These are not good AI use cases. They can be supported with better information, but the decision stays with a person.

One more filter worth applying. If adopting it means your team has to change how they work entirely, that is a warning sign, not an opportunity. The automations that stick are the ones that slot into the way work already happens.

Score them, do not just rank them

Ranking by gut feel falls apart once the list runs past about ten tasks, and every list does. Score each one from 1 to 5 against the four tests instead, then add them up. Here is the same exercise run on a recruitment desk:

Task	Often	Patterned	Data exists	Measurable	Total
Formatting CVs before they go to a client	5	5	4	5	19
Chasing interview feedback from clients	5	4	3	5	17
Writing the monthly client report	3	4	4	4	15
Deciding which candidate to put forward	4	1	3	2	10

Read it like this. Sixteen and above is worth costing out now. Eleven to fifteen is worth revisiting once you have one automation working. Ten and below should be left alone, and the last row shows why: deciding who to put forward happens often and the information exists, but it is a judgement call and you cannot really measure whether it was right. That is not a failure of the task. It is a signal that it belongs to a person.

Two things this exercise reliably shows up. The tasks that score highest are almost never the ones anybody complains about, because people complain about the difficult work rather than the repetitive work. And two or three high scorers usually turn out to be the same underlying problem wearing different clothes, which means one piece of work rather than three.

How to work out the ROI

Two numbers. What the task costs you now, and what fixing it costs. The gap between them, divided into the cost, is your payback period. Doing this sum is what lets you compare AI use cases on economics rather than on which one sounds most impressive.

What it costs you now. Take the hours per week, multiply by the loaded hourly cost of whoever does it, multiply by fifty two. That is the visible half.

The invisible half is usually bigger. What does the task cost you when it slips? A quote that goes out two days late sometimes loses the job. A candidate nobody called back takes the other offer. A follow-up that never happened is a deal that died quietly. Put a rough figure on how often that happens and what it is worth. For most owners this number dwarfs the labour line, and it is the real argument for fixing the task at all.

What fixing it costs. Usually a one off to build or set up, then something monthly to run. Ask for both before you commit, and ask what the monthly figure does as your volume grows. Budget for a tuning period as well. Every system of this kind needs a few weeks of corrections before it settles, and that time is part of the cost.

Before you talk to anyone about building it, have five things written down: the task step by step as it happens today, roughly how many times a month it runs, where the information lives and who controls access to it, what a correct result looks like, and who inside the business will own it once it is running. A scoping conversation with those five answers takes half the time and produces a quote you can actually rely on. Without them you will get a range so wide it tells you nothing.

A worked example. Say someone spends six hours a week formatting documents and chasing replies. At $35 an hour fully loaded, that is about $10,900 a year. If a system takes most of that work and costs $6,000 to set up plus $200 a month to run, you are square inside nine months and ahead every month after that.

A second, less flattering one. Same task, but the person doing it costs $22 an hour and the system only removes about 60% of the work. Now you are saving roughly $4,100 a year against the same $6,000 and $200 a month. That one does not pay back inside two years, and you should not do it. Run both versions of the sum before you commit, because the answer moves a long way on hourly cost and on how much of the task actually goes away.

Both sets of figures are illustrative, not results we are claiming. Put your own in.

One thing worth checking before you cost anything out. Singapore and Australia both run government support schemes for small business technology adoption, and the terms change from year to year. IMDA publishes what is current for Singapore businesses and business.gov.au does the same for Australia. It will not change which task you should pick, but it can change the payback on the one you choose.

Two honest cautions. A payback that only works if you let someone go is a different decision, and you should make it deliberately rather than discover it halfway through. And the first task you automate usually has a worse payback than the third, because you are paying for the setup and the learning at the same time. Judge the programme, not the pilot.

Rank your list by payback, then sanity check it against how hard each one looks. Start with something that scores well on both. Your first automation should be the one that proves the idea to your team, not the most ambitious one on the list. It also helps to favour tasks that leave something reusable behind, such as a connection to your CRM or a cleaned-up set of data, because the next two AI use cases then cost less.

What this looks like in practice

We run our own business this way, which is the clearest example we can give.

Our business data collects itself every morning. A written brief lands at 07:30 with what moved yesterday and what needs a decision. The whole thing runs from a Telegram bot, so we can be away from the desk and nothing stops.

None of that is clever technology. It is four or five boring tasks that used to be done by hand, found exactly the way described above, and handed over one at a time. That is the same shape as the AI operating system we set up for clients: not one big system, but the recurring work moved across in order. To turn the same idea into AI use cases for your own business, look for the point where information has to be carried by hand from one system to another. That carrying is almost always the task. The longer version of how those pieces join up is in how to build an AI operating system.

Automating a task is not the same as automating a decision

This distinction is worth getting right, because most of the fear about AI in a small team comes from blurring it.

A task is a sequence. Take the information from here, put it in that shape, send it there, chase it if nothing comes back. Sequences can be handed over completely, and should be.

A decision is a judgement about which there is no correct answer written down anywhere. Which of these three candidates the client will actually like. Whether this job is worth quoting low to win. Whether to push back on a difficult customer or let it go. Nobody wants those made by a machine, including you.

The useful move is to automate the sequence right up to the point of the decision, and then hand the decision to a person with everything they need to make it well. In practice that means the system assembles the shortlist and shows the evidence behind each name, and the consultant chooses. The system drafts the follow-up and the person sends it. The report gets written and somebody reads it before it goes out.

This is also the difference between an automation your team defends and one they quietly work around. People do not mind losing the copying. They mind being overruled on the thing they are good at. Design for that from the start and adoption stops being a problem you have to manage later.

Build, buy, or bring someone in

Once you know the task and its payback, the choice gets simpler. In practice most businesses end up doing a bit of each, buying a component and building the join.

Buy when the task is standard and hundreds of other businesses do it the same way. Scheduling, basic support replies, invoice capture. Pay monthly and be running in a fortnight. Before you sign, ask the vendor to run their system against a sample of your own data and show you where it got things wrong. A demo on their data tells you nothing about yours.

Build when the task is the thing that makes your business yours, or when it sits across two tools that will not talk to each other. This costs more and takes longer, and you own the result. If you go this way, ask for it in pieces that can be reused, because a custom build that leaves behind a working connection to your CRM has paid for part of the next project already.

Bring someone in when you know the work is there but have nobody to scope it. That is what an AI assessment is for. Someone maps the tasks, puts a number on each one, and hands you a ranked list. You should be able to act on that list whether or not you use the person who wrote it. Ask for a pilot inside 30 to 90 days rather than an open ended strategy engagement. We set out what an outside firm actually does, and when you are better off not hiring one, if you want to know what you are buying first.

Whichever route you take, ask three questions of anyone selling to you. Does it connect to the tools we already use? What happens when it gets something wrong? Who fixes it in six months?

What the first month actually looks like

Useful to know before you start, because the shape is fairly consistent whatever the task.

Week one is writing it down. How the task runs today, every step, including the exceptions people handle without thinking. Agree what finished looks like before anything gets built. Most projects that go wrong went wrong here, because nobody defined the result precisely enough to check it.

Week two is the smallest working version. Not the full thing. The version that handles the common case and hands back anything unusual. You are trying to find out whether the idea holds, not to finish.

Week three is running both. The automation and the manual process side by side on the same work, so you can compare them on real cases rather than argue about them in theory. This is where you find the exceptions nobody mentioned in week one, and there are always some.

Week four is the handover. Training on the team's own work, not a demo. An agreement about what happens when it gets something wrong and who fixes it. Then it is live.

After that, leave it alone for a month and look at the numbers you chose at the start. Not before, because the first fortnight of any system of this kind is noisy and you will draw the wrong conclusion from it.

What usually goes wrong

Starting with the technology. If you begin with "we should use AI", you will find a use for it, and it will not be a good one. Good candidates come from watching how work actually moves, not from a product list.

Automating something nobody minds doing. Ask the person who does the task. If they are not relieved, you picked the wrong task. Sometimes a manual step is quietly acting as a quality check, and removing it breaks something nobody had written down.

Counting savings that never show up. An hour saved is only real if it goes somewhere you can name. More calls made, proposals out faster, less overtime. If the time just evaporates into the day, you did not get the return, whatever the spreadsheet said.

Skipping the handover. A system your team does not use is worse than the spreadsheet it replaced. Whoever builds it should train the people using it, on their own work, before it is called done.

Removing the judgement. The drafting, chasing and formatting can go. The decision about what the client hears should not. Build the escalation in from the start, so the system hands back anything it is unsure about instead of guessing.

Common questions

How soon should we see the money back? For a first task chosen well, months rather than years. If a proposal cannot tell you roughly when you break even, that is a reason to ask more questions before you sign.

How long does this take? The audit itself is an afternoon. Costing and ranking is another half day. Automating the first task is usually a few weeks. AI use cases that touch several systems at once take longer, so plan for it.

Do we need clean data first? Usually not for the first one. Pick something that runs off information you already hold in one place, and leave the messier work until you have a win behind you.

What if we have nobody technical? That is the normal case at this size. It matters for who builds the thing, not for whether you can spot the opportunities. Everything above is written for the owner, not an IT department.

What should this cost? It depends on the task, but the thing to insist on is a fixed price quoted before work starts, against a scope you both wrote down. Hourly billing on work like this puts the risk of a bad estimate on you. If someone cannot give you a number before starting, the scope is not clear enough yet and more scoping is the next step, not a deposit.

What happens when it gets something wrong? It will, and the plan for that matters more than the accuracy rate. Ask how the system behaves when it is unsure: does it guess, or does it stop and hand the case to a person? Stopping is almost always the right answer for a small team. Ask who fixes the underlying problem, how quickly, and whether that is included or billed.

Will this replace anyone? In our experience it moves people off the admin and onto the work you hired them for. If the plan is a headcount cut, say so at the start, because your team will work it out anyway.

Where to start

Block two hours this week. Write down every task your business repeated in the last seven days. Score each one from 1 to 5 on the four tests: how often it happens, how patterned it is, whether the information already exists, and whether you could measure the result. Add the scores up, put a yearly cost beside the ones that pass, and you have a ranked list of AI use cases with the arithmetic already done.

Then take the top one. Not the top three. Measure what it costs you honestly, sketch the smallest version that would remove half the time, and run it. The learning from one finished pilot is worth more than a roadmap of ten, and it tells you which of the remaining AI use cases are worth starting next.

If you want a second pair of eyes on that list, book a free call with us. Thirty minutes, no obligation, and you will leave knowing which of your tasks are worth automating first and roughly what each is worth.