The shape of the stall.
Months one and two of an AI rollout look like progress. The first system ships. The team uses it for two weeks. The senior partner who was skeptical ten weeks ago says something quietly positive at the partner meeting. Hours start coming back. The Slack channel for the rollout has activity.
Month three is when the first hard problem surfaces. An adoption gap, a data inconsistency, an unhandled edge case. The team works it through. Things keep moving.
Month four is where it dies. Not dramatically. The Slack channel goes quiet. The follow-up build that was supposed to start in week 16 doesn't have a scope. The senior who was using the system stops using it for two days, then five, then a week. By month five, the rollout is in its post-mortem phase, and nobody has officially declared it.
This pattern shows up in roughly 60% of the rollouts we audit. Three causes. Each one has a fix.
Cause one: the second-build queue is empty.
The most common cause. The operation commissioned a build for the most painful workflow. It works. The pain is gone. Nobody scoped what comes next, because the partners thought the first build was the project.
What's actually happened is that the first build proved the model, but the model's value compounds across multiple workflows. Without a second build queued, the team treats AI as a one-time intervention rather than an ongoing capability. The momentum dissipates because there's no Q3 build to keep the muscle warm.
Fix: at month two of the first build, scope the second. Don't wait for the first to finish. The senior who is now AI-fluent because of the first build is the right scoper for the second; their attention is the asset that wastes if you don't use it. Lesson 5 of the AI-Ready Course covers tight scoping; rerun it on the second workflow while the first is still building.
Cause two: the senior who shepherded the first build moved on, mentally, in month four.
The second-most-common cause and the one no AI vendor will mention because it's about your business's politics, not their product. The senior who pushed the rollout through partner approval, did the data prep, and ran the change-management is exhausted by month four. Not because the rollout was hard, but because they did it on top of their existing partner workload.
Their attention shifts back to their book of business. The rollout's gravity lapses. The system continues running but stops evolving. Six months later, the system is rotting around the edges and nobody owns it.
Fix: at month one, name the operator who owns the system at month six. It cannot be the partner who scoped it; their incentives don't sustain. The right answer at most mid-market operators is a senior staff person (firm administrator, COO, ops lead) whose job description includes "AI-system owner" as a real line item. Without that named owner, the rollout will stall.
Cause three: the operation hit a guardrail and didn't know it.
Less common but more painful when it happens. The system is running well in production. A partner asks for a slightly bigger workflow expansion. The expansion crosses a guardrail that was scoped in week one (typically: "the system never sends client communications without one-click approval" or "the system never modifies the system of record"). The expansion request is technically blocked.
The partner doesn't see the guardrail; they see the system not doing what they asked. They conclude AI doesn't work for their use case. They quietly disengage. The next ask never comes.
Fix: at month two, run a 30-minute session with the partner group to walk through the guardrails explicitly, in plain English. Let them push on each one. If a guardrail no longer fits, change it deliberately rather than discovering it as a barrier in month four. Guardrails are scoped to be safe for the operation; they are not scoped to be sacred.
The pattern of operators that don't stall.
Across the rollouts we've audited, 40% don't follow the stall pattern. The shape of those is consistent enough to describe:
Second build is scoped at month two of the first build. Named operator owns the system at handoff, not the partner. Guardrails get a deliberate review at month two. The second build ships in month four, the third in month seven. By month nine, the operation is treating AI commissioning as a quarterly cadence rather than a one-time project.
That cadence compounds. The operation at month twelve is in a structurally different position than the operation at month four. The capacity reclaimed by the first build is being reinvested in the second; the cultural muscle memory is set; the AI-fluent senior staff are now the operation's natural translators between partner intent and system capability.
What this means for your rollout, if you're at month two.
Three things to do this week:
1. Scope the second build. The conversation can be 60 minutes; the deliverable is a one-page scope. Use the four-element scope frame: outcome, interface, data, guardrails.
2. Name the post-handoff owner. Make sure their job description includes the system. Make sure that's reflected in their next review cycle.
3. Walk the partner group through the current guardrails. Surface any that no longer fit. Adjust deliberately.
If you're past month four and the rollout has already stalled, the same three steps still work. They just take more deliberate effort to restart momentum.