BMS Alert SLA Design: What Starts, Pauses and Stops the Clock

SLA design for human-raised work is well understood. A caller reports a fault, the report is timestamped, a clock runs, and everybody agrees what happened. Machine-raised alerts break that cleanly, because there are now at least four candidate start times for the same event, the gaps between them are caused by systems rather than by people, and whichever one the report uses decides whether the contractor looks compliant.

The message up front: define the clock before the target. Decide which timestamp starts it, what stops it, and what legitimately pauses it, write those definitions into the contract alongside the durations, and store every candidate timestamp on the record so a dispute can be settled from data. Run response, attendance and rectification as separate clocks, and measure the integration's own latency separately so it never silently consumes a contractor's response time.

1. This is not the severity question

Two distinct pieces of design get merged and then neither is done properly.

The first is which alerts deserve what urgency, and who gets told at each stage when nobody responds. That is severity and escalation design, and it is the subject of alarm severity and escalation design. The second, this one, is how the resulting commitment is measured: what the clock is, when it runs, and what the number means afterwards.

They need to be separate because they are agreed with different people. Severity is settled with operations and controls. The clock definition is settled with whoever owns the contract, and it is the half that ends up in a dispute. The general structure of FM service commitments is covered in SLA matrix design; what follows is specifically about the machine-raised case, where the detection timestamp is not the same as the notification timestamp.

2. The four candidate start times

There is no universally correct choice. There is a correct process: pick one, state why, and record all four so the others remain available.

3. Three clocks, not one

Collapsing everything into one duration from alert to closure produces a number that moves for reasons unrelated to responsiveness, mostly parts availability and access.

• Response. From the agreed start to acknowledgement by somebody accountable. This measures whether the alert reached a person who took it on, and it is the clock most worth tightening because it is almost entirely within the organisation's control.
• Attendance. From the start to somebody being physically at the plant. Dominated by travel, access and shift patterns, which is why it needs its own target and its own pause rules.
• Rectification. From the start to the condition being resolved. Legitimately long when parts are involved, and meaningless as a performance measure unless waiting time is excluded.

Separating them has a side benefit: when a target is missed, the three clocks together usually show why, which converts an SLA report from a scorecard into a diagnosis.

4. What pauses a clock, agreed in advance

Pause rules are where SLA reporting is either defensible or a monthly argument. The rules themselves are not controversial; the problem is that they are almost always invented after the first breach.

• Access unavailable. A tenant space that cannot be entered, or a plant room needing an escort. Legitimate, and it needs a recorded start and end rather than a note in a comment field.
• Awaiting parts. Legitimate for rectification, never for response, and it needs the order reference attached or it is unverifiable.
• Awaiting a permit. Real and often substantial, particularly on isolation work, as in permit to work integration.
• Planned shutdown or works. Alerts during planned activity should usually be suppressed rather than paused, which is cleaner and is covered in suppression during planned shutdowns.
• Outside service hours. Needs a stated convention for an alert raised just before a window closes, because that case occurs constantly and is the most common source of disagreement.

Each pause must be a recorded event with a reason and a duration, not a correction applied to the report later. A report that can be adjusted after the fact is not a measurement.

5. The awkward cases, decided up front

Four situations arise constantly on machine-raised alerts and have no obvious default.

The condition clears before anybody attends. Does the clock stop, and is the target met? A defensible position is that response is still owed because the alert was raised and somebody has to determine whether it was transient, while rectification does not apply. The operational handling is in when a fault clears before a technician arrives.

The same fault recurs and is joined to an existing case. If recurrence attaches to an open case, as in repeated faults as one case, the clock should not restart, or a persistent fault generates an endless series of met targets while the problem continues. That is the single most common way an alert SLA reports well on a building that is performing badly.

The alert was a communications failure, not a plant fault. A device that stopped answering needs a different target and a different responder, usually IT or controls rather than a maintenance trade, per the connectivity loss playbook.

The alert was wrong. A faulty sensor or a misconfigured limit produced a real alert about nothing. The response was still required, so the target applies, but the event should be classifiable as a false alert so the false-alert rate can be measured and reduced. Without that classification, the pressure falls on the responder rather than on the configuration.

6. Reporting it so the number survives scrutiny

• Publish the clock definition beside the figure. One line stating which timestamp starts it and what pauses it prevents most disputes, because most disputes are about definition rather than performance.
• Report achievement with a count, not only a percentage. Ninety percent of ten is a different conversation from ninety percent of four thousand.
• Show excluded and paused time explicitly, as its own figure. A compliance rate that depends on large unexplained exclusions invites exactly the scrutiny it cannot survive.
• Report alert volume and false-alert rate alongside. SLA achievement rises when fewer alerts are raised, which can mean a quieter building or a broken collection path, and nothing distinguishes them without volume on the same page. The completeness measures in data completeness KPIs are the check.
• Keep the evidence queryable. The timestamps and pause events need to survive in the audit trail described in the alert audit trail, or the report cannot be reconstructed when challenged.

The idea to walk away with

On machine-raised alerts the start of the clock is a design decision, not a given, and the interval between detection and notification belongs to the integration rather than to the responder.

Define the clock before agreeing the target, store all four candidate timestamps, run response, attendance and rectification separately, agree pause rules in advance as recorded events, decide the awkward cases before they occur, and measure the integration's own latency so it never quietly consumes somebody else's response time.

Final thoughts

A single check tells you whether your current reporting is sound. Take an alert-driven work order that met its target and work out, from the stored timestamps, how long passed between the condition appearing at the device and a person being notified.

If that interval is small, your measurement is clean and the target describes the team. If it is a significant share of the target, the SLA has been reporting on your integration and attributing the result to your responders, and the fix is a definition rather than a project.

Related reading: Alarm severity and escalation, SLA matrix design, Who owns a BMS alarm, Alert audit trail, Repeated faults as one case, Field service KPIs and SLAs.