Most businesses that stall on AI don't stall because the technology disappoints them. They stall because the first project was the wrong one: too ambitious to finish, too vague to measure, or too far from anyone's daily work to get used.
The first project does a second job beyond saving time. It sets how the rest of the company feels about AI. A small win that people actually use makes the next project easy to approve. A sprawling pilot that never quite ships makes every later proposal harder to sell.
Start with a task, not a technology
The most reliable way to pick badly is to begin with 'where can we use an AI agent?' That question produces a list of impressive-sounding ideas with no owner. A better starting point is a list of tasks someone on your team does repeatedly and would happily hand off: sorting an inbox, re-keying data between two systems, drafting the same kind of reply for the hundredth time.
Ask the people doing the work, not just the people managing it. The person who processes forty invoices a week knows exactly which step is tedious and which step needs a human eye. That detail is what separates a project that fits the work from one that fights it.
Score candidates on four things
Volume: does the task happen often enough that automating it matters? A task done twice a month rarely repays the effort. Clarity: can you write down what a correct result looks like? If two experienced people would disagree about the right answer, an automation will inherit that disagreement. Cost of a mistake: what happens if the system gets one wrong? Drafting a first-pass reply is forgiving; issuing a payment is not. Access: does the task live in systems that can be reached, or does it depend on information that only exists in someone's head?
A strong first project scores well on volume and clarity, tolerates occasional mistakes because a person reviews the output, and works with systems you already have access to. It doesn't need to be the most valuable task in the company. It needs to be one you can finish.
Keep a person in the loop at the start
For a first project, design the system so a person approves the result before it goes anywhere consequential. That feels slower than full automation, and that's the point. Reviewing real outputs shows you where the system is strong, where it hesitates, and which edge cases nobody mentioned during scoping.
Once the review step shows the system is right consistently on a particular kind of case, you can let that kind of case through without approval and keep the review for the rest. Autonomy earned from evidence holds up far better than autonomy granted on day one.
Define success before you build
Decide in advance what you'll measure. Hours spent on the task before and after, turnaround time, error rate, or the share of cases that needed human correction. Pick one or two and write down today's number, because it is surprisingly hard to reconstruct a baseline after the fact.
Without a baseline, every project ends in an argument about whether it worked. With one, you can say plainly that it saved a certain amount of time, or that it didn't yet, and decide what to change. Both answers are useful. Silence is not.
Common ways first projects go wrong
The biggest one is scope creep dressed up as ambition: a project that began as 'sort the support inbox' becomes 'transform customer service' before the first version exists. Keep the first version narrow enough that you can describe it in a sentence.
The second is building something nobody asked for. If the people who would use the system haven't seen it until launch day, expect a polite shrug. Show them early and often, and change the plan when they point at something that doesn't fit how they work.
The third is ignoring maintenance. Systems connected to real tools need attention when those tools change. A project with no owner after launch tends to decay quietly until someone notices it has been wrong for weeks.
Pick a repetitive task someone wants to hand off, make sure a correct result is easy to define, keep a person reviewing at first, and measure against a baseline you wrote down before building. A small project that ships and gets used will do more for your AI plans than a large one that doesn't.