The first 90 days of an AI deployment: what good looks like
The first ninety days decide whether an AI project becomes a working system or another stalled pilot. Most of the 95 percent that fail were lost in this window, not because the technology was wrong, but because the wrong things were prioritised. This is a plain account of what a healthy first quarter looks like, and the warning signs that one is going off the rails.
Days 0 to 30: scope one number and wire in
A healthy deployment starts with subtraction, not ambition. The first month is for naming the single metric the build will move, response time to a first inquiry, the share of leads that convert, the cost of a backlog, and saying no to everything else. A first quarter aimed at one number ships; a first quarter aimed at a transformation stalls. This is also where the integration work begins, mapping the systems the agent must read from and write to, because an agent wired into nothing is the demo that never reaches production.
What good looks like by day 30: a single agreed metric, a documented view of where it leaks, and a clear picture of how the system will connect to the tools your team already uses. What it should not look like: a long feature list, a platform chosen before the problem was diagnosed, or a scope that has quietly grown to touch every department.
Days 30 to 60: ship narrow into production
The second month is for getting a real, narrow system in front of real volume. Not a sandbox, not a controlled pilot for a friendly audience, but the actual workflow with actual inquiries, owned by the client. This is the step most projects defer and the deferral is fatal, because everything you need to learn only appears under real conditions: the messy data, the edge cases, the Tuesday afternoon when something breaks. Production is where the project starts being real.
What good looks like by day 60: a live agent doing one job against genuine volume, instrumented so the metric from month one is being measured, not assumed. The warning sign is a pilot that keeps getting polished but never goes live, perfection used as a reason to avoid the exposure of production. A working system measured against a real number beats a flawless demo every time.
Days 60 to 90: rebuild against the real result
The third month is where the value is actually made, in the loop of measuring against the real number and rebuilding what falls short. This is not failure, it is the method. Our own voice agent connected on fewer than one in ten calls when it first went live and was rebuilt until it cleared better than one in three. That gap closed in the rebuild loop, not in the original build, and no amount of upfront design would have substituted for it.
What good looks like by day 90: the metric has moved in a way leadership can see, the system is owned by the client with the code, data, and prompts in their hands, and there is a documented plan for who runs and tunes it next. The warning sign is a system that launched and was left alone, treated as a finished purchase rather than an operating capability that needs an owner.
The warning signs across all three months
A few signals predict a stall regardless of timeline. Scope that grows instead of narrowing. A metric that nobody can name, or that keeps changing. A pilot that never reaches production. A partner who says yes to everything and never tells you where AI will not help. And a plan that ends at go-live, with nothing said about who runs the system afterward. Any one of these is a reason to pause and correct, because each is a known path into the 95 percent.
The healthy pattern is the opposite in every case: narrowing scope, one stable number, early production, honest no's, and a named owner for the run. None of it is glamorous, and that is rather the point. The first ninety days reward operational discipline, not technical ambition.
What you should expect from a partner
A serious partner runs this rhythm by default: diagnose to one number, integrate, ship narrow, measure, rebuild, and hand over an owned system with a plan for who maintains it. They will push back on scope, ship sooner than feels comfortable, and show you the real metric rather than a flattering dashboard. They will also tell you, early, if the number is not moving, because a clear no in month two is worth more than a hopeful pilot dragged through month six.
Done well, the first ninety days compound: month four starts from a system already in production with a number already moving, so the second build is funded by the first result rather than by faith, and the engagement builds on proof instead of restarting on hope. Treat the first quarter as the test of the whole engagement, because it usually is.
Common questions
- What should the first 90 days of an AI deployment look like?
- Month one: name the single metric the build will move and wire the system into the tools your team already uses. Month two: ship a narrow agent into real production against genuine volume. Month three: measure against the real number and rebuild what falls short, then hand over an owned system with a plan for who runs it. Each phase is about operational discipline, not technical ambition.
- Why are the first 90 days of an AI project so important?
- Most of the projects that fail are lost in this window, not because the technology was wrong but because the wrong things were prioritised: scope grew, no metric was agreed, or the pilot never reached production. A disciplined first quarter, one number, early production, and a rebuild loop, is what separates a working system from a stalled pilot.
- How fast should an AI system go into production?
- Sooner than feels comfortable, ideally within the first two months. Everything that matters, the messy data, the edge cases, the real failure modes, only appears under genuine conditions. A pilot that keeps getting polished but never goes live is following the failure pattern; a narrow system measured against a real number in production beats a flawless demo.
- What are the warning signs an AI deployment is failing?
- Scope that grows instead of narrowing, a metric nobody can name or that keeps changing, a pilot that never reaches production, a partner who says yes to everything, and a plan that ends at go-live with no owner for the run. Any one of these is a known path into the roughly 95 percent of pilots that never reach measurable impact.
- What should we expect from an AI partner in the first quarter?
- A clear rhythm: diagnose to one number, integrate, ship narrow, measure, and rebuild, then hand over a system you own with a plan for who maintains it. Expect them to push back on scope, ship early, show the real metric rather than a flattering dashboard, and tell you honestly if the number is not moving, because a clear no in month two beats a hopeful pilot in month six.