AV & IT in the Enterprise – Post 5 of 6
The standard is written. The archetypes are defined. The rooms are built. The ribbon has been cut and the project has been signed off.
Now it is Monday morning and something does not work.
The question of who picks up the phone is not a technical question. It is a governance question. And in most organisations, nobody has answered it.
The Support Gap
Post 1 of this series opened with a familiar scene. A new office. A ribbon cutting. A helpdesk ticket already waiting.
The support gap is not a new problem. But it looks different from the operational side than it does from the procurement side.
From procurement, the gap is invisible. The integrator was paid. The SOW was delivered. The rooms work on day one. Job done.
From operations, the gap surfaces slowly. The integrator has handed over and moved to the next project. Facilities think the rooms are an IT system. IT think they are a building system. The managed service agreement, if one exists at all, covers what the contract says and nothing more.
The vendor and OEM management portals have largely solved the visibility problem. The tooling exists across the major platforms and certified hardware ecosystems to provide real-time estate health, call quality data, and device status across the entire managed estate. The data is there. The question is whether anyone has configured the alerts, whether there is a defined owner watching the dashboard, and whether there is an escalation path that activates when a problem surfaces. Visibility without accountability is not a support model. It is a dashboard nobody checks.
The user in the room does not care about the org chart. They care that the call starts.
The Burden of Knowledge
There is a concept that rarely gets named in enterprise AV design but sits at the centre of almost every support problem. Call it the burden of knowledge.
In a well-designed room estate, the user carries almost none of it. They walk in, they press join, the call starts. The standard absorbed the complexity. The archetype resolved the platform question before anyone sat down. The interop paths were tested before the room was certified. Nothing in the room asks the user to know anything they should not have to know.
In a poorly governed estate, that burden does not transfer to the design team, who have moved on. It does not transfer to the integrator, who has handed over. It accumulates. As support tickets. As floor walk requests. As training sessions that have to be repeated every time staff turn over. As calls to the helpdesk from someone who cannot work out why the join button is not appearing for this particular meeting, or why the content sharing is not working from this room, or why the interface looks different to the one they used last week.
These are not questions that should reach the user. Each one is a design failure that was not resolved before the room opened. And they do not resolve themselves.
This is why platform choice, at the level of the operational archetype, is not a purely technical decision. A room that requires the user to understand the nuance of which join method works for which meeting type, or why interop behaves differently depending on the platform on the other end of the call, is a room that has not absorbed its complexity at the right level. The standard and the archetype exist precisely to absorb that complexity before it reaches the person in the room. When they do not, the support team absorbs it instead. And the support team, in most organisations, is neither staffed nor equipped for it.
The Support Model Has to Be Designed, Not Inherited
Most AV support models are not designed. They are inherited. The integrator knows the estate, so the integrator becomes the support function by default. IT absorbs the service desk tickets because they have a service desk. Facilities handle the physical issues because they handle the building. And somewhere in the gaps between those three, most problems live.
A designed support model starts with a simple question: what does a healthy room look like, and who is responsible for knowing when it is not?
That question requires answers at several levels. What does tier one support look like, what can they resolve remotely, and what is the escalation path when they cannot? What remote management tooling is in place, what does it surface, and who is monitoring it? What constitutes an alert condition and who responds to it? What is the SLA for a standards-based room, and is it different for a complex space?
The answers to those questions do not come from the integrator’s handover pack. They come from a deliberate design process that treats support as a first-class deliverable alongside the rooms themselves. The management plane, the monitoring configuration, the alerting thresholds, the escalation paths are not afterthoughts. They are part of the standard. They belong in the design conversation before a cable is pulled.
Managed Service Versus In-House
The build versus buy decision for AV support rarely gets made consciously. It happens by default, usually after the first significant failure, when the organisation realises that nobody on the payroll knows how the complex spaces work.
The options are real and each has a cost profile. An in-house AV support function gives you capability, institutional knowledge, and direct accountability. It also requires headcount, training, tooling, and a career path that most organisations are not willing to invest in for what they still classify as a building system. An outsourced managed service gives you specialist capability and defined SLAs. It also requires a contract that was written before the estate was built, which means the scope is often wrong by the time the first ticket is raised. A hybrid model, with IT holding tier one and a managed service partner holding tier two and above, can work well when the boundary between them is clearly defined. It fails when it is not.
The point is not which model is right. The point is that the decision has to be made consciously, at design time, not inherited from whoever happens to be standing closest when something breaks. The support model is as much a deliverable of the standard as the room design. It belongs in the same conversation.
Concierge Support for the Complex Space
The ten complex spaces in a hundred room estate carry a disproportionate support burden. They are harder to diagnose remotely. They have more failure modes. They require specialist knowledge to resolve. And they are, almost by definition, the spaces being used for the highest-stakes meetings in the building.
For a standards-based room, a reactive support model is sufficient. Something breaks, a ticket is raised, the room is resolved. The impact is contained and the risk is proportionate.
For a complex space hosting a high-stakes event, a reactive model is not sufficient. By the time the ticket is raised, the damage is done.
Consider the scenario. A flagship event. Two hundred people in the room. Partners, clients, senior leadership. The agenda is full. The speakers are prepared. The room has been booked for months. The AV fails at the start. Not catastrophically, just the kind of fault that a pre-event check would have caught and resolved in the thirty minutes before anyone arrived. Instead it surfaces when the room is full and the clock is running.
The cost is straightforward to calculate, even without specific figures. Take the number of people in the room. Multiply by your organisation’s fully loaded hourly cost. Multiply by the time lost. Add the catering that ran regardless. Add the reputational cost if the event was client-facing or involved external guests. The deferred agenda does not get recovered. It gets compressed or cut. Whatever that number is in your organisation, compare it to the cost of a concierge engineer for a half day pre-event check. The justification does not need a spreadsheet. It needs an honest conversation about what the event is worth and what it costs when it goes wrong.
A concierge model for complex spaces is not a luxury. It is the logical operational consequence of having consciously designed those spaces, documented their complexity, and priced them honestly. You knew at design time that these rooms were different. The support model should reflect that.
The Handover Problem
Every project has a handover. The integrator completes the build, produces the documentation, delivers the training, and moves on. The client takes ownership of an estate they did not design, running technology they do not fully understand, supported by documentation that captures what was built but rarely captures why.
The knowledge that sits in the integrator’s lead engineer’s head, the room that needed an extra access point, the DSP configuration that was tuned on site, the quirk in the control logic that was resolved three days before practical completion, does not transfer in a handover pack. It walks out the door.
This is not a criticism of integrators. It is a structural problem. Handover is a point in time. Knowledge retention is an ongoing operational requirement. The organisation that treats handover as the end of the knowledge transfer has already lost most of it.
The answer is not a better handover pack. It is a support model that does not depend on one person knowing everything. Documented configurations. Standardised commissioning. Remote management tooling that surfaces the state of the room without requiring institutional memory to interpret it. For complex spaces, a consistent user control interface across the estate means the support team understands the control logic of every room without having to relearn it each time. The archetype does the heavy lifting across the standards-based estate. Ninety consistent rooms means the support team learns one thing deeply rather than a hundred things shallowly. The user learns one interface. The floor walk covers one workflow. The training programme runs once and stays relevant.
And this scales globally. The user who walks into a room in Paris, Berlin, New York, or London sees the same interface, follows the same workflow, and has the same experience. It is not just consistency. It is familiarity. It becomes the way the organisation does things, embedded in the culture rather than written in a manual that nobody reads.
SLAs and the Reality of Response Times
Response time is where the cost of the complex space becomes visible in operational terms.
A standards-based room with remote management in place can often be diagnosed and resolved without a site visit. A firmware issue, a configuration drift, a network connectivity problem are resolvable remotely if the management plane is properly configured and the support team has been trained on it. The SLA for that room can be measured in hours.
A complex space with a non-proprietary DSP, a custom amplifier chain, and a control processor running bespoke logic cannot be diagnosed remotely with confidence. It requires someone who knows that specific room, that specific configuration, and that specific failure mode. That person may not be on the service desk. They may not be in the same city. The SLA for that room is measured in days, and the cost of each day is proportionate to how important that room is.
This is not an argument against complex spaces. Some rooms genuinely need what it takes to build one. It is an argument for pricing them honestly, not just the build cost, but the support cost over the lifetime of the fit-out. A room that costs significantly more to build and an order of magnitude more to support is a different investment decision than the build cost alone suggests.
Somebody Has to Own It
This series began with a room that did not work and nobody who owned the problem.
Post 1 named the gap. Post 2 described why the complexity is real. Post 3 built the standard. Post 4 defined the archetype. This post is about what happens when the standard and the archetype are in place and the estate is live. Who monitors it. Who responds when something fails. Who holds the knowledge when the integrator has moved on. Who makes the conscious decision about managed service, about concierge support, about SLAs that reflect the actual cost of failure rather than the cost of the contract.
The answer to all of those questions is the same answer as Post 1. Someone has to own it.
Not facilities managing it as a building system. Not the integrator on a break-fix SLA. A named function within IT, with defined accountability for how the estate is specified, built, and governed. Not budget ownership, that sits elsewhere. Architectural authority. The standing to make design decisions and be in the room when they are made.
The technology is not the hard part. The technology works when it is specified correctly, built to a standard, and supported by people who know what they are looking at. The hard part is the governance. It always was.
And the reason it remains unsolved in most organisations is not that nobody cares. It is that the architectural discipline that would close the gap is unnamed, ungoverned, and unrecognised. The work gets done, in spite of the gap rather than because it has been closed. Everyone knows something is missing. Nobody can agree on what to call it or where it sits.
The domain is Workspace Architecture. It exists. It just does not have a seat at the table yet.
Next: Unclaimed Baggage.
RA. Blog: Technical Thoughts from the AV/UC World 
Leave a comment