Walk into any facility management operation — a property owner running a mixed portfolio, a service company managing office buildings across three cities, an FM team responsible for a hospital campus — and ask to see the ticket queue. The number on screen will tell you something immediately. Not the number itself, but the fact that you cannot see it. It stops counting at 99+. More open alarms, error reports, and work orders than the system bothers to display.
The problem runs deeper than staffing. The structure itself is broken. And it has been getting worse, not better, for years.
How we got here
The last decade of building technology was built around a single ambition: more insight. More sensors. More integrations. More data points feeding more dashboards. And by that measure, it worked. Today you can detect a water leak in a single toilet block before it causes damage. You can monitor the performance of thousands of assets across a portfolio from a single screen. The buildings have never been more legible.
What has not kept pace is the capacity to act on what you see.
Every new sensor generates potential alarms. Every new integration adds another source of error reports and work orders. Industry data puts the average at 12.5 alarms per day for a typical facility manager, with more than 50% receiving up to 30 daily. And only one in three reacts to them — because, as Facility Executive reports, building managers begin to ignore alerts, assuming they are false alarms or not urgent. Two-thirds receive alerts from their BMS. One-third acts on them.
The insight layer scaled. The operational response layer did not.
Generative AI made this worse in a specific, ironic way. It arrived as a promising tool and was applied to the right place — explaining alarms. Where before you received a raw sensor alert with a code and a timestamp, you now receive a readable description. That is a genuine improvement.
But it solved the wrong half of the problem.
Understanding an alarm and handling an alarm are two entirely different things. Your team now comprehends the noise better. The queue is still 99+. Someone still has to open each ticket, assess it, route it, prioritize it, escalate it, close it, or find the person who should. The cognitive overhead came down slightly. The operational overhead did not.
The hidden cost underneath the number
There is a secondary consequence that rarely shows up in reporting. When a queue is perpetually at 99+, your team stops trusting it as a reliable signal of actual building health. You develop an intuitive sense of whether things are broadly fine or broadly not — because the data no longer gives you a clean read.
This is expensive in ways that compound. Important tickets sit alongside noise. Urgent issues share a queue with duplicate alarms and false positives. The team learns to triage the triage. Missed issues become incidents. Incidents become tenant complaints. Tenant complaints become service credits or contract risk.
According to ProptechOS’s own process mapping of 289 FM workflows, 80 to 95% of BMS alarms are non-actionable — nuisance alarms, chattering sensors, and cascading alerts from a single root cause. Today, human operators wade through this noise manually. The gap between what is technically possible and what is actually practiced represents enormous operational waste.
What changes the queue
The shift that moves the number comes from agents that act, not better explanations.
A triage agent connects to all incoming service objects — alarms, error reports, and work orders — and processes them autonomously. It corrects misclassifications, fixes wrong priority assignments, and identifies tickets routed to the wrong team. For simple incoming requests — a tenant reporting a light is out in a space that already has an open work order, for example — it auto-replies and updates the status without any human involvement. For tickets that do require human attention, it ensures they arrive correctly classified, correctly prioritized, and routed to the right person before anyone has touched them.
This single agent, handling one subtask within the broader FM process, is typically the highest-impact starting point available to any FM team. It does not require redesigning how your organization works. It plugs into the existing flow.
A context enrichment agent runs in parallel. Before any operator opens a ticket, this agent has already done the homework: it has pulled historical telemetry for the relevant asset, retrieved previous service records, past incidents, and related metadata from across the building. When your technician sits down to assess the ticket, they are not starting from scratch and logging into three separate systems. They arrive with full context and can move immediately to judgment and action. The ProptechOS Agent Creator Guide describes this as the difference between an agent that alerts and an agent that acts — and the enrichment phase is where most of the time savings surface first.
An alarm consolidator addresses the noise at source. It scans incoming BMS and SCADA alarms for duplicates, related events, and false positives — then merges and reclassifies them before they reach the queue. Fifty alarms triggered by a single fault event become one consolidated signal with a clear description of the underlying issue. The 99+ counter starts to move.
Together, these three agents do not replace your FM team. They remove the work your team should never have been doing in the first place.
Where to begin
You do not need to automate an entire process end to end to get there. The most effective approach is to start with one high-volume, low-judgment subtask — the work that is currently consuming hours without requiring the skills your team was hired for.
Run the triage agent in review mode for the first two weeks. It proposes actions but does not carry them out. Your team reviews the proposals each day. Once the reasoning is trusted, extend its permissions to act autonomously within defined boundaries. In ProptechOS, the transition from pilot to production is typically measured in days, not months. All agent prompts are open source and available in the ProptechOS Agency library, so you can review and adapt them before any deployment decision.
The 99+ problem is a product of a toolset built to generate insight without the operational layer to act on it. Inevitably it is not. The teams building that operational layer today will have a fundamentally different operation in twelve months than the teams waiting to see how the technology matures.
