Choosing a First AI Project for Your Small Business

“Use AI in sales” leaves almost everything unresolved. It could mean researching prospects, drafting emails, answering product questions, preparing quotations or approving discounts. Each activity needs different information and carries a different cost when something goes wrong. A first project becomes manageable when the unit of work is small enough to describe in one sentence.

For example: prepare a draft response to a service enquiry using the customer's message and the current service catalogue, then send it to a staff member for approval. That description identifies an input, a reference source, an output and a person responsible for release. It also exposes boundaries. The system can explain a listed service; it cannot invent availability or negotiate a price.

Begin with work that already happens often enough to examine. Ask the people doing it to show recent examples, including awkward ones. Where do they wait? Which information do they repeatedly retrieve? What takes judgement, and what merely takes time? A spreadsheet of task names is less revealing than watching one request move from arrival to completion.

The best first AI project has a result that someone can check before the business pays for a mistake. That is a more demanding standard than finding a task that produces an impressive answer in a demonstration.

A recurring task may be expensive because the information is scattered, because approvals are slow or because nobody owns it. AI addresses those causes differently. A summary tool can shorten reading time. It cannot resolve a missing commercial policy. An assistant can prepare an answer quickly and still leave the request waiting in an unattended inbox.

Build a short comparison of candidate tasks. Record weekly frequency, time spent actively working, elapsed time before completion, available reference material and the consequence of an incorrect result. Use observed ranges where the data is imperfect. A plausible estimate marked as an estimate is more honest than a detailed score assembled from guesses.

Then ask how the output will be verified. Checking a draft against three approved documents may be straightforward. Verifying an elaborate market analysis could take longer than writing a focused brief from scratch. Review effort belongs in the operating cost from the beginning.

Access matters too. A promising task may depend on information held in several accounts, inconsistent files or an application with no suitable integration. That does not disqualify it permanently, but it can make it an expensive first experiment.

A simple ranking should reveal trade-offs, rather than disguise them behind a single number. Prefer a candidate with adequate information and clear review over a theoretically valuable task whose basic process is still unresolved.

Consider a hypothetical maintenance company with a busy enquiries inbox. A first pilot might identify the equipment mentioned, retrieve the relevant service information and draft follow-up questions. Staff would still confirm whether the company can take the job. The same model could technically produce a booking confirmation, but issuing one would require reliable capacity data and permission to commit the business.

Those are different projects. Combining them in the first release makes it harder to discover whether the difficulty lies in language, information quality, system access or commercial rules.

Write down the permitted actions. “Draft only” should mean the system cannot send messages through another route. “Read customer records” should not accidentally include editing account details. Match its access to its assigned work, and keep an identifiable person responsible for exceptions.

NIST's AI Risk Management Framework places the context and consequences of AI use within risk management. For a small business, the practical application can be concise: identify who could be affected, what failure would look like and which controls are proportionate.

A task involving health advice, eligibility, lending, employment or another consequential judgement deserves a different level of assessment from drafting an internal meeting summary. Starting small is about limiting exposure as well as limiting the development budget.

A pilot needs a baseline that describes the work people actually receive. Record how long representative cases take, how often they need clarification and how frequently they return for correction. Separate routine requests from complicated ones. Otherwise a quiet week or an easier mix of work can make the new system appear more effective than it is.

Choose the result that matters to the customer or the next person in the process. For enquiries, that might be the time until a relevant, accurate response reaches the customer. Generating a draft in seconds is an intermediate event. Approval, missing information and rework can consume the rest of the day.

Research also argues against treating all users as interchangeable. A field study of AI assistance in customer support found that effects differed with worker experience and skill. That finding supports testing with the people who will use your system, rather than borrowing a headline productivity estimate.

Include experienced staff in the pilot, particularly those who recognise subtle mistakes. Their role is to reveal where the draft is misleading, where source information is outdated and where the proposed workflow adds work. If adoption depends on hiding extra checking time, the business case is already weak.

Agree on a trial period, a manageable group of users and a defined class of work. Preserve the existing route so staff can complete a request when the assistant is unavailable or unsuitable. Keep a record of cases where the tool helped, required major correction or was bypassed.

Set acceptance conditions before reviewing the results. These should cover quality and operational benefit together. An improvement in response time is welcome only if material errors remain within the organisation's agreed tolerance and reviewers can sustain the workload. Some tasks require zero tolerance for particular errors, even where minor wording defects are acceptable.

NIST's AI RMF Playbook offers adaptable actions rather than requiring every suggestion to be implemented. The same proportionate approach belongs in a pilot: select controls that address the actual task, then test whether they work.

A stop condition is equally valuable. Pause when the reference material cannot support reliable answers, when staff lack time to review or when an integration exposes broader access than intended. These findings can justify a smaller scope or preliminary data work.

The investment should produce evidence even if the first implementation is abandoned. You should leave knowing more about the process, the information it needs and the conditions under which assistance would be worth operating.

When a pilot succeeds, resist copying it indiscriminately across departments. Examine what still limits performance. Faster drafting may reveal that approvals take too long. Better classification may expose an overloaded specialist queue. More complete requests may make scheduling the next constraint.

Sometimes the next investment is an integration. Sometimes it is a clearer policy, a better form or a change in responsibility. AI can expose these needs without being the answer to every one of them.

An AI automation project should therefore be scoped around a working process: its information, people, controls and measurable result. That gives the business a basis for deciding what to extend and what to leave alone.

Before commissioning a wider rollout, prepare a short account of the pilot: the task covered, the cases excluded, the benefit after review effort, the recurring failure modes and the owner of ongoing maintenance. A colleague who was absent from the demonstration should be able to understand why the system deserves a place in daily operations.