RA. Blog: Technical Thoughts from the AV/UC World

AV & IT in the Enterprise – Post 3 of 6

A standard sounds like a constraint. A fixed point. A decision already made on your behalf before you walked into the room.

That is not what a standard is for.

A standard, properly built, is a framework that absorbs the complexity of the environment without losing the consistency of the outcome. It doesn’t tell you what to build. It tells you what the user should experience regardless of what you built. And in a world where no two rooms, no two clients, and no two organisations are the same, that distinction is everything.

This post is about what a standard actually needs to accommodate and why the most important thing it can do is tell you when not to build at all.

The Client Shapes the Standard

The first thing a standard has to acknowledge is that you do not always control the platform.

In professional services, particularly legal, the meeting doesn’t happen on the platform you designed for. It happens on the platform the other party mandates. German courts have historically required SIP connectivity. Not Teams. Not Zoom. SIP, with a dial string, because that is how the court operates and the court is not changing its infrastructure to accommodate your preferred stack.

A law firm with a global footprint has to be able to join a Munich court via SIP on Tuesday, a San Francisco technology client via Google Meet on Wednesday, and an internal board meeting via Teams on Thursday. Ideally from the same room. The standard has to make all of that possible, not by supporting everything equally, but by defining a clear platform hierarchy with documented interop paths for the clients that sit outside it.

The Silicon Valley technology client is a useful example in its own right. Google Meet is native to that environment. Startups especially treat it as the default and everything else as friction. If your standard doesn’t account for that profile, if Direct Guest Join from Meet isn’t a tested and documented capability in your certified room estate, you have designed for the organisation and ignored the client they are meeting. That is a user experience failure dressed up as a platform decision.

Zoom. WebEx. Teams. Meet. SIP. The list of platforms a modern enterprise room estate has to support, depending on the sector and the client base, is longer than most people want to admit. The standard doesn’t pretend otherwise. It maps the landscape honestly and builds the interop layer accordingly.

Physical, Logical, Security

Behind every platform decision is a set of standards operating at three distinct layers. Each one shapes the user experience in ways the user will never directly observe, until something goes wrong.

Physical

Display sizing is calculated against the furthest viewer. Camera selection follows room geometry, a fixed wide-angle for huddle spaces, a PTZ with auto-framing for larger rooms where occupancy shifts. Microphone coverage is mapped to the table configuration, with full capture across the occupancy range as the brief. Mounting heights are defined and held: a display too high forces unnatural head position across a long call, a camera above eye line changes the perceived dynamic for remote participants. Integration with the building fabric, fire alarm relay contacts, lighting control, BMS occupancy triggers, belongs here too. The physical standard is complete when the room performs at full occupancy, not just under ideal conditions.

Logical

It begins with how the room account is created: naming convention, licensing model, mailbox configuration. Platform hierarchy is defined here; Primary platform, Direct Guest Join support, and the rules for meetings that fall outside both. Interop paths are documented against specific client profiles: SIP dial strings for court or legacy connectivity, gateway and PEXIP routing where needed. Network configuration follows: dedicated VLAN, QoS policy to protect call traffic under load, DNS and NTP confirmed before certification. Remote management tooling is configured and tested at commissioning, not added afterwards.

Security

Physical security starts in the rack: cabinet doors locked, unused I/O ports shrouded, control panels presenting only what the user needs. Shared credentials are stored in a password vault, rotated on schedule, and never held only in the memory of the commissioning engineer. Remote access for external partners is time-limited, logged, and scoped to minimum necessity. Firewall rules for AV endpoints are explicit. Room accounts sit within the organisation’s identity architecture, conditional access, MFA where supported, and a defined deprovisioning process. Monitoring defines what a healthy room looks like, what triggers an alert, and who responds.

None of this is validated by configuration alone. Penetration testing during the pilot phase is the mechanism by which the gap between what the standard specifies and what was actually deployed gets found before it becomes an incident. Findings feed back into the standard, not just as remediation for the rooms tested, but as specification changes that close the gap across the estate before it is built. Pen testing after deployment is expensive and disruptive. Pen testing during pilot is design.

Cost, Function, and the Honest Conversation

In the public sector, platform decisions are often already in place when a project begins. Procurement frameworks, enterprise licensing agreements, and existing infrastructure commitments shape the environment before the design conversation starts. The constraint shifts.

The question in that environment is not which platform. It is how much room, at what cost, for what functional outcome.

The temptation when a budget is constrained is to treat cost reduction as feature removal. Take out the intelligent camera. Simplify the control interface. Drop the room booking panel. The result is a cheaper room that is also a worse room and the users, who had no input into the cost decision, experience only the latter.

A standards framework at a lower cost point should still deliver a consistent user experience. What changes is the capability envelope, not the quality of the outcome within it. A small satellite office doesn’t need intelligent speaker tracking. It needs a camera that covers the table, a microphone that captures the room, and a control interface that anyone can operate without training. Designed deliberately to that profile, it is not a compromised room. It is the right room for that location.

The standard defines what each location needs to be. And then it holds that definition.

When the Standard Says No

The divisible space is a common brief. A wall that folds away, turning one meeting room into two, or two into one. Flexibility for an organisation that doesn’t always know how it will use the space until it needs to.

In the right location, with the right support model, a divisible space with full AV in both configurations is a legitimate solution. The switching logic, the combining amplifier, the dual control surfaces, the complexity is real but it is manageable if the people responsible for managing it are present, capable, and resourced.

In a remote satellite office, with no on-site support, the nearest qualified engineer a flight away, and a user base of thirty people who want to join a Teams call, that same solution is not a feature. It is a liability. When it fails – and it will fail – nobody on site can fix it. Nobody remote can diagnose it quickly. And the organisation has paid a significant premium for a room that is now a source of frustration rather than productivity.

Adding a second system does not solve this. It compounds it. Two codec systems. Two control interfaces. Double the firmware. Double the failure modes. Double the support overhead for a location that cannot absorb it.

The standard has to ask a harder question before the design starts.

Does the divisible space belong in this location at all?

Not whether it can be engineered. It can always be engineered. Whether the support model of this location can sustain it. Whether the user density justifies the cost. Whether the brief is actually right.

A standard that never challenges the brief is a production document. A standard that asks whether the brief is right is a design tool.

That question, asked early, answered honestly is one of the most valuable things a Workplace Architect can do for a project. It is also the one most likely to cause an uncomfortable conversation with the person who specified the divisible wall.

Have it anyway.

The Standard Is Not Finished

The platforms this standard is built around are not standing still. Microsoft, Zoom, Google and Cisco are shipping capability updates on cycles that bear no relationship to a construction programme. A device certified for Teams Rooms in Q1 may have new firmware, new features, and a revised roadmap by Q3. Hardware specified at test fit stage, sometimes twelve to eighteen months before installation, can arrive at practical completion already approaching end of support.

This is not an edge case. It is the operating condition.

The standard has to be maintained as a live document, not archived after sign-off. That means a defined owner, a review cadence, and an active horizon-scanning function that tracks platform release notes, OEM roadmaps, and end-of-life announcements. When a certified device is discontinued, the standard is updated before that device is specified into the next project, not after the purchase order is raised.

It also means being willing to take advantage of what improves. AI-driven noise suppression, intelligent framing, and in-room occupancy analytics have moved from premium differentiators to standard inclusions on mid-range hardware in the space of two years. A standard written before those capabilities existed will underspecify what is now achievable at the same cost point. Horizon scanning is not just about managing obsolescence. It is about knowing when the floor has risen and updating the standard to stand on it.

The standard is a point-in-time expression of best practice. Treated as permanent, it becomes a constraint. Maintained actively, it remains what it was designed to be.

The User Never Sees the Standard

A well-applied standard is invisible.

The user in Munich doesn’t know that the SIP dial string resolved correctly because someone wrote a gateway policy three months before the room opened. The user joining from Google Meet doesn’t know that Direct Guest Join was tested against four platform combinations before the room was certified. The user in the satellite office doesn’t know that the simple room they’re sitting in was deliberately specified that way, because the alternative would have been a complex room nobody could support.

They just know the call worked.

That is the point of the standard. Not to make the architect’s life easier, though it does. Not to make the design process faster, though it does that too. To make the outcome consistent enough that the technology disappears and the meeting happens.

The standard doesn’t constrain what you build.

It defines what the user should never have to think about.

Next: Not Every Room is Special.