| Takeaway | Detail |
|---|---|
| Stamp the alarm at T0 and test T0 + 15 minutes against the vendor standard-hours cutoff. | The thesis fixes the BMS lag at 15 minutes; crossing the vendor standard-hours cutoff during that lag moves a routine HVAC fault from a standard-rate dispatch into an after-hours truck-roll. |
| Auto-dispatch when timestamp-plus-lag crosses the cutoff; hold only alarms that stay inside standard hours and are not escalated. | The reader rule requires every BMS alarm to be time-stamped against both the vendor standard-hours cutoff and the alarm escalation severity before the hold or dispatch decision. |
| Apply the same cutoff test across a 50-200-store facilities portfolio. | Field-Ready describes facilities managers covering 50-200 stores; IBM defines a comprehensive IWMS as capturing real-estate and facilities portfolio management data and metrics, including operating costs. |
| Monitor, manage, and report lag-to-cutoff outcomes as portfolio performance, with operating costs tracked. | London Business Training & Consulting lists defining, monitoring, managing, and reporting facilities-management portfolio performance; IBM notes IWMS metrics include operating costs. |
This reference shows how to test every BMS alarm against the 15-minute lag and your vendor standard-hours cutoff before a routine HVAC fault becomes an after-hours dispatch. It gives the timestamp, severity, auto-dispatch, and hold conditions, plus the portfolio checks needed to keep truck-roll timing consistent across properties.

How BMS Routing Lag Compounds
An alarm does not reach a dispatcher as one event; it moves through sensor, controller, BMS front end, notification service, and dispatcher, and each hop can add latency. This guide tests whether a 15-minute aggregate lag — an illustrative figure, not a published benchmark — can change the dispatch class of a routine HVAC fault: an alarm raised at 4:50 PM that incurs such a lag would reach dispatch after a 5:00 PM standard-hours cutoff, so the same fault becomes an after-hours premium call instead of a standard-rate call. Measure your own lag against your own cutoff before assuming the crossing occurs.
The compounding effect is that the lag converts a scheduling problem into a cost-class problem. The fault severity has not changed, but the arrival time has crossed the boundary that separates standard-rate dispatch from premium dispatch. That is why the lag must be measured against the cutoff, not treated as harmless background delay.
Two lag sources can usually be diagnosed without vendor help. First, check the backend polling cycle for each controller: if a controller polls on an interval, an alarm can wait unseen for up to that interval before the BMS front end records it. Second, time-stamp notification delivery by comparing when the alarm leaves the BMS front end with when dispatch receives it; the gap is your notification lag. Add the two gaps to see whether the total can push a late-afternoon alarm past the cutoff.
The mechanism is simple arithmetic against a fixed boundary. If an alarm is generated at 4:50 PM and the aggregate lag is 15 minutes, dispatch sees it at 5:05 PM. If the standard-hours cutoff is 5:00 PM, the alarm has crossed by five minutes. The same 15-minute lag at 2:00 PM does not cross the boundary, so it does not change the dispatch class. The risk is concentrated near the cutoff, not spread evenly through the day.
The operating rule follows from that boundary: time-stamp every alarm at generation and at dispatcher receipt, project whether the lag will carry it past the cutoff, and auto-dispatch any alarm that will cross during the 15-minute lag. Alarms that will not cross can remain in the standard queue. This keeps the lag from silently converting routine faults into premium truck-rolls.

