Getting an AI pilot to show results is not the hard part anymore. The hard part is what comes next.
Most enterprise organizations can point to at least one AI initiative that produced promising early numbers and then plateaued when adoption remained lower than expected. The use cases that worked in the controlled environment did not produce the same results when rolled out more broadly. A few departments embraced the new workflow, but others did not change their behavior at all. The executive sponsor moved on to the next priority. The program kept running but stopped compounding.
This pattern showed up in the background of nearly every AI strategy workshop INRY facilitated across healthcare, retail, manufacturing, higher education, engineering, and professional services. Leadership teams were not starting from zero. They were starting from a first attempt that had not scaled. And the question they were really asking was not “should we invest in AI?” It was “why didn't the last investment do what we expected, and how do we make sure this one does?”
The answer was consistent across every industry and function. It comes down to two things that organizations underinvest in, almost universally, in the early stages of AI deployment.
The word “trust” shows up in a lot of AI strategy documents. Usually it is positioned as a cultural consideration, something to manage through communication and change management. That framing is not wrong, but it is incomplete in a way that causes real problems.
In practice, trust in an enterprise AI context is an infrastructure question. It is about whether the system behaves consistently, whether decisions can be explained and audited, and whether humans retain meaningful control over outcomes that carry risk. Organizations that treat trust as a communication problem rather than a design requirement end up with AI systems that work well in demos and fail to gain traction at scale.
Here is what the organizations that scaled their AI programs had in common:
One pattern INRY observed repeatedly: organizations that moved fast on deployment without establishing governance ran into a ceiling at roughly the 60 to 90 day mark. While early adopters were using the tools, the broader population was watching and waiting. When they saw edge cases handled inconsistently, or when they could not understand why the AI had made a particular recommendation, adoption stalled. Rebuilding confidence after that point is significantly harder than building it correctly at the start.
The executives who understood trust as a critical part of infrastructure rather than sentiment made very different decisions about sequencing. They were willing to spend time on knowledge structure, governance design, and exception-handling frameworks before pushing for broad rollout. That investment consistently produced faster and more durable adoption than in the organizations that prioritized speed of deployment over integrity of design.
This may be the single most consistent finding across all 12 workshops. There is a widespread assumption in enterprise AI programs that if you build a good enough tool and deploy it to enough people, adoption will follow. That assumption is wrong, and organizations that operate on it will keep being surprised by the gap between what the technology can do and what the organization actually does with it.
Adoption at scale requires a different kind of investment than deployment. It requires understanding how the people doing the work currently do it, where the new workflow is genuinely easier versus where it creates friction they were not expecting, how managers are reinforcing or inadvertently undermining the new behavior, and what the feedback loops look like when something does not work as expected.
“Teams are too overloaded to fix their own processes. Competing priorities, after-hours work, and constant firefighting leave no capacity for strategy or coaching.”
— Service manager, INRY workshop participant
This is a capacity trap. The people who would most benefit from AI-enabled efficiency are the same people who are too overwhelmed by existing workload to learn and adopt a new way of working. Deployment does not solve this. A structured adoption program that accounts for where capacity is being consumed, and that builds adoption activity into existing workflows rather than layering it on top, is what solves this.
The organizations that sustained AI momentum past the pilot stage had all built adoption measurement into their programs from the beginning. They were tracking virtual agent utilization, self-service containment rates, knowledge article engagement, and manager-level adoption alongside technical deployment metrics. When adoption lagged in a specific group or workflow, they could identify it quickly and respond specifically, rather than applying a generic communication campaign and hoping the numbers improved.
One of the most valuable outputs of the INRY AI strategy workshops was not a list of use cases. It was a sequenced roadmap that reflected where each organization actually was, not where they wanted to be.
Most enterprise organizations have more potential AI use cases than they can fund or staff. The discipline of the workshop methodology was in scoring those use cases against two variables: business impact and implementation feasibility, given the organization's current state. Those two variables, not feature richness or vendor enthusiasm, determined what went into the near-term roadmap.
Organizations that skipped this discipline, attempting to pursue high-impact, high-complexity use cases before establishing the foundational capabilities those use cases depend on, consistently struggled. It was not that the use cases were wrong, but that the sequence was. AI programs build on themselves. Foundational investments in knowledge structure, virtual agent capability, and self-service design create the infrastructure that advanced use cases require. Attempting the advanced use cases first produces a system that is impressive in a controlled environment but breaks down at scale.
The organizations that moved fastest were not necessarily the ones with the most ambitious roadmaps. They were the ones with the most honest assessments of where they were starting from and the discipline to build in the right order.
If your AI program has stalled after a pilot, the diagnosis is usually not that the technology did not work. It is that governance and adoption were treated as downstream concerns rather than foundational design requirements. But that does not mean you have to start over. It means the path forward requires you to be honest about what was built and what is missing, and to address the gaps in the right sequence.
If your organization has not yet moved past the planning stage, the research from these 12 workshops gives you a significant advantage. The patterns are clear enough that you can avoid the failure modes that slowed other organizations down, design governance infrastructure before you need it, and build adoption programs that account for where your employees actually are rather than where you hope they will be.
The INRY AI strategy workshop was designed specifically to help enterprise leadership teams do this work with precision and without wasting the organizational capital that a poorly sequenced AI program consumes. INRY brings the methodology, the field findings, and the ServiceNow platform expertise. You bring the executive team and the business problems. The output is a roadmap your organization can actually execute.
The full eBook, “The AI Advantage: What Executive Workshops Reveal About Generating Real Value from ServiceNow AI,” contains the complete findings from every workshop engagement, the use case scoring methodology, and the business case frameworks that executive sponsors have used to secure investment and sustain it. Download it now or contact INRY to discuss what a structured AI strategy engagement looks like for your organization.
Most programs stall because governance and adoption are treated as phase-two concerns rather than foundational design requirements. The pilot shows results in a controlled environment, but when the program expands, adoption stays lower than expected, edge cases are handled inconsistently, and the business case becomes harder to defend. The technology is rarely the problem; the sequence and the missing governance and adoption infrastructure usually are.
Organizations that scale build governance into the deployment architecture before they expand, define which decisions require human review and make that logic auditable, establish systematic feedback mechanisms, and design AI to surface its reasoning. They also measure adoption from the beginning, tracking virtual agent utilization, containment rates, and manager-level adoption, so they can respond specifically when adoption lags.
In an enterprise context, trust is an infrastructure question, not just a cultural one. Governance determines whether the system behaves consistently, whether decisions can be explained and audited, and whether humans retain control over risky outcomes. Organizations that move fast without governance tend to hit an adoption ceiling around the 60 to 90 day mark, and rebuilding confidence after that point is much harder than building it correctly at the start.
Score potential use cases against two variables, business impact and implementation feasibility given the current state, and let that scoring drive the near-term roadmap. Foundational investments in knowledge structure, virtual agent capability, and self-service design create the infrastructure that advanced use cases depend on. Attempting high-impact, high-complexity use cases before those foundations are in place produces systems that work in controlled environments but break down at scale.