“We should do something with AI.” The sentence is heard in many businesses, and afterwards it often goes quiet. Not because nobody has ideas, but because there are too many: writing quotes, sorting the mailbox, checking invoices, supporting the field team. You have to start somewhere, and the first attempt decides whether there is a second.

A pilot project is not a small task that runs on the side. It is the attempt to show, in one place, what AI does for your business and what it does not. For that, the place has to be chosen well. This article describes how to recognise a good start, with examples from everyday business, and where you are better off not beginning.

Five marks of a good start

  • The task recurs. It comes up regularly, always in a similar shape, and takes time from staff who would rather spend it elsewhere. A task that rarely occurs is not worth the effort.
  • The result is easy to check. Anyone can see at a glance whether an invoice was matched to the right order. Whether a text is “good” is a matter of taste.
  • A person stays in the sign-off. The AI proposes, a member of staff checks and approves. Nothing leaves the building that nobody has seen.
  • The data exists. The invoices sit as PDFs in the mailbox, the old quotes on the drive. If the AI first needs data that nobody records, the project is two projects.
  • Staff feel the benefit. The best pilot takes a job off someone who dislikes doing it. Then there is someone who wants the project to succeed.

Examples from everyday business

  • Pre-sorting incoming invoices. The AI reads the invoice from the mailbox, recognises supplier, amount and order number and matches it to the order. Accounts check and post.
  • Routing enquiries in the mailbox. What arrives at info@ is recognised and passed to sales, service or accounts, with a note on what it is about.
  • Preparing quotes from templates. From the enquiry and earlier quotes for similar orders, a draft emerges. Sales add prices and send it off.
  • Searching documents. Staff ask in their own words what the contract, the minutes or the assembly instructions say, and get the answer with its source. How that works is described in How AI reads your documents.
  • Summarising minutes and notes. The field team’s notes from customer conversations become a summary with open points for the CRM.

All five have one thing in common: the AI prepares, a person decides, and the result can be checked.

Where not to start

  • Customer communication without sign-off. A chatbot that answers customers directly, or emails that go out unread. The first mistake lands with the customer, not with you.
  • Decisions that carry liability. Credit checks, recruitment, approving payments. This is not about technology but about responsibility, and that stays with people.
  • Projects that touch the whole business. “The AI should take over scheduling” is not a pilot but a replacement. At the start, the experience and the trust for that are not there yet.
  • Tasks without data. If the information the AI would need lives only in the foreman’s head, something else has to happen first.

What AI fundamentally cannot do, and why sign-off is not distrust, is covered in What AI cannot do for your business.

Measuring success without inventing figures

Many pilot projects end with a slide showing a percentage nobody can recalculate. You avoid that by writing down, before the start, how you will know it has worked. For example:

  • Accounts no longer match invoices by hand but only check suggestions.
  • Nothing unassigned is left in the mailbox at the end of the day.
  • Sales no longer start a quote from a blank page.
  • The staff who work with it do not want to give it up.

A second sheet belongs with it: how will you notice that it is not working? How many suggestions may be wrong before checking them is more work than the old manual routine? Whoever settles that in advance can also end the pilot without it being a defeat.

What has to be in place before you start

A pilot needs little, but that little has to be right. The workflow the AI is meant to support must be described, at least roughly: who does what today, in which order, with which documents? How to write that down without producing a manual is described in Documenting business processes. The data must be reachable, with the permissions the people involved already have. And it needs one person in the business who wants the project and is available to colleagues.

Questions before you decide

  • Which task recurs regularly and is disliked?
  • Can you see at a glance whether the result is right?
  • Who signs off before anything goes outside?
  • Is the data there, and who is allowed to see it?
  • How will you recognise success, and how will you recognise failure?

If one project remains after these questions, it is usually the right start. If several remain, take the one whose result is easiest to check.