Plenty of enterprise AI projects start with a successful pilot. The demo impresses leadership, a small team tries it, feedback is positive. Then nothing happens. Six months later it's still a pilot, or it's quietly been forgotten.
Taking Frontline at WiZR from an early concept to a commercial enterprise rollout meant getting through that stage with several clients. The pilots that turned into real deployments were usually planned differently from the start. The ones that stalled tended to fail for predictable reasons.
Why pilots stall
| Reason | What it looks like | What helps |
|---|---|---|
| No agreed success criteria | "It was interesting" but no decision | Define what success means before starting |
| Wrong users | Enthusiasts who aren't typical users | Include everyday users from the real workflow |
| Not connected to real systems | Works in isolation, can't be used for real work | Plan integration early, even if basic |
| No owner after the pilot | Champion moves on, nobody takes over | Name a business owner from the start |
| Security and legal arrive late | Review blocks rollout after a successful pilot | Start reviews in parallel with the pilot |
| Cost not understood | Budget question appears at the end | Estimate production cost during the pilot |
Agree on success before you start
Write down with the client what would count as a successful pilot. Time saved on a specific task, quality of output, adoption by a team, whatever matters to them. Agree on how it'll be measured and when.
Without this, a pilot can be positive and still not lead to a decision, because nobody agreed what positive meant. I covered the measurement side in the AI adoption metrics post.
Use real users and real work
A pilot with a handful of enthusiastic volunteers using sample data tells you the technology works. It doesn't tell you whether the product will be adopted by people who didn't volunteer, using their actual work.
Include some everyday users from the team that would use it in production. Use real tasks where you can, with appropriate data handling. Their feedback is less flattering and much more useful.
Plan the path to production during the pilot
The questions that block production usually aren't new. Security reviews, data handling agreements, integration with existing systems, user training, support. Start them while the pilot runs instead of after.
Enterprise security teams often have detailed questions about AI products specifically: where data goes, how outputs are checked, what guardrails are in place. Having answers ready shortens the process a lot.
Name an owner on the client side
Someone in the client organisation needs to own the outcome. Not just the champion who brought you in, but someone with authority over the workflow and budget. If that person isn't identified, the pilot has nowhere to go when it ends.
Set a decision date
Pilots without an end date drift. Agree on a date when the client will decide: roll out, extend with specific changes, or stop. Stopping is a valid outcome. A clear no is much better than an indefinite maybe.
Plan for what changes at scale
Things that work fine for twenty users can break for two thousand. Response times, cost, review capacity, support load, and the variety of requests all change. Before rolling out, think through which of these will matter and how you'll handle them.
For voice agents, scale also means more calls that need a person, so the handoff to a human has to be staffed and tested before rollout. A phased rollout, team by team, usually works better than switching everyone on at once. It also gives you more chances to learn and adjust.
What I'd do differently
Looking back, I'd push harder on success criteria and client ownership in the first week. Those two things predicted whether a pilot would move forward better than any measure of output quality. A good model with no owner stalls. A decent model with a committed owner and clear goals usually finds a way into production.