I worked on a smart hospital project recently where a single meter was flooding a BACnet MS/TP segment with broadcast traffic, sending a message every time its reading drifted by a fractional amount, a rounding error’s worth of change, thousands of times an hour. On a bandwidth-constrained, token-passing bus, that’s enough to lock the whole segment up. And it did. Entire sections of the building OT network—HVAC, metering, mechanical systems—dropped offline completely for a period of time. This meant that a chunk of a hospital’s mechanical systems had no data and no control feedback at all. Life-safety systems are isolated from that network by design, so this wasn’t a life-safety event. From my perspective, this is as close to an emergency situation as you can get without life-safety systems being impacted.
Finding the cause took real network visibility, tracing a building-wide problem back to one small, misbehaving device buried in a much larger system. But visibility only got us to the diagnosis. Somebody still had to physically track that meter down, figure out why it was behaving that way, and get it fixed before the hospital could trust that network again.
In thirteen years working the fault detection and analytics side of this industry, I’ve watched that same pattern repeat at every scale, from a single device flooding a network to a building full of dashboards nobody’s acting on. Visibility on its own isn’t the thing that changes anything. What happens after it is.
Visibility is the Foundation, not the Finish Line
Nothing above the network layer works if the network itself is a black box. You can’t trust a fault detection alert if you don’t know whether the data behind it actually made it across the wire intact. You can’t diagnose a control loop hunting between setpoints if you can’t first rule out a flaky MS/TP segment causing the same symptom. Network visibility is the thing that lets every layer above it be trusted, and for a long time, most buildings didn’t have it. That’s a real problem, and solving it is real work.
It cuts the other way too, and this part rarely gets talked about. A stale device, a router silently dropping packets, or a segment overwhelmed with retries can look, from the analytics layer, exactly like an equipment fault. A chiller running perfectly fine can get flagged as anomalous because the data describing it arrived late, incomplete, or not at all. Without OT monitoring visibility to rule that out first, a facilities team ends up dispatching a technician to troubleshoot a problem that was never in the mechanical system to begin with. That’s one of the more common, least discussed ways trust in an analytics platform erodes. The model wasn’t wrong. The network underneath it was lying to it.
But visibility answers a specific question: what’s happening. It doesn’t answer the next one, which is what we should do about it, and who’s actually going to do it. Those are different problems, and a lot of buildings quietly assume that solving the first one solves the second.
The Dashboard that Nobody Acts on
The same pattern shows up constantly, just quieter than a network going down. An air handling unit’s filter starts clogging. A dashboard, fed by good, clean, visible data, shows the pressure drop across that filter creeping upward, a fraction of an inch of water column at a time, one more trend line ticking slowly among a hundred others. Technically, the information is all there. Practically, it’s useless to the person looking at it, because a facilities manager juggling forty other things has no reason to treat a slow, incremental line as more urgent than anything else on their plate.
What that same person actually needs is a sentence, not a chart: the filter on this unit has crossed the pressure threshold, it’s restricting airflow enough to matter, it’s costing you real energy, and a work order has already been created. The underlying data didn’t change between those two versions. What changed is whether the system did the last mile of work translating a number into a decision.
This is where a lot of smart building investment quietly stalls. Most facilities teams still end up juggling multiple platforms and dashboards just to get a complete picture of their own building. The industry has largely solved for generating visibility. It’s mostly failed to solve for consolidating it into something a person can act on without becoming a full-time analyst in the process.
Nice-to-Have vs. Must-Have
There’s a real, practical test that separates the platforms that survive from the ones that get quietly dropped at renewal: would anyone notice if it disappeared tomorrow?
A nice-to-have platform gets used by whoever bought it, when they have time, usually during budget season when someone’s trying to justify the spend. A must-have platform is embedded in the actual workflow: it’s the reason a technician got dispatched, and it’s the record someone points to when a contractor needs to be held accountable for a callback. One of these gets checked occasionally. The other one, people would notice within a day if it went down.
Visibility tools, OT network or otherwise, risk landing in the first category if they stop at showing the picture. The ones that earn a permanent place in someone’s actual day are the ones that close the loop, connecting what’s visible to what happens next, automatically, without requiring a human to bridge that gap by hand every single time.
Closing the Loop on OT Network Data Means Someone Has to Own it
Even a well-built alert dies on the vine if it lands somewhere nobody’s watching. A platform that generates a perfectly reasoned recommendation inside its own dashboard, disconnected from the CMMS a technician actually opens every morning, is asking that technician to manually bridge two systems every time. Most people, most days, won’t, and it has nothing to do with caring. Context-switching between platforms is exactly the kind of friction that gets deprioritized the moment something more urgent shows up, which in a building is constantly.
More sophisticated alerting won’t fix this. What closes the gap is making sure the last step, the work order, the technician assignment, lands inside the system of record the team already trusts, rather than a new platform they’re expected to check on top of everything else. Visibility earns its value the moment it stops requiring a person to manually translate it into the next step, and starts doing that translation itself.
Where the Real Value Lies
None of this argues against visibility, network or otherwise. It belongs at the start of the value chain, not the end of it. See the OT network clearly, trust the data that comes off it. Then you can make sure whatever sits on top of that data is actually built to turn a signal into an action, ideally without a person having to notice it every time.
The buildings getting real value out of their technology stack right now aren’t the ones with the most dashboards. They’re the ones where visibility, at every layer, quietly turns into a work order, a dispatched technician, or a fixed problem, without anyone having to babysit the handoff in between.
