Executive summary

Over the last six months we interviewed 43 directors and VPs of operations at mid-market and enterprise operators running multi-site facilities, property, and field-service portfolios across Canada and the US. The sample skews where MAIA sells: residential and commercial property operators running between 12 and 400 buildings, integrated facilities firms serving retail and institutional portfolios, and commercial field-service companies operating in five or more regions.

Five findings hold across every segment we studied. They are not surprising to the operators themselves — every leader we spoke to could name at least three of them off the top of their head. What is surprising is that nobody has a system that addresses them end-to-end. The same leaders who can articulate the problem with clarity consistently told us they were still solving it with a stack of dashboards, spreadsheets, and the patience of their best people.

Finding 01 — Signal-to-decision latency is 71 days on average

The average multi-site operator takes seventy-one days to convert a meaningful operational signal into an executive-level action. We measured this across ten recurring signal types: arrears spikes, compliance deadline drift, SLA misses, vendor performance decay, energy anomalies, tenant churn risk, contractor-credential lapses, elevator and fire-system faults, work-order backlog thresholds, and staffing gaps. The median was 71 days. The top quartile averaged 19. The bottom quartile exceeded 140.

The gap between groups is not a technology gap. Both use the same PMS, the same FSM, the same Microsoft 365. The difference is that top-quartile operators have someone whose job is explicitly to sit between the systems and the decisions. In every case that person was expensive, scarce, and burning out. This is the market MAIA addresses.

Finding 02 — 73% of enterprise data never reaches a decision

We asked operators to estimate, for each of their primary data sources, what fraction of weekly output feeds into a decision at any level within thirty days. The self-reported median was 27%. Enterprise systems produce the inverse of the telephone game: every hop — sensor to system, system to dashboard, dashboard to meeting, meeting to email, email to action — drops signal. By the time anything reaches the person who can act, three out of four bits have been discarded, aged out, or routed to a distribution list nobody reads.

The operators who do best on this axis have ruthlessly narrowed their dashboards. One VP at a 200-building residential portfolio told us they had deleted 14 of their 16 dashboards over eighteen months on the explicit theory that fewer dashboards mean more decisions. Their backlog compressed 22% in the next quarter.

Finding 03 — Vendor rotation is effectively random in 82% of operators

Vendor and contractor dispatch — who gets assigned the next work order — is a policy-heavy process in theory and an availability-and-personality-driven process in practice. Of the 43 operators in our sample, 35 could describe an explicit fairness policy and only 8 could show a system enforcing it. In the other 27, the policy exists on paper, and actual allocation drifts toward whoever the dispatcher trusts, whoever is easiest to reach, or whoever bid lowest on the last comparable job.

The four operators with automated fairness audits were uniformly the ones running dispatch software with rule enforcement built in, not bolted on. Fairness is a runtime property, not a documentation property. If the system does not enforce it on every assignment, it is not happening.

Finding 04 — Compliance horizons lag by 40+ days

Every operator we interviewed had a statutory-obligation calendar: fire-code inspections, elevator filings, insurance renewals, contractor WSIB verifications, annual reviews. Every operator had missed one in the last twelve months. The median lag between when a compliance obligation became knowable and when it entered the operator's compliance calendar was 43 days. The worst we saw was 128.

This is the most straightforwardly solvable of the five findings — compliance obligations have structure, deadlines, and a finite set of issuers. But the gap is real because compliance lives in contract language, regulator portals, vendor certifications, and one-off emails from insurers, not in any single system. Until those sources are wired into the compliance calendar automatically, the calendar is a lagging indicator of what the regulator already knows.

Finding 05 — Autonomy earns trust at the action level, not the decision level

The most durable finding is about how operators delegate authority to software. Every operator had one or more auto-dispatch, auto-notify, or auto-escalate feature in their existing stack. None of them trusted those features with the decision itself. The autonomy they actually granted was always at the action level: let the system send the notification, but the operator decides who. Let the system draft the notice, but the operator approves it.

This is the right instinct, and it is the exact architecture decision infrastructure should embrace — not as a limitation, but as a feature. The best operators we spoke to had found software that reliably did the actions well while visibly showing its reasoning on every decision. They didn't want the software to be smarter. They wanted it to be legible. Trust is earned at the action layer, in milliseconds, one legible decision at a time.

What the top quartile does differently

Three things showed up repeatedly. First, they treat the decision as the output, not the dashboard — they define what decisions they need each week and work backwards into which signals and systems are required to produce them. Second, they ground every decision in its source: which document, which system, which rule. This makes decisions reviewable, auditable, and reversible without finger-pointing. Third, they unify across systems rather than within them. The worst operators chase feature completeness inside a single system. The best accept that their decision layer sits above their operational systems and is built specifically to reason across them.

Where the next decade goes

Every major category of enterprise software has, eventually, produced a layer above it that compressed the distance between its outputs and a decision. Finance got FP&A platforms on top of ERPs. Sales got CRM intelligence platforms on top of Salesforce. Security got XDR on top of SIEM. Operations is next.

Based on this fieldwork and the deployments we are running, the operations decision layer will differ from its predecessors in three ways. It will be ontology-first, because operations are fundamentally entity-resolution problems. It will be explanation-native rather than summary-native, because trust scales with legibility. It will treat autonomy as an action-level property, not a decision-level one, because that is how the people who do the work already want to delegate.

MAIA is being built to be that layer. This report is the field study. The Operational Ontology is the companion specification, and the Decision Latency Benchmark is the reproducible measurement.

Methodology note

Between November 2025 and April 2026 we conducted 43 semi-structured interviews with directors and VPs of operations at multi-site operators in Canada and the US. Sample inclusion required an operator managing 12+ locations and generating at least 200 work orders per month. Signal-to-decision latency was measured by asking each operator to name three recent examples of each signal category and estimate the time between detection and executive-level action. All figures are rounded medians unless stated otherwise.