A client completes a full rollout of AI-enabled collaboration tools across fifty conference rooms. The vendor training is done. The IT team has pushed the software updates. End users have watched the onboarding videos. Three months later, the rooms are running the same way they always did. Nobody is using the AI meeting summaries. The intelligent camera framing is switched off on half the systems. The noise suppression keeps getting disabled because people do not trust what it is doing to their audio. The integrator gets called back in. The instinct on both sides is to blame the users.

That instinct is usually wrong, and acting on it wastes time and budget.

What actually happens in most enterprise AV deployments is this: users receive access to a capable system, complete whatever onboarding is required, and then walk into rooms that have not changed in any meaningful way. The booking workflows are the same. The meeting behaviours are the same. IT policy still treats the conferencing endpoint as a peripheral rather than an intelligent participant in the room. Nobody has defined whether the AI-generated transcript is the official record, who reviews it, or what happens when it gets something wrong. People are left to figure out the rules of engagement themselves, and in the absence of clear rules, they default to what they know. That is not a training failure. That is a structural failure in how the deployment was scoped and handed over.

The gap that most AV and UC deployments are falling into right now is the gap between technical commissioning and operational readiness. Getting a room certified, connected, and performing to spec is the work integrators know how to do. But increasingly, the value of what is installed depends on a second layer of work that almost nobody is formally responsible for: defining how the human and the AI system are supposed to operate together in that room. What does the room intelligence actually own? When does a user override it, and what happens when they do? Who is accountable when an AI-generated action item from a board meeting turns out to be wrong? These are not questions a firmware update answers. They are organisational design questions, and if they are not answered before deployment, they get answered inconsistently by whoever is sitting in the room at the time.

For integrators advising enterprise clients on room upgrade cycles or larger UC infrastructure decisions, this creates a practical opportunity. The clients who are frustrated with AI adoption are not, in most cases, frustrated because the technology is failing. They are frustrated because the conditions required for the technology to deliver value were never put in place. That is a conversation about role clarity, workflow integration, and who owns the feedback loop when the system gets it wrong. Integrators who can have that conversation alongside the technical one are able to position themselves as deployment architects rather than equipment vendors. It changes the scope of the engagement and, frankly, it changes the margin on it.

The reframe for your next client conversation is straightforward. Before asking whether your users need more training on the AI features, ask whether the organisation has actually defined what those features are supposed to do, who is responsible for them, and what success looks like in operational terms. A well-specified room with an under-specified operating model will underperform every time. That is not a user problem. It is a design problem, and it is solvable.

Read the full analysis at intelligentworkplace.ai