Every room. One console.
RoomOps watches your conference rooms across Logitech Sync and Zoom, finds what is broken, proves why, and hands the ticket to the right person with the evidence attached.
This is a real fleet on a bad day. We did not tidy it up for the photograph.
Most of its rooms are offline, whole sites are dark, and not one of those tickets has been triaged yet — every tier queue reads zero. That is the state a console gets pointed at — nobody buys one on a morning when everything works.
Every screen on this page is that same fleet, and what they show is the work: one named fault on one named unit, a cause with the evidence behind it, and a queue nobody has picked over first. A console that only reads well when the rooms are already fine is no use on the morning they are not.
Room names, sites, people and device identifiers are replaced throughout. The counts are the fleet's own.
Three consoles.No answer.
Sync knows the hardware. Zoom knows the meetings. The switch knows the port. Nobody knows whether the room at the end of the hall will work at nine.
So a support team opens every console, compares what each one says, and guesses. A room that shows offline might be unplugged, might be on a dead switch, or might be one of forty rooms on a firmware build that broke on Tuesday. RoomOps reads the sources for you and answers the question that matters: is this room broken, or is something around it broken?
Sweep. Detect.Prove. Hand off.
Four steps on every sweep: read every source, check each room against the devices it should have, find the pattern across rooms, then hand the ticket to the tier that can fix it. The third step is the one nobody has time to do by hand.
Diagram. Nine rooms are read on one sweep and six of them are faulting. The unit that raised each alert is traced to the two things those units have in common. All six are the same model on the same CollabOS build, a rate above the one the rest of the fleet runs at, so the configuration group is named as the cause. Only two of the six sit on the same VLAN behind the same switch, which is no worse than any other subnet, so the network group is ruled out.
A group becomes the answer when it is clearly above the rate the fleet already runs at, or when it carries an outright majority of the fault. Both tests are needed. A console that only compares against a baseline goes quiet on the morning the whole fleet is already degraded, which is the morning you need it.
The whole fleet,on one screen.
Rooms, devices and open issues, with the rooms that need attention first.
What the room has,against what it should.
"Rally Bar: mic pod expected 2, connected 0." That is an alert an engineer can act on.
A room is only called offline when nothing in it answers. When the room is up and one unit is missing, the alert names that unit. A site where every room is down is raised as its own outage, ahead of everything else.
Recoveries close themselves, so the open count always means broken right now.
A fault that keeps coming backis not fixed.
Insights rank what is failing by model and by firmware build, so a fault the whole fleet shares stops being answered one room at a time.
A rate is not a cause on its own. It is the shortlist: the model or the build that fails more than the rest of the fleet does, and the rooms that keep reporting the same fault after somebody cleared it — which a repeat count proves and a single ticket never can.
The right tier,with the reason why.
Every ticket moves through the same phases: automatic first response, untriaged, tier 1, tier 2, tier 3, then the vendor.
Built for the peoplewho keep rooms working.
Every model you own
One row per model, built from the fleet: how many units, in which rooms, and how many of those rooms are alerting. Open a model to see every unit it counts and the builds they are running.
Templates from your own rooms
RoomOps finds what rooms of the same shape already agree on and proposes that as the standard. Drift is reported, never silently changed.
Can this network make a call
DNS, TCP, TLS and HTTP checks against Zoom, Teams, Meet, Webex and Logitech Sync, with a report you can hand to the network team.
Tests that need proof
Automated call tests pass on what the platform reports back, not on a successful request. Live monitoring starts only when someone presses the button.
Rooms mapped to networks
Sites follow your Sync groups. Subnets are discovered per site, and any MAC address format finds the device it belongs to.
AI writes the words, not the fix
Claude drafts briefings and customer replies from facts RoomOps has already worked out. The steps a customer is asked to try come from a fixed list and are never rewritten.
The toolsyou already run.
RoomOps reads and orchestrates. For anything it does not hold, it links you straight to the vendor console.
From running roomsto designing them.
Room Designer/
Measure the room and get a compatible kit: camera reach against the far seat, microphone coverage against the table, display size against the back row, laid out in 3D with a bill of materials.
Knowledge library/
Runbooks and platform guides built on checked facts with sources, linked straight from the alert they fix.
Read first.Write on purpose.
The questions a security review asks, answered, including the ones where the answer is not yet. RoomOps is in beta. You should find the gaps here rather than in a meeting.
It reads Logitech Sync and the meeting platforms on a schedule. It holds a short list of actions that change something: reboot a device, bounce a switch port, join a room to a meeting you name. Reading is the default and most of the console only reads. Anything that changes a room is named as an action that changes a room before it runs.
No. An operation that changes state does not run unless the request carries an explicit confirmation, and that is enforced on the server, not by the wording of a button. The helper that offers first-line support its next step is narrower still: it runs only actions from a fixed list, only against the room on the ticket in front of it, and it refuses the same action on the same room twice inside two minutes.
Every write. Every create, every edit, every device control, recorded with who did it. Actions run from the ticket helper are written onto that ticket's own timeline, so the record sits where the next person is already looking instead of in a log nobody opens. Moving a ticket between tiers records the reason the person typed when they moved it.
A support tier is a capability set, not a rank. What tier one may do is a list; tier three's list is a different one. A single function answers every permission question, so there is no second place for the rule to drift, and the interface is handed the same list so it hides what you could not have done anyway. A ticket cannot change tier without a written reason, and that reason is the handover the next person reads.
The limit, plainly: that check is enforced today at the point a ticket changes tier. The rest of the console still runs behind one signed-in administrator account. The capability names are already in place, so enforcing them across the remaining routes is a mechanical pass rather than a redesign, but the pass has not been made. If you are sizing RoomOps for a team with real differences in access, ask us about this one first.
There is no SSO today. A session login guards every route, and an API request without a session is refused rather than answered. SSO is planned, Okta first, and it is not built. If single sign-on has to be there on day one, RoomOps is not ready for you yet, and we would rather say that now than in procurement.
No. Neither exists, and there is no audit under way that we could point at. What we can put in front of a security review is the behaviour on this page: a session required on every route, a confirmation required on anything that changes a room, an audit record for every write, and a list of the actions the software can take at all that is short enough to read in one sitting.
RoomOps is one Python process and a SQLite database. Deploying it is a pull and a restart, so it runs where you decide to put it. There is no multi-tenant service you share with other customers: it is a single-tenant internal tool, one organisation per install.
It holds what the vendor APIs return — rooms, devices, serial numbers, MAC and IP addresses, firmware builds, alerts and tickets — plus the mail on a ticket, which leaves from your own shared support mailbox rather than from an individual. The stored copy of each sweep is kept for thirty days. The one line recording that the sweep happened is kept for good, so the history outlives the data.
As hard as a person clicking would, and no harder. Reads go through a rate limiter with a daily budget that survives a restart, and each kind of sweep has its own cooldown on top. An automatic refresh cannot spend the allowance your own team needs later in the day.
Jira exists as a field map. A ticket already produces the payload that would create the issue, and it can hold the key of the issue it mirrors, but it is a dry run until Jira credentials are set and nothing reaches Jira before then. ServiceNow is not integrated at all. If ServiceNow is where your tickets live, say so on the call rather than after it.
That RoomOps runs every day against a real fleet, the one on this page, and that it has not been installed anywhere else yet. A beta engagement means we set it up with you, we watch it with you, and what breaks comes back to us. There is no service level to point at, and we are not going to write one before it has been earned.
If your security review asks something this does not answer, send it to contact@byrdie.ai and we will answer it in writing.
Find it.Prove it.Hand it off.
Thirty minutes. Bring the rooms that keep failing and we will show you how RoomOps reads them.
Screens are from a live fleet. Room names, people, addresses and device identifiers have been replaced.