Start with a task, not a tool
The question “which tool should we choose?” comes too early. The right first question is: which task eats time or produces errors on a repeated basis, and what would change if it were done better?
In an SME, the usual candidates are sorting and qualifying incoming requests, keying in supplier invoice data, drafting first versions of customer service replies, finding an internal procedure, preparing a report from meeting notes. All of them are frequent, bounded, and their output is easy to judge.
By contrast, tasks that carry heavy responsibility, rely on rare judgement or touch highly sensitive data are not good first candidates.
Four criteria for choosing the first use case
Frequency. A task performed several times a day by several people justifies the effort of automating it; a monthly task rarely does.
Description. If nobody can explain how the task is done today, step by step and with its exceptions, it is not ready. Describing the current process is, in fact, often the most valuable part of the project, AI or not.
Verifiability. You must be able to say whether the result is right or wrong. An invoice whose amounts have been extracted can be checked in seconds; a “better sales strategy” cannot.
Cost of error. If, when the system gets it wrong, someone corrects it on review, the case is a good one. If a customer receives false information, systematic human checking will be needed.
Data: what to verify before you begin
An AI fed bad data produces bad results with complete confidence. Three checks are essential.
Does the data exist in a usable form? Procedures that live in the heads of long-serving staff, contracts scanned at an angle or spreadsheets whose columns keep changing all need tidying up first.
Is it current? An assistant answering from an outdated version of the catalogue or the staff handbook does more harm than a search engine.
Who is allowed to access it? If the internal assistant can read payslips because they are stored next to the procedures, you have a problem before the first question is asked. Access rights are thought through before anything is connected.
Decide what the system may do on its own
The point most often neglected is the level of autonomy. Three positions are possible: the system suggests and a person approves everything; the system acts alone within a defined perimeter and flags doubtful cases; the system acts alone and is checked after the fact.
It is sensible to begin at the first position and move the dial as confidence builds on observed results. What must never be left to chance is the fallback rule: when the system hesitates or meets an unforeseen case, who is alerted, and how?
That rule has to be written down, known to the teams and tested. A system that fails silently is more dangerous than one that fails loudly.
Size a pilot you can learn from
A good pilot is small enough to deliver quickly and real enough to teach you something. A few markers:
- one use case, one team, a clearly bounded set of data;
- a set of test cases assembled before the start, with expected results, so quality is measured rather than judged on impression;
- simple indicators defined in advance: time spent, correction rate, number of cases passed to a person;
- a review date fixed from the outset, when you decide to extend, correct or stop.
A pilot that cannot be stopped is not a pilot; it is a rollout in disguise.
Involve the people who do the task today: they know the undocumented exceptions and will be the first to work around a tool that makes nothing easier for them.
Buy or build
Many off-the-shelf products now include AI features; for cases such as meeting summaries or writing assistance, a well-configured existing solution is enough. Custom work is justified when the use case depends on your own data, your own business rules or an integration nothing on the market covers.
The criterion is not sophistication, but how much of the value produced comes from your data and your processes.
In short
Begin with a frequent, well-described, verifiable task. Check that the necessary data exists, is current and is properly protected. Write down what the system is allowed to do alone and what happens when it hesitates. Run a bounded, measured pilot with a review date.
To structure this approach, from the choice of use cases through to data governance, see our AI integration for business service.