The technology worked exactly as designed. The employees still couldn’t start the meeting.
The executive walked into the conference room early for the call.
This was not an internal meeting. It was the final conversation before a client decided whether to renew.
The room had everything.
Two displays. Multiple cameras. Ceiling microphones. Wireless presentation. A scheduling panel outside the door. Motorized shades. Preset lighting scenes. A centralized control system tying it all together.
The meeting was on the calendar. The room had been reserved.
But nobody could figure out how to start it.
One person pressed “Start Meeting.” Someone else connected a laptop. Another began searching for the correct input.
– Are we joining from the room or the laptop?
– Which camera is active?
– Why can’t the client see the presentation?
– Is the microphone muted?
It became conference room bingo. Press a button. Change an input. Disconnect a cable. Try something else and see what happens.
The scheduled start time passed, and eventually someone called IT. The client remained connected while four employees stood around the table debating which cable to pull.
Nine minutes after the scheduled start, the meeting began.
Nobody could say whether the delay affected the client’s decision. What everyone understood was that the client’s first experience of the meeting was nine minutes of visible internal confusion.
Nothing was necessarily broken. Every component may have been operating exactly as designed.
That was the problem.
Technically Integrated. Operationally Complicated.
Modern conference rooms can recognize scheduled meetings, frame whoever is speaking, display remote participants, share content wirelessly, adjust the lighting, lower the shades, and connect several locations.
Each capability may be useful. Every device may have been properly specified, installed, and tested.
The person sitting at the table, however, does not experience those components individually. They experience the room—and whether it makes the meeting easy to start.
The cameras, displays, microphones, controls, lighting, and conferencing platforms may all communicate properly while the presenter is still faced with too many choices:
- Select a meeting source.
- Choose a presentation input.
- Confirm the display destination.
- Pick a camera.
- Decide whether to join through the room or a laptop.
The technology may be integrated behind the wall, but the person at the table is still being asked to make decisions the system should already understand.
“We Just Want It to Work”
The complaint I hear most often at the beginning of a conference-room project is remarkably simple:
“We just want the technology to work the way it’s supposed to.”
That request usually comes from experience. Meetings have started late. Presentations have appeared on the wrong screen—or not at all. Remote participants could not hear the room. People have learned which conference rooms to avoid and which colleague to bring because they know how to make the system work.
Those frustrations become the starting point for the new design. But “work the way it’s supposed to” does not tell the design team what someone should see, press, or expect when they walk into the room.
Without that definition, a project can replace every piece of technology and recreate the same frustration.
The Room Was Designed Around Everything It Could Do
Conference rooms become complicated one reasonable decision at a time.
The technology team wants reliable connectivity. The AV consultant wants flexibility. The architect wants the controls incorporated into the room. The business wants different conferencing platforms, outside presenters, hybrid meetings, training sessions, town halls, and future technology accommodated.
Taken together, those requests can produce a room designed around everything it might someday do instead of what most people need it to do every day.
Someone presenting a slide deck should not have to know whether the content is being routed through a room computer, wireless gateway, tabletop connection, or conferencing platform. They should be able to share the presentation without understanding the system behind it.
Advanced capabilities can remain available. They just should not stand between the presenter and the basic functions of the room.
When Every Room Works Differently
The problem becomes more pronounced across a portfolio.
One room starts from the scheduling panel. Another requires a touchscreen. A third expects someone to connect a laptop.
Press “Share” in one room and the presentation appears. Press it in another and a menu asks where the content should go. Even the language changes: “Share” in one room, “Present” in another, and an input number in a third.
Each room may function, but people cannot carry what they learned in one room into the next.
Eventually, they stop trusting the technology. They avoid conference rooms they have not personally tested, especially when the meeting matters. The most capable rooms in the building can become the ones people quietly route around.
When someone reports that a room is not working, the equipment may be fine. The room simply did not behave the way they expected.
Training Cannot Fix Every Design Problem
The usual response is more training. Instructions are placed on the table, tutorials are posted, and someone from the technology team demonstrates the controls.
That may help frequent users. It does much less for someone who enters that particular room once every few months.
In many workplaces, the occasional user is typical. It may also be the person asked to start an important meeting in the largest, best-equipped room in the building—the room they are least likely to use regularly.
If starting a standard meeting depends on remembering instructions unique to that room, the experience has not been simplified. The complexity has been transferred to the person trying to use it.
Specify What People Should Have to Do
Most conference-room projects specify what the room must contain. Far fewer specify what someone should have to do once they enter it.
Owners spend considerable effort defining the displays, cameras, microphones, speakers, network capacity, control systems, conferencing platforms, lighting, shades, and acoustics.
They should give the same attention to a more basic question:
What should someone have to do to start a meeting?
For most meetings, the essential actions are limited:
- Join the meeting.
- Share content.
- Adjust the volume.
- End the meeting.
Those actions should look and behave consistently from room to room. Decisions the technology can make should remain behind the interface, while advanced functions remain available when they are actually needed.
The goal is not to remove capability. It is to keep ordinary meetings from requiring unnecessary choices.
Test the Meeting, Not Just the Equipment
Testing can confirm that the cameras, microphones, displays, lighting, controls, and network connections perform as specified. That proves the individual systems are ready for turnover.
Before accepting the room, ask someone who did not participate in the design to complete a few ordinary tasks:
- Start a scheduled meeting.
- Share a presentation.
- Bring in a remote participant.
- End the call.
Provide no instructions and watch what happens.
Notice where the person hesitates, which words are unclear, and what produces an unexpected result. The moment they start guessing is where the design still needs work.
Commissioning can prove that every component works. Only a person using the room can prove that the meeting works.
A successful conference room is defined less by how many features it contains than by how little complexity the person at the table has to manage.
Could someone unfamiliar with your conference rooms walk in and start an important meeting—or would they have to press buttons and hope something worked?
Related: The Building Was Designed. The Technology Infrastructure Wasn’t.
About the Author: Richard Neuman advises organizations on capital planning, project governance, and complex capital programs. He has overseen more than $2 billion in capital investments across commercial real estate, healthcare, utilities, industrial, broadcast, and development projects.
He writes candidly from an owner-side perspective about the executive decisions and organizational dynamics that shape capital project outcomes.
Leading a major capital program or facing a complex capital decision?
Contact Richard.
Subscribe for insights on capital planning, project governance, and the executive decisions that shape project outcomes long before construction begins.