Evidence You Can Actually Verify
Verify the lag in your own data before you trust any vendor number. Pull 30 days of alarm logs and compare each alarm's BMS creation timestamp with its dispatch-notification timestamp; the median difference is your real routing lag. Treat any vendor-quoted lag figure as marketing until you reproduce it in your own log data, and keep the raw export with the calculation so another reviewer can repeat it.
| Verification item | Evidence to retain | If it is missing |
|---|---|---|
| Routing lag | 30-day alarm log with BMS creation and dispatch-notification timestamps | Use your measured median; treat the vendor quote as unverified |
| Standard-hours cutoff | Master service agreement rate schedule section | Ask the vendor in writing; do not assume a cutoff hour |
Establish the fee boundary from the contract, not from a sales conversation. Read the master service agreement's rate schedule section for the standard-versus-after-hours cutoff hour; if that hour is not printed there, the number does not exist and you must ask the vendor in writing for the written rate schedule before you classify any dispatch.
Make the measurement auditable. Use system-generated timestamps from one clock source, apply one time zone to both fields, and exclude records where either timestamp is missing or manually edited. Report the median and the spread of the differences, and note the BMS version, notification path, and network segment in effect during the 30-day window.
Test vendor claims against your operating conditions. Ask for the vendor's test method, sample size, and environment, then compare those conditions with your building's BMS version, network, and notification path. If the vendor cannot reproduce the quoted lag in your environment, record it as unverified rather than as a performance commitment.
Store the evidence where the decision is made. Robotic Imaging notes that facilities managers coordinating across dozens or hundreds of stores spend significant time in stores, with vendors, and in meetings, so the lag calculation, rate schedule, and written vendor response should be available from a phone or tablet during a store visit rather than only from a desktop.
Re-measure after any change that can alter the path: BMS updates, notification-service changes, vendor changes, or network changes. A lag that was measured once is a snapshot, not a permanent property of the system.
Options Compared
Compare the four postures by one question: does the rule change behavior specifically when the 15-minute lag would push an alarm across the standard-hours cutoff? Cost labels are directional only; use your own measured lag and severity classes rather than assumed fees.
| Option | Routing rule | Principal trade-off |
|---|---|---|
| A. Hold all alarms for morning triage | Queue every alarm until the next standard window | Lowest fees; highest equipment-damage exposure |
| B. Dispatch everything immediately | Send a technician for every alarm now | Lowest damage risk; maximum premium truck-rolls |
| C. Lag-aware conditional dispatch | Auto-dispatch alarms that will cross the standard-hours cutoff during the 15-minute lag; hold the rest | Targets the lag-induced crossing without blanket premium dispatch |
| D. Third-party alarm-monitoring relay | Outsource notification and escalation handling | May reduce notification latency; cutoff logic still must be verified |
A fair comparison separates notification latency from dispatch policy. Options A and B change dispatch policy for every alarm; Option C changes it only for alarms whose timestamp plus lag crosses the cutoff; Option D changes who receives the alarm, not necessarily when a truck is dispatched.
Option C wins on the criterion this guide set: it attacks exactly the failure mode the thesis names — the lag alone. It neither pays premium rates for alarms that remain inside the standard window nor defers alarms that the lag will push past the cutoff.
Option C is a decision rule, not a vendor feature claim. It requires the same two timestamps and severity class used in the audit, and it should be tested against held-out alarms before it replaces a blanket rule.
Option D can be useful, but only as a notification layer. A relay that shortens one hop does not automatically timestamp alarms against the standard-hours cutoff or apply severity-aware dispatch.
Costs and Numbers That Matter
Build the cost model as a two-line ledger rather than a blended average: one line for the dispatch premium created by the lag, and one line for the damage exposure created by overnight delay. Keep every input unlabeled as an assumption until your own 30-day audit and work-order history replace it with measured figures.
| Input | Source or method | Use in the model |
|---|---|---|
| Standard dispatch rate | Vendor contract, standard-hours term | Subtract from the after-hours rate |
| After-hours dispatch rate | Vendor contract, after-hours term | Difference is the premium per crossed alarm |
| Lag-crossing fraction | 30-day alarm-log audit: alarms whose BMS creation timestamp plus the 15-minute lag crosses the cutoff, divided by total alarms in the audit | Multiplies the rate difference |
| Alarm count (optional) | Same 30-day audit window | Converts the per-alarm result to a period total |
| Overnight damage delta | Work-order history: comparable fault cost overnight minus same-day cost | Compared against the lag premium for the same alarm class |
Cost of lag = (after-hours rate − standard rate) × (fraction of alarms that cross the cutoff because of the lag). The rate difference comes from your vendor contract's standard-hours and after-hours terms; the fraction comes only from your 30-day alarm-log audit, because cutoff times and alarm volumes are site-specific. Do not borrow an industry percentage. If you want a period total, multiply the per-alarm result by the alarm count in the same audit window; if you want a site comparison, keep the denominator identical across sites.
Equipment-damage exposure = repair-cost delta of a fault left unattended overnight versus the same fault caught same-day. Derive that delta from your own work-order history, not from a generic estimate, and separate condensate or freeze-risk escalations from routine wear so the delta reflects the fault class you are actually routing. A condensate overflow caught during standard hours may be a cleanup and coil check; the same overflow left overnight can become ceiling, flooring, or controls damage, but the size of that gap is a property of your buildings, not a universal number.
Use the model as a decision threshold rather than a forecast: compare the expected premium from the lag against the damage delta for the same alarm class, and let the larger exposure drive whether the alarm is auto-dispatched before the cutoff. Re-run the audit fraction whenever vendor hours, alarm volume, or site mix changes; the model is only as current as the 30-day log behind it.
What the Evidence Does Not Show
Before you adopt the lag-aware dispatch rule, be clear about what the evidence in this guide does and does not establish. There is no published figure for BMS routing lag, no published after-hours fee schedule, and no study correlating a 15-minute lag with a dispatch-cost increase. Every number in this guide is either a measurement method or a worked illustration that must be filled from your own vendor contracts and alarm logs. The cited sources on facilities portfolio management — IBM's IWMS framework, which captures real-estate and facilities data including operating costs, and Robotic Imaging's retail facilities coverage, which describes managers overseeing 50–200 stores — support the general principle that operating-cost data should be captured and measured at the portfolio level, but none of them supplies a routing-lag benchmark or a premium truck-roll price. If you want a number, you have to pull it from your own 30-day log comparison and your own service agreement.
That honesty extends to where the rule itself breaks. The lag-aware rule — auto-dispatch anything that will cross your vendor's standard-hours cutoff during the routing lag — is a decision aid for routine HVAC faults, not a universal policy. The table below states, in one place, the conditions where holding an alarm past the lag is the wrong move versus where the rule still wins.
To run it, export 30 days of BMS alarm records. For each alarm, find the creation timestamp and the notification-delivered timestamp. Compute lag in minutes. Compare the delivered timestamp, not the creation timestamp, against the vendor's standard-hours cutoff. Mark Y when delivery lands after cutoff. Mark N when it lands on or before cutoff. If your escalation policy makes certain severities immediate, flag those rows separately; the five columns still measure whether lag pushed delivery past the cutoff. The Y count is the only number that carries into the cost model; the lag median tells you how early you need to dispatch to avoid adding rows.
Keep the worksheet mobile. Robotic Imaging's field-ready retail facilities platform notes that portfolio intelligence historically lived on a desktop—accessible when you are at a desk and invisible when you are in the field making decisions. A timestamp audit has the same failure mode. If the worksheet cannot be updated during a store visit or vendor meeting, it gets reconstructed later from memory, and the reconstruction can miss the 4:50 PM alarms that crossed at 5:05 PM.
Use the audit as a dispatch trigger, not a postmortem. For any active alarm, add your median lag to the current time. If that projected delivery time crosses the vendor cutoff, auto-dispatch now. If it stays inside the standard window, hold. The worksheet gives you the median lag and the 30-day crossing count; both come from your data, not from a vendor's routing claim.
Worked Example: Run the Numbers
Here is the arithmetic worked once, end to end. Assume, as an illustration rather than a vendor claim, a store whose standard-hours dispatch window closes at 17:00 local and an alarm class whose routing lag you have already measured at 15 minutes. Robotic Imaging's field-ready retail platform notes that facilities managers overseeing 50–200 stores spend a large share of their day in stores, with vendors, and in meetings (roboticimaging.com) — which is the practical reason the alarm's timestamp, not anyone's attention, has to drive the dispatch decision.
Step 1: find the lag-crossing threshold. The last alarm creation time that can still reach a dispatcher inside the window is the cutoff minus the lag: 17:00 − 0:15 = 16:45. An alarm created after 16:45 is not visible to a dispatcher until after the window has closed. Because vendor contracts differ on whether the cutoff minute itself counts as inside, treat the boundary as outside and work from 16:44 — one minute of pad.
Step 2: test three alarms against that threshold.
| Alarm created | Dispatcher notified (+15 min) | Inside the 17:00 window? | Action under the rule |
|---|---|---|---|
| 16:38 | 16:53 | Yes — 7 minutes of margin | Hold to routine dispatch |
| 16:44 | 16:59 | Yes — 1 minute of margin | Hold, but flag as boundary |
| 16:47 | 17:02 | No — 2 minutes past | Auto-dispatch |
Step 3: declare the winner and its break-even trigger. In this example the auto-dispatch rule wins on the 16:47 alarm. Holding it converts a routine fault into a premium truck roll, and the 15-minute lag is the entire reason it crossed — the fault itself looks the same as the 16:44 one. The break-even trigger is 16:44: the cutoff minus the lag, minus the boundary pad. At or after 16:44, auto-dispatch; below it, hold.
Step 4: stress the number. If the measured lag for that alarm class were 22 minutes instead of 15, break-even moves to 17:00 − 0:22 − 0:01 = 16:37. If the standard-hours cutoff were 18:00 instead of 17:00, break-even moves to 17:37 at a 22-minute lag. Each extra minute of lag moves the break-even one minute earlier, so the auto-dispatch band grows minute for minute. Recompute the same subtraction for every severity tier, using whichever cutoff that tier carries, and treat the resulting time — not a flat rule — as the dispatch trigger.
Decision Rules for Dispatch
The dispatch decision comes down to one piece of arithmetic: standard cutoff minus measured lag. If an alarm's BMS creation timestamp falls after that difference, you dispatch immediately at standard rate — you do not route it to a human triage queue, because triage itself burns lag minutes and pushes the same fault into premium territory. The rule is mechanical on purpose. A facilities manager covering 50–200 stores, as the retail portfolio literature from Robotic Imaging describes, cannot personally adjudicate every alarm in real time, so the cutoff-minus-lag test has to run automatically at the alarm layer, not at the desk.
Severity overrides the clock. If the alarm class is life-safety or carries freeze or coil-damage risk, dispatch regardless of lag or cutoff. A 15-minute routing delay is noise next to overnight equipment exposure — a coil that freezes and splits turns a standard-rate service call into a replacement decision, and no cutoff arithmetic justifies letting that sit until morning. Build these two classes as hard-bypass rules in your escalation matrix so they never touch the lag calculation at all.
Contract structure changes the third rule. If your vendor agreement carries a flat 24/7 rate, hold every non-critical alarm for morning triage. The lag costs you nothing in that structure, and paying dispatch attention to routine HVAC faults overnight buys no rate advantage — you are spending the same either way, so spend the attention where triage quality is higher. The check here is contractual, not operational: pull your vendor agreement and confirm whether after-hours carries a premium multiplier or a flat rate before you configure which alarms auto-dispatch. If the contract is silent, treat it as premium until the vendor confirms otherwise in writing.
Put the three rules in one table so whoever configures your BMS escalation logic can implement them without interpretation:
| Condition at alarm timestamp | Action | Rationale |
|---|---|---|
| Timestamp after (standard cutoff − measured lag), routine severity | Auto-dispatch immediately at standard rate | Waiting crosses the cutoff during the lag window |
| Life-safety or freeze/coil-damage class, any timestamp | Dispatch immediately, bypass lag logic | Overnight exposure risk dwarfs routing delay |
| Flat 24/7 vendor rate, non-critical severity | Hold for morning triage | Lag carries no cost premium under flat rate |
Two implementation checks make the table hold up. First, recompute the cutoff-minus-lag figure whenever your vendor's standard-hours cutoff changes or your measured lag shifts — the rule is only as current as its inputs, and the lag verification method covered earlier is what keeps that input honest. Second, log every auto-dispatch decision with the timestamp arithmetic that triggered it, so when a premium truck-roll does occur you can audit whether the rule fired correctly or the cutoff input was stale.
The failure mode to watch is the middle case: a routine alarm timestamped just before the cutoff-minus-lag line, where a dispatcher "quickly checks" it manually and the check itself consumes the buffer. That is why the canonical rule is auto-dispatch, not dispatch-after-review — the review is the lag.
What to do next
| Step | Action | Why it matters |
|---|---|---|
| 1 | Stamp every BMS alarm at T0 and record both the vendor standard-hours cutoff and the alarm escalation severity before deciding hold or dispatch. | Creates the required dual time-stamp and severity check before any routing decision. |
| 2 | Add the fixed 15-minute BMS lag to T0 and auto-dispatch any alarm whose timestamp-plus-lag crosses the vendor standard-hours cutoff. | Prevents a routine HVAC fault from becoming an after-hours truck-roll during the lag. |
| 3 | Hold only alarms whose T0 + 15 minutes still lands inside standard hours with margin and whose escalation severity is not escalated. | Keeps standard-rate dispatch available only when the lag does not cross the cutoff. |
| 4 | Apply the same T0 + 15-minute cutoff test across every store in the 50-200-store facilities portfolio. | Stops site-by-site exceptions from hiding lag-driven after-hours cost. |
| 5 | Track routine HVAC faults that would cross the cutoff under the 15-minute lag and revise dispatch rules around those cases. | Targets the specific faults most likely to trigger avoidable after-hours truck-rolls. |
| 6 | Compare portfolio outcomes against the 30-day figure above and update the facilities-manager playbook for 50-200 stores. | Keeps the cutoff rule aligned with the period and portfolio scope already in the guide. |
Frequently Asked Questions
At what point should a BMS alarm be time-stamped for the cutoff test?
Stamp the alarm at T0 and test T0 plus 15 minutes against the vendor standard-hours cutoff.
What condition turns a routine HVAC fault into an after-hours truck-roll?
Crossing the vendor standard-hours cutoff during the 15-minute BMS lag moves a routine HVAC fault from a standard-rate dispatch into an after-hours truck-roll.
Which alarms should be held rather than auto-dispatched?
Hold only alarms that stay inside standard hours and are not escalated.
What two factors must every BMS alarm be time-stamped against before a hold or dispatch decision?
Every BMS alarm must be time-stamped against both the vendor standard-hours cutoff and the alarm escalation severity before the hold or dispatch decision.
Which group is described as covering 50-200 stores?
Field-Ready describes facilities managers covering 50-200 stores.
What does IBM define a comprehensive IWMS as capturing?
IBM defines a comprehensive IWMS as capturing real-estate and facilities portfolio management data and metrics, including operating costs.
Quick answers
| What happens when the 15-minute BMS lag crosses the vendor standard-hours cutoff? | Crossing the vendor standard-hours cutoff during that lag moves a routine HVAC fault from a standard-rate dispatch into an after-hours truck-roll, raising vendor dispatch cost. |
| How should a BMS alarm be stamped and tested against the cutoff? | Stamp the alarm at T0 and test T0 + 15 minutes against the vendor standard-hours cutoff. |
| When should the system auto-dispatch versus hold an alarm? | Auto-dispatch when timestamp-plus-lag crosses the cutoff; hold only alarms that stay inside standard hours and are not escalated. |
| What does the reader rule require before the hold or dispatch decision? | Every BMS alarm must be time-stamped against both the vendor standard-hours cutoff and the alarm escalation severity before the hold or dispatch decision. |
| How should lag-to-cutoff outcomes be monitored and reported? | Monitor, manage, and report lag-to-cutoff outcomes as portfolio performance, with operating costs tracked, applying the same cutoff test across a 50-200-store facilities portfolio. |
Also worth reading: Building heating repair delays 2026: auto routing 45 to 12 minutes vs vendor escalation: Building heating repair delays 2026: · Heating and cooling cost per square foot: $76,833—Payroll Cost, Not Price: Heating and cooling cost per · Heating repair response times: 4-hour vs next-day dispatch decision 2026: Heating repair response times: 4-hour