The executive said it was unusable. Every device was green.
The dashboard said green. CrossRoom scores what the people in the room heard, thirty seconds at a time, and then names one layer and one device.
After the call that went wrong
It runs against the call you name, on hardware you already own.
Device telemetry, switch counters and call statistics, over read-only access.
No audio, video or shared content is captured. It reads statistics about the call.
If part of the chain went unmeasured, the verdict cannot score above 74. A half-seen room reads as half-seen.
Every light in the room stayed green for the worst call of the week.
The control system reported the room as operational. The network graphs were flat. The codec logged no errors. And the person in the chair says they could not hear anyone for ten minutes.
Averages hide it. A call that is fine for fifty-five minutes and unusable for five averages to fine, and the five minutes are the entire complaint.
The complaint is about five bad minutes, so it scores thirty seconds at a time.
Thirty seconds at a time, with the bad ones named.

It scores the experience, then works backwards to the cause.
Thirty-second slices. A good hour can no longer bury five bad minutes.
On what the room would have heard, using statistics the room and the network already keep.
One layer and one device, with the evidence that points there and the confidence attached.
A half-seen room scores 74 at most.
If a layer went unmeasured, the verdict says which one, and the fault is not pinned on whatever it could see. Here is how to raise the ceiling.
- 1Find out which layer went unmeasured
The verdict names it. Usually it is one device that does not export statistics, or one switch nobody has read-only access to.
- 2Then instrument that one thing
One device is normally the difference between a capped verdict and a real one. The report tells you which.
- 3Then run it on the good calls too
A baseline of what normal looks like in this room is what turns the next bad call into a five-minute answer.
Does it record our meetings?
Does it record our meetings?
No. There is no audio or video capture anywhere in it. It works from statistics the room and the network already produce.
Does it work for calls that already happened?
Yes, as long as the statistics for that window are still retained. That is the usual case, and the report tells you when a window has aged out.
Which platform does it support?
What matters is the equipment and the switches. It reads the room and the network, so the platform that hosted the call matters much less.
Will it blame the network every time?
No. The cap exists for exactly this. A layer it cannot see is named as unmeasured, and the fault does not default to the layer it could see.
See it work
The meeting the CFO complained about.
The CrossRoom console on its sample estate: 21 reconstructed meetings across 13 rooms. Open the Q3 Forecast Review in Denver Room 4B, where every device stayed up and the audio still fell apart for four and a half minutes.
Start here. You will open one bad meeting, scrub to the moment it broke, and read who is at fault and why. It takes about a minute.
One bad meeting, traced to one access point.
Every device in Room 4B stayed up. CrossRoom still found the Wi-Fi, named AP-3F-North, cleared the platform, the camera, the mic and the DSP by name, and said which one device it could not check.
Sample data from CrossRoom's own sample estate. CrossRoom reads call statistics and device state. It never records audio, video or shared content.
Stopping the next bad call
When the device it names needs a firmware change, CrossCheck rehearses that change before it goes in.
CrossRoom next to the other sevenCrossRoom hands you the one device that spoiled the call, which is where CrossCheck picks up: “Will this change break the room?”
Bring one call that went wrong.
Bring the call people complained about, with its date and its room. If the statistics for that window are still retained, you leave knowing which layer and which device to look at.
