How to decide what to automate with AI in a small business

This guide from AR Labs is a do-it-yourself AI opportunity assessment for owners of small service businesses who have more AI ideas than they can test and no clear way to choose. It shows how to decide what to automate with AI: find the workflows that cost the most, measure them, decide whether each needs a process fix, existing software, simple rules or AI, and test one change against a baseline before spending more. Often the answer is not AI, and the method is built to reach that answer when it is right. It follows the discovery stage of our client delivery framework, and once you have chosen a workflow, the process mapping guide shows how to map it. The business examples here are illustrations, not accounts of clients.

Why AI adoption stalls

Surveys describe owners stuck between interest and commitment. In a national survey of 947 small businesses carried out in May 2025 by Reimagine Main Street, a project of the Public Private Strategies Institute, with support from PayPal, 25% had integrated AI into daily operations and 51% were experimenting with AI tools without being fully committed. Among those experimenting, 38% worried about data privacy and security, 37% lacked the time or resources to explore tools, 34% did not yet see a clear use case or return on investment, and 74% said they would adopt with clearer evidence of return (PayPal newsroom, 10 June 2025). Larger organisations report slow returns too. Deloitte surveyed 1,854 senior executives in 14 European and Middle Eastern countries between 15 August and 5 September 2025; most reported achieving a satisfactory return on a typical AI use case within two to four years, against the 7 to 12 months typically expected for technology investments (Deloitte).

The common path in a small business looks like this:

flowchart TD
  I["Many AI ideas"] --> T["Try a chatbot or an automation tool"]
  T --> E["Experiment on whatever is to hand"]
  E --> M{"Did it save time or money?"}
  M -->|"no baseline: cannot tell"| S["Stalls, or becomes another tool to check"]
  M -->|"works in a demo"| R["Fails on real cases or exceptions"]
  R --> S

The current pattern: the experiment starts before the problem is measured, so nobody can tell whether it worked.

The steps below reverse the order: problem, measurement and decision first, tool last.

Step 1: List where time and money go

What to do. Ask everyone who does routine work to list the tasks that take the most time, cause the most errors, or most often delay a customer. Group them into workflows: a trigger, a series of steps and an output, such as "enquiry to booked job" or "month-end to invoices sent".

Why. Assessments that start from AI capabilities find uses for AI. Assessments that start from the work find the problems worth solving, some of which AI suits and many of which it does not.

Example. A small accountancy might list: chasing client documents, answering the same questions about deadlines, typing figures from receipts, preparing month-end reports, and scheduling appointments.

• Everyone who does routine work contributed
• Items grouped into named workflows with a trigger and an output
• Top three to five workflows chosen for a closer look

Step 2: Measure a baseline for each

What to do. For each chosen workflow, record how often it happens, how long it takes, how often it goes wrong and what going wrong costs: a lost customer, a refund, rework, a late payment. Use real records where you have them and a short tally where you do not.

Why. Without a baseline, no change can be shown to have worked. The baseline also ranks the workflows by real cost rather than by how irritating they feel.

Example. An illustrative tally: "Document chasing: about 40 new or returning clients a quarter, three or four chasing emails each, and roughly one in five starts late because something is missing."

• Volume, time, error rate and consequence recorded
• Source of each number noted
• Workflows ranked by cost

Step 3: Map the top workflow before choosing a fix

What to do. For the most costly workflow, map who does what in which tool, where information is re-typed or held in someone's head, and which steps need a person's judgement. The process mapping guide covers this step in detail.

Why. The fix depends on where the cost actually sits. A workflow that loses time to re-typing needs a connection between tools, not a language model.

• Current workflow mapped
• Hand-carried steps and memory-dependent steps marked
• Judgement steps marked

Step 4: Classify each problem by the kind of fix it needs

What to do. For each failure in the map, decide which kind of fix fits, starting with the simplest:

• Process repair: the steps are unclear, inconsistent or unowned. Write the method, a checklist or a script.
• Existing software: a tool you already have can do it once configured.
• Fixed rules: the decision follows rules you can write down (if this, then that), and an automation can apply them reliably.
• AI: the input is unstructured or varies too much for fixed rules, such as free-text messages, documents or speech, and the output can be checked by a person.

Why. AI is the most expensive and least predictable of the four. Fixed rules are cheaper, testable and do the same thing every time. Use AI only where the input defeats rules.

Example. Late starts caused by missing documents: process repair (one request with a list) and existing software (reminders). Typing figures from receipts: existing software or an AI extraction tool, with a person checking totals. Answering deadline questions: a published page and fixed replies, not a chatbot.

• Each failure classified
• Simplest workable fix chosen for each
• AI kept only where input is unstructured and output can be checked

Step 5: Score value, feasibility and risk

What to do. For the remaining candidates, score value (from the baseline), feasibility (does the data exist and can it be reached; does the tool fit how people work) and risk (what happens when it is wrong; is personal or sensitive data involved; does it touch customers or money). A simple high, medium or low for each is enough.

Why. The highest-value idea is not worth starting if the data is not there or a mistake would reach a customer unchecked. If a candidate uses customers' or staff's personal data, check what your data-protection rules allow, whether people must be told or asked for consent, and where the tool stores the data. Data readiness is one of the first questions in our client delivery framework for this reason.

Example. Receipt extraction: value medium, feasibility high (receipts already arrive as photos), risk low if a person checks totals. A chatbot answering client tax questions: risk high, because a wrong answer reaches a client as if it were advice.

• Value, feasibility and risk scored for each candidate
• Sensitive data and customer-facing actions flagged
• Assumptions behind each score written down

Step 6: Decide what happens when it is wrong

What to do. For any candidate that uses AI, answer two questions before going further: what error rate can you accept, and how will a person catch and correct the errors? Decide where a person reviews, approves or can override, and what the fallback is when the system is unavailable.

Why. AI systems are wrong some of the time. If a system is right 95% of the time, the other 5% still arrives somewhere. Designing review and fallback first is what makes it safe to try, and until the error rate is known, a person stays between AI output and anything a customer or the accounts will see.

Example. Extracted receipt figures go to a review screen; a person approves each batch before it posts. If extraction fails, the receipt stays in the queue for manual entry.

• Acceptable error rate stated
• Review, approval and override points named
• Fallback defined

Step 7: Choose one first move and define success

What to do. Pick one change. Write what it is, who owns it, which number from the baseline it should move, what result counts as success, and what result means stop.

Why. One change at a time can be measured; with several at once you will not know which one helped. A stop rule written in advance protects you from continuing because of effort already spent.

flowchart TD
  W["Workflows listed"] --> B["Baseline measured"]
  B --> M["Top workflow mapped"]
  M --> K["Failures classified: process, software, rules, AI"]
  K --> S["Value, feasibility and risk scored"]
  S --> E{"Owner decides error tolerance and review points"}
  E --> F{"Owner chooses one first move with success and stop rules"}
  F --> T["Run beside current process"]
  T --> R{"Owner decides: expand, change or stop"}

The target method. Diamonds are decisions the owner makes; the analysis informs them.

Example. "One onboarding request with automatic reminders, owned by the practice manager. Success: fewer than one in 10 clients start late over the next quarter. Stop: if it is no better than the baseline."

• One change chosen, with an owner
• Target number and success threshold written
• Stop rule written

Step 8: Run it beside the current process, then decide

What to do. Run the change on real work alongside the existing process where you can, or for a defined period. Compare the result with the baseline. Then decide: expand it, change it, or stop.

Why. Running beside the old process limits the damage if it fails. Comparing against the baseline, rather than against expectations, gives an honest answer, and "stop" is a useful answer.

Example. Suppose late starts fall but long-standing clients find the reminders irritating. The owner keeps the change for new clients only.

• Change run on real work
• Result compared with the baseline
• Decision recorded: expand, change or stop

Choosing how far to go

The four kinds of fix in step 4 sit on a ladder: work by hand, configure a tool you own, connect tools, then build custom software. The ladder of changes in the process mapping guide sets out what each rung involves and its limits. For AI the rule is the same at every rung: use it where the input is unstructured and rules cannot cope, and only with a person checking the output. AI can arrive on the second rung, as a feature in software you already pay for, before anything is built.

AR Labs offers this kind of assessment and design work to owner-run businesses; more about us is on the about page.