Where should your business start with AI?

Choosing a first AI project starts with understanding the work. What takes time, what information does it require, and what would a better result look like? Those questions help narrow a broad interest in AI into a project a team can define, build, and evaluate.

This guide walks through how to find candidate tasks, check whether the information behind them is usable, decide what success means, and pick one project to start with. The examples use a made-up company: a regional building supplies distributor with a sales desk, a customer service team, and a small finance group.

Start with the work people already do

The most useful place to look for project ideas is a plain account of how people spend their week. Ask each team to describe the tasks they repeat, and keep the questions concrete:

• What do you do every week that follows roughly the same steps?
• Where do you copy information from one place into another?
• What sits in a queue waiting for someone to get to it?
• Which tasks need you to read a document or email and decide what it means?
• Where do mistakes usually get caught, and how late?

At the distributor, these conversations turn up a familiar list. Customer service answers order-status emails by looking up each order in the ERP system. The sales desk retypes purchase orders that arrive as PDF attachments. Finance matches supplier invoices against deliveries. The sales manager would like a better demand forecast.

Each of these could involve AI. The next steps help sort the ideas that are ready from the ones that need groundwork first.

Look for tasks with a few traits in common. They happen often. They take real time each time. They involve reading, sorting, extracting, or drafting. And a person who does the work today can tell you whether a result is right.

Check that the information is there

An AI system works with the information it's given. If that information is scattered, out of date, or hard to reach, the project will stall before the choice of model matters.

For each candidate, trace where its inputs live and how a system would reach them:

• Location. Is the information in a system with an API, a database you can query, a shared drive, or someone's inbox?
• Access. Who controls it, and would they approve a new system reading it?
• Consistency. Do the documents follow a few common formats, or does every supplier send something different?
• Sensitivity. Does it include personal data, pricing, contract terms, or anything covered by customer agreements?
• Ownership. If a field is wrong, who fixes it?

At the distributor, purchase orders arrive by email, the product catalog sits in the ERP, and customer-specific pricing lives in a spreadsheet maintained by one person. The first two are workable. The spreadsheet is a risk, because the project would depend on one person keeping it current. That doesn't rule the project out. It goes on the list of things to fix or design around.

Forecasting looks different once you trace the inputs. Historical sales data exists, but returns, promotions, and stock-outs are recorded inconsistently. A forecasting project would start with months of data cleanup. That may be worth doing later. It's probably a poor fit for a first project.

Define what a better result looks like

Before building anything, write down what the project should change and how you'll know it did. One sentence is enough to start: "Reduce the time the sales desk spends entering purchase orders, while keeping order errors at or below today's level."

Then make it measurable:

• Pick the measures. Time per item, turnaround time, the share of items that need correction, and errors that reach a customer are common choices.
• Record a baseline. Measure the current process for a few weeks. Without a baseline, any improvement is a guess.
• Collect real examples. Gather a sample of past items with known correct outcomes. For purchase orders, that means the original PDFs alongside the orders as they were finally entered. This sample becomes your test set.
• Decide who reviews. In the first version, a person usually checks every output. Name that person and agree on what they do when something is wrong.

The test set does a lot of work later. It lets you compare approaches on the same inputs, and it shows whether a cheaper or faster design still holds up. We cover that in more detail in how to evaluate cost and quality in an AI workflow.

Compare the candidates

With inputs traced and goals drafted, put the candidates side by side. A short set of questions is usually enough:

• How often does the task happen, and how long does it take each time?
• Can a system reach the information it needs today?
• Is there a clear right answer, or at least a person who can quickly judge the output?
• What happens if the output is wrong, and will someone catch it before it matters?
• Is there a team that wants this and will own it after launch?

Here's how the distributor's list might come out.

Purchase order entry scores well. Volume is steady, the inputs are documents the team already receives, and the correct result is the order as it should appear in the ERP. A reviewer can check each extracted order before it's submitted. The sales desk wants it.

Order-status replies make a good second project. The emails are simple, but the system needs reliable read access to the ERP, and that connection takes some setting up.

Supplier invoice matching is promising. Finance has a quarter-end close coming, though, and nobody has time to review outputs until it's done.

Demand forecasting has the weakest fit for now. The data needs work, and a forecast takes months to judge.

The result is a first project with a clear input, a clear output, a reviewer, and a team that cares about it. It may be the least ambitious idea on the list, and that's fine. A project the team can finish and measure builds the experience and trust the next one needs.

Keep the first version small

A small scope makes the first version easier to build, test, and trust. For the distributor, that could mean one team, the most common purchase order formats, and a reviewer approving every order before it reaches the ERP.

It helps to plan the stages up front:

• Prototype. Run the approach against the test set. Check accuracy on each field and note where it struggles.
• Pilot. Use it on live work for a few weeks alongside the existing process. Track the same measures as the baseline, plus review time.
• Production. Expand to more formats or more of the team once the pilot results hold up.

Agree before the pilot on what result would justify moving forward and what would make you pause. That keeps the decision tied to the measures you chose at the start.

Plan the operating side early too. Someone needs to own the system after launch, watch its results, and update it when formats or processes change. Usage, hosting, and maintenance carry ongoing costs, which we cover in how to plan the ongoing cost of an AI system. Access rules, approval steps, and records of what the system did belong in the plan from the first version.

Questions to bring to a first conversation

Whether you're talking to an internal team or an outside partner, answers to these questions make a first conversation about an AI project much more productive:

• Which task do you have in mind, and who does it today?
• How often does it happen, and roughly how long does each one take?
• Where do the inputs come from, and can a system access them?
• What does a correct result look like? Do you have past examples?
• What happens when the result is wrong?
• Who will review outputs during the pilot?
• Who owns the system once it's running?

You don't need complete answers to all of them. The gaps are useful too, because they show where the groundwork is.