How to choose your company's first AI project

Your first AI project matters more than the ones that follow. If it works, your team believes in it and ideas start coming from them. If it fails because it was too broad or badly chosen, it will be a long time before anyone listens to you on the subject again.

The choice depends less on the technology than on the task. At Oliverlist, AI has been in our product since May 2023, and the tasks we have given it look alike: sorting prospect replies, writing call scripts, coaching the team. They come back every day, in volumes we can count. That is the profile to look for in a first project.

In many owner-led companies, work runs on email, spreadsheets and WhatsApp. That is a perfectly good starting point: it tells you where your data already is, and where it is not.

Here are five tests, examples of good and bad first projects, and why small is the right size to start.

Five tests for a good first project

1. Repetitive. The same operation, in the same form, dozens of times. You describe the method once, with examples. That is impossible for a task that changes every time.
2. Frequent. Daily or weekly. You see results quickly, the team gets used to it, and errors show up early, while they are cheap.
3. Measurable. You can count time, turnaround, errors or volume, before and after. Without a measurement, the project will be judged on impressions, and impressions depend on who is talking. I explain the method in Measuring the ROI of AI without inventing numbers.
4. Accessible data. What the task needs sits in a mailbox, a shared folder or software that can export it. Not on paper, not in one person's head, not on one salesperson's personal phone.
5. Someone who approves. A person who knows the task, reviews what the AI produces and can say: this is right, or this is wrong. If your team works in several languages, that person must read the language the output is written in. Without them, nobody will use the tool and nobody will improve it.

A project that passes all five tests is a good candidate. If one is missing, fix that first or pick another project.

Examples of good first projects

Depending on your business, these often pass all five tests:

• a shared inbox (info, orders, customer service): classify each message, summarise it, draft the reply, have it approved;
• overdue invoice reminders: spot late payers, draft a reminder suited to each client, approve it before it goes out;
• reading purchase orders or supplier invoices: extract the lines and prepare them for your system;
• first drafts of simple quotes, on a well-known product range, from the request and past prices;
• a weekly activity summary: the week's figures, the gaps, the points to look at, ready for the management meeting.

They share one feature: an output someone can check quickly, and an error that can be caught before it reaches a client.

I have covered two sectors in more detail: accounting and tax firms and quoting in industrial companies.

Bad first projects

Bad first projects look alike too:

• too broad: "AI everywhere", "an assistant that answers everything". Impossible to measure, impossible to finish;
• too rare: the annual budget, a one-off study. Once a year, you learn nothing and measure nothing;
• hard to check quickly: a pricing decision, a hire, a legal opinion. The output calls for judgment nobody can verify in a few minutes;
• no data: orders arrive as WhatsApp voice notes on a salesperson's phone. Bring them into a shared system first;
• alone with clients from day one: a bot answering clients with no review. Start internally, with approval, and open up later.

There is one subtler case: the task that does not need AI at all. When a task follows fixed rules, classic automation does the job at a lower cost. At Oliverlist, that is where our big productivity jump came from: between 2019 and 2023, revenue per person tripled thanks to automation, before generative AI. Sometimes the right first project is connecting two systems, not adding AI.

Why start small

Starting small does not mean building a demo. A useful first project runs on a real flow, with real data, and the team uses it every day. Small means one task, one team, a narrow scope.

The reasons are simple:

• results come fast: within a few weeks, you know whether it works;
• errors are cheap: on a narrow scope, every error is visible and gets fixed, and every fix becomes a rule;
• you learn how AI gets things wrong on your data, which helps with every project after it;
• your team sees the tool doing their real work, which convinces more than a presentation;
• the next project is easier to choose: the first one shows where the data is, who approves and what is missing.

At the start, AI proposes and a person approves everything. Approval is then relaxed case by case, as errors become rare. Once the first project is running, it becomes the template for the next one: same method, same measurement, same approval rule.

Key takeaways

• Choose a task that is repetitive, frequent and measurable, with accessible data and someone to approve the output.
• Between two candidates, take the one that comes back every day rather than every month.
• Avoid projects that are too broad, too rare, without data or hard to check.
• Name the person who approves and take a baseline before you start.
• Check that simple automation would not do the job.
• Small scope, real flow: your first project runs in production, not as a demo.