Where to start with AI in your business

Before handing a process to AI, note down how often it repeats, how long it takes, and how clear the rules around it are. If most customer questions fall into five or six patterns, if order status gets checked over and over, if the same type of document gets reviewed again and again — these are good candidates. A task that needs a different judgement call every time, one that shifts with context, is too early for this.

Measuring time is a step people often skip. Asking a team member how many hours a week they spend on something is the simplest way to see which task should come first. If the answer isn't clear, get them to keep notes for a few days — the estimate is usually well off the real figure.

• Is it a repeating task that takes at least a few hours a week
• Are there clear rules behind the decision, or does it depend on context every time
• For anything with a low margin for error (invoice checks, say), is human sign-off still needed
• Do you have enough historical data on this task
• What does it cost when it goes wrong

First contact with a customer, sensitive complaints, price negotiation — these should generally stay in human hands, or at least someone should have the final word. AI can still be involved here, but as a background assistant suggesting options, not the one making the call.

Before handing a task to automation, ask this: if it goes wrong, who notices? If the answer is nobody, you need to build in a check before handing it over. That check can sometimes be as simple as a weekly review of a sample of cases.

One example: an online shop handed most customer questions to an assistant, but the moment a price objection or return request came in, the conversation routed straight to a staff member. Drawing that line clearly from the start protected customer satisfaction and let the team spend its time on the decisions that actually needed a person.

Most projects start with let's set up the AI first, we'll sort the data later — and that's exactly where they get stuck. Scattered spreadsheets, customer records kept in different formats, missing fields: no model gives a correct result until these are fixed.

Data prep is dull but not something you can skip. Spending a week working out where the current data lives, which fields are missing, which records are duplicated, speeds up every step after and cuts down on surprises later.

• Is the data kept in one place, or scattered across several systems
• Are fields like names, dates, and amounts entered in a consistent format
• How high is the rate of missing or incorrect records
• If it includes personal data, is it clear which rules apply

Rather than changing the whole process at once, test a single task in a single team for a limited time. Four to six weeks is usually enough — by the end you can see whether it genuinely saved time and whether the error rate went up or down.

Don't decide to roll it out to the whole company before the pilot's finished. A problem that's invisible at small scale grows compounded at large scale, and becomes far more costly to undo.

Getting regular feedback from the team during the pilot matters as much as the numbers. A tool looking good on a report doesn't mean it's making the daily user's job easier — and when the two disagree, the person actually using it is usually the more reliable read.

For a small pilot, an off-the-shelf tool is usually enough — ready-made chat assistants for customer service or email classification tools can be set up in a few days. Custom development comes into play when your business genuinely relies on a process of its own, or when off-the-shelf tools don't cover what you need.

Don't make this call before the pilot ends. Try an off-the-shelf tool first; if it works and usage scales up, moving to custom development is usually less risky than building a bespoke system from the start.

Don't confuse we're using it with success. What needs measuring is whether processing time has genuinely dropped, how the error rate has changed, and whether the team trusts the tool.

The most common mistake is launching a pilot and never measuring the outcome. Three months in, when someone asks is it working, nobody has a clear answer — so decide at the start of the pilot which number you'll track, and check it at regular intervals.

You don't need a complicated dashboard for this. Noting processing time, error count, and team satisfaction in a simple table each week builds a clear picture after a few months — one that also guides which task you pick for the next pilot.