Your First AI Pilot: How to Scope It So It Actually Ships

The graveyard of enterprise AI is not full of bad technology. It's full of pilots that were never really scoped: projects that started as "automate invoice intake," grew into "transform finance," and died in month six with nothing in production. The difference between an AI pilot that ships and one that stalls is decided before anyone writes a line of code. Here's how to decide it well.

Why Most First AI Projects Never Ship

Three patterns account for most stalled pilots. The first is scoping by ambition: picking a project big enough to excite leadership, which is usually a project too big to finish. The second is building without a baseline: six weeks in, the tool works, but nobody can say what it improved, so nobody will fund the next step. The third is fuzzy ownership: no single person is accountable for the pilot succeeding, so it becomes everyone's side project and no one's job.

All three are scoping failures, and all three are avoidable with a few decisions made up front. The rest of this guide walks through those decisions in order.

Step 1: Pick One Workflow — and Only One

A good pilot workflow has a specific shape. When we help clients choose (the ranking exercise is the core of our AI readiness audit), we look for candidates that check most of these boxes:

• High frequency. It happens daily or weekly, so a measurement window of a few weeks produces real data.
• Painful but bounded. It consumes meaningful hours, yet has a clear start and end — "draft the response," not "improve customer experience."
• Accessible data. The documents and records it touches are already digital and reachable without a six-month integration project.
• Tolerant of review. A human can check the output before it matters, which lets you deploy before the system is perfect.
• An owner who feels the pain. Someone on the team wants this fixed badly enough to give feedback every week.

If several candidates qualify, pick the boring one. Document drafting, intake triage, data entry between systems, and first-pass categorization make excellent pilots precisely because they are unglamorous, frequent, and easy to measure. For a menu of proven candidates, see our list of AI workflow automation examples.

Step 2: Measure the Baseline Before You Build

This is the step teams skip, and it is the one that decides whether the pilot can ever be judged. Before the build starts, capture how the workflow performs today: how many items per week, how many minutes per item, how often errors occur and what they cost, and how long the end-to-end cycle takes. A week of honest tallying beats a year of retrospective guessing.

The baseline doesn't need to be scientific — it needs to be written down and agreed on before the pilot begins, so nobody can argue about it after. Our AI ROI measurement framework covers what to track and how to report it in a way finance will accept.

Step 3: Write Success Criteria a Skeptic Would Accept

"See if AI can help" is not a success criterion. A usable one names a metric, a threshold, and a deadline, and it includes the kill condition. For example: the assistant drafts at least 70% of weekly volume with outputs the reviewer accepts unedited or with minor edits; per-item handling time drops measurably against the baseline within the pilot window; if reviewers are rewriting most outputs by week four, we stop and write up why.

The kill condition is the credibility mechanism. When leadership sees that the pilot can fail on explicit terms, they trust the result when it succeeds. It also protects the team: a pilot that can be killed cleanly is one nobody has to quietly babysit forever.

Step 4: Draw the Scope Line and Defend It

The moment a pilot shows promise, requests arrive: can it also handle the other document type, the other team, the other language, the edge case from 2019? Each request is individually reasonable and collectively fatal. The discipline that works is simple: keep a visible phase-two list, and put every new idea on it without debate. The pilot ships the original scope; the list becomes the roadmap discussion after the measurement is in.

Three scope rules we hold to on every pilot:

1. One workflow, one team. Cross-department rollout is a scaling problem, not a pilot problem.
2. Human review stays in the loop. Removing review is a decision you earn with measured accuracy, not one you schedule in advance.
3. No new systems mid-pilot. If a feature needs an integration that wasn't in the plan, it's phase two by definition.

A Realistic Pilot Timeline

A well-scoped pilot for a single workflow typically runs four to eight weeks. The first stretch is setup: access to systems and data, baseline confirmation, and agreement on the success criteria in writing. The middle is the build, done against real historical cases rather than invented demos, with the workflow owner reviewing outputs weekly. The final stretch is the measurement window: the tool runs on live work, with humans reviewing, while the numbers accumulate. Then comes the readout — baseline versus pilot, in one page.

If a proposed pilot plan runs past a quarter, it isn't a pilot; it's a project wearing a pilot's name tag, and it carries a project's risk without a project's justification.

After the Pilot: Kill, Fix, or Scale

A finished pilot ends in one of three decisions. Kill it if the criteria weren't met and the reasons are structural — the data was worse than believed, the judgment involved was deeper than it looked. Fix it if the misses are specific and addressable, and run a short second measurement. Scale it if the criteria were met — which opens the genuinely hard questions of rollout, training, and governance that we cover in the enterprise AI implementation roadmap.

Whichever door you walk through, you walk through it with evidence. That is the entire point of a pilot, and it's why scoping — not modeling, not tooling — is where first AI projects are won.

Frequently Asked Questions