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

AV & IT in the Enterprise – Post 4 of 6

Before this post does anything else, it needs to make a distinction that the industry consistently fails to make.

A requirement is what the business needs the room to do. A standard is what a good outcome looks like and the rules that govern how you get there. An archetype is how you build to that standard, repeatedly, across a diverse estate, without turning every room into a design exercise.

They are not the same thing. They are not interchangeable. And confusing them is where room estates quietly fall apart.

An organisation with a standard but no archetypes re-solves the same problems on every project. Every room is a fresh conversation about cameras and codecs and control surfaces, even when the answer was the same last time. An organisation with archetypes but no standard ends up with rooms that look consistent but perform differently, the same kit in rooms where it was never the right answer. An organisation that forgets the requirement exists ends up with beautifully compliant rooms that nobody wanted.

All three have to exist. All three have to be distinct. This post is about the archetype, what it is, where it comes from, when it bends, and when it breaks.

The 90/10 Rule

For every 100 rooms you deploy, 90 should be archetype-based. The answer already exists. The kit is defined, the outcome is known, and the project is a deployment exercise not a design exercise.

Ten will be complex spaces. They earn that status through documented need, not through drift, scope creep, or a stakeholder who saw something at a trade show. The 90 take care of themselves. The 10 are where the real decisions live.

Before Huddle Rooms Existed

The archetype as a concept predates the product category it eventually helped create.

In a large law firm, practice groups are the operational heartbeat of the organisation. Lawyers working together on a matter need to meet regularly, quickly, and often without notice. In buildings where large meeting rooms were shared, competed for, and frequently unavailable, practice teams were losing time and productivity to a space problem that nobody had framed as a technology problem.

The solution was a defined room type built around the partner office. Not a full meeting room. Not a shared bookable space. A small, always-available environment where a practice team could convene on demand, either through BYOD or through a compact appliance bringing Teams or Zoom directly into the room as a managed endpoint.

The effect was twofold. Practice teams got a space that worked for them. The shared meeting room estate got relief from a category of meeting it was never designed to absorb.

The OEMs eventually arrived at the same conclusion and built a product category around it. The huddle room is now a standard archetype in every estate. But the problem it solved, and the operational logic behind solving it at the room type level rather than the scheduling level, came first.

That is what an archetype does. It takes an operational problem, defines a solution at the right level of abstraction, and makes it repeatable.

Defining the Archetype

An archetype is a defined room type with a defined hardware kit. Not a suggestion. Not a starting point for a conversation. An answer.

But before the hardware is defined, the archetype has to be anchored in requirements. Every organisation has a baseline – a minimum viable room. The things every meeting space in the estate must be able to do, regardless of size, location, or budget tier. Join a call. Be seen. Be heard. Be managed. That baseline is not the archetype. It is the floor the archetype has to clear.

The archetype says: this room type gets this proprietary ecosystem. Selected because it meets the outcome mandates in the standard and clears the organisation’s core requirements. Tested in a pilot. Certified before it goes anywhere near a live deployment. And from that point forward, it is the answer to the question before the question is asked.

That kit does not have to be rigid about platform. A single hardware solution that natively supports Teams, Zoom, and Google Meet as a localised choice still constitutes one archetype, because the hardware, the management plane, and the support model are identical across all three. The platform choice is made at the point of deployment, set through the device’s management platform, and held for the life of that room’s configuration. It is not a per-meeting toggle. The decision is made once, deliberately, as part of the archetype definition. The archetype holds.

In practice, most estates are served by three archetypes. The complexity compounds as the spaces increase in size, and so do the options available within each one.

The small room is a video bar, a screen, and a touch panel. Options within the archetype include a microphone extender where the acoustic environment demands it, a room booking panel at the door, a BYOD kit for guests, and platform choice at the point of deployment.

The medium room steps up to a larger video bar with a wider field of view, the same touch panel, a larger screen. Options extend to dual screens, a content camera for document sharing, microphone extenders, a booking panel, BYOD, and platform choice.

The large room is where the archetype begins to do more work. The video bar may become a PTZ camera array depending on the room geometry. Screens may become an LED wall. Repeater displays serve the far end of a long table. A content camera and a presenter camera are both on the options list. Wireless presentation becomes relevant. Microphone extenders are more likely than optional. And platform choice at this level may mean a codec swap rather than a software setting, because the room’s requirements have outgrown what a bar-form-factor device can natively deliver.

The options listed within each archetype are not exceptions. They are the archetype’s response to the environment. A small room with a microphone extender is still a small room archetype. A large room with an LED wall and a presenter camera is still a large room archetype. The kit extends. The archetype holds.

Physical and Operational Archetypes

It is also worth noting that an organisation may operate more than one set of archetypes, not defined by room size but by operational context.

Through the lens of a law firm this becomes immediately clear. Business services and internal practice floors have straightforward requirements. Rooms are used to meet on the organisation’s default platform, Teams in most cases. Interoperability needs are minimal or non-existent. The archetype serves those spaces cleanly and without complication.

Client-facing floors are a different discipline entirely. These spaces are often more considered in their aesthetic, and their technology has to match. Meetings in these rooms need to interoperate with whatever platform the client is using that day. This is where you see mandates for native rooms: a Teams room, a Zoom room, a Google Meet room, each running the platform natively rather than relying on interop. The hardware may be identical. The standard may be the same. But the operational archetype is different, because the governing context is different.

Physical archetypes define what goes in the room. Operational archetypes define how the room is configured and what it needs to be capable of. Both have to be defined. And in a complex enterprise environment the two dimensions overlap. A large room on a client floor is both a large room archetype and a client-facing operational archetype simultaneously.

The Archetype is Not a Cage

A long room may need several cameras, or cameras mounted at a height that allows them to capture participants at distance rather than shooting past empty chairs at a wall. A wide room presents a different problem – participants on opposite sides of the space need to be captured and framed without the remote end experiencing jarring motion blur as an auto-framing camera tries to keep up, or being ignored entirely by a single camera that was never designed for that geometry. A space used for presentations needs a second display so the presenter can face the room rather than the screen.

None of these break the archetype. The archetype extends to meet the environment.

The distinction that matters is whether the extension stays within the proprietary ecosystem. A second camera from the same vendor, managed through the same platform, patched through the same firmware cycle, that is an extension. The archetype holds. The room is still an archetype-based deployment. It just has more of something than the baseline kit.

The environment shapes the solution. That is not a failure of the standard. It is the standard doing its job, defining the outcome, and allowing the deployment to flex in pursuit of it.

When Does an Extension Become a Complex Space?

There is a threshold. Cross it and you are no longer extending an archetype, you are building a bespoke space that happens to share some components with the archetype kit.

The clearest signal is the introduction of a non-proprietary component.

A ceiling microphone array is excellent technology in the right environment. It is also a component that sits entirely outside the proprietary support envelope. It requires a DSP to process it. That DSP is a separate device, a separate firmware cycle, a separate failure point, and often a separate support contract. The moment it enters the design, the room can no longer be diagnosed and resolved entirely within the vendor’s own management and support tooling.

The same is true of repeater displays requiring distribution hardware, environmental controls integrating with building systems, and custom amplifier chains. Each one is a reasonable decision in the right context. Each one is also a line being crossed.

The test is simple: can this room be fully diagnosed and resolved within the vendor’s native management platform? If yes, it is an archetype-based room, possibly extended. If no, it is a complex space – and should be governed as one from the moment that decision is made, not after the first support call that nobody can answer.

The Complex Space – Conscious. Documented. Expensive.

The complex space is not a mistake. Some rooms genuinely need what it takes to build one. A flagship boardroom. A divisible conference suite. An executive briefing centre. An arbitration room in a global law firm where the technology is part of the service the firm is selling.

But the complex space comes with a contract. It has to be conscious, someone with authority made the decision and understood what they were accepting. It has to be documented, the design rationale, the exception from the standard archetype, the support model, all written down before the first cable is pulled. And it has to be priced honestly. Not just the build cost. The support cost, the maintenance overhead, the extended response SLA, the specialist knowledge required to keep it running.

The complex space that nobody acknowledged as complex is not a premium room. It is a liability waiting to surface at the worst possible moment.

Your estate has ten of them per hundred rooms. Probably. Make sure you know which ten they are.

Next: Who owns it when it breaks.