What should a smart building service-level agreement include?

It is entirely possible for a supplier to meet every target in its service-level agreement while part of the building stays out of use for days. Avoiding that starts with what the agreement measures. A smart building SLA should define exactly which systems and services are covered, prioritise incidents by their effect on the building and its occupants, and set separate targets for response, restoration and permanent resolution.

Around that core sit support, security, data and exit arrangements, each covered below. The principles are simple to state and easy to miss: write priorities in building terms, measure what matters to operations and not what is easiest to report, and make sure the agreement still works when the supplier changes or the contract ends.

Beyond the IT template

An SLA copied from an IT service contract measures how quickly a ticket is acknowledged and how long a server stays up. A building operator cares about different things: whether the plant is running, whether rooms are comfortable, whether doors open for the right people and whether alarms reach someone. The SLA has to describe outcomes in those terms.

Twelve sections to settle

Response is not restoration

The commonest weakness in building SLAs is a single "response time". Response means the supplier has acknowledged the incident and started work. Restoration means normal service is back, perhaps through a temporary fix. Resolution means the underlying cause has been permanently corrected. A supplier can respond within minutes and still leave a fault unrestored for days while it waits for parts, which is why all three need separate targets, each precisely defined in the agreement.

Write priorities in building terms

Each priority level should be defined by its effect, with examples relevant to the site. A typical set might have a priority that covers loss of a critical service affecting safety, security or a large part of the building; one for a significant service degraded in part of the building; one for a single room or non-critical function; and one for requests and minor defects. The agreement should also say who can assign a priority, how disputes are resolved, and that the operator's view of impact prevails when it is reasonable.

Life-safety systems such as fire detection and alarm usually have their own maintenance and response requirements under applicable regulations and standards. A smart building SLA should not dilute those, and should state how incidents affecting interfaces with life-safety systems are escalated.

Security belongs in the service terms

Remote support is central to most smart building services, and it is also a significant security exposure. The agreement should require that remote access uses an agreed, monitored route, preferably enabled on demand by the operator; that every person works under an individual named account and credentials are never shared; that the supplier maintains a list of authorised staff; and that access is removed promptly when staff leave. These follow the contract topics CISA and the FBI recommend for integrators; align them with the security terms in your other supplier contracts.

For software and connected products, the agreement should require notice of vulnerabilities affecting the service, a timescale for assessing and applying security updates in a way that respects operational testing, and notice of end-of-support dates. Align those dates with the support period that manufacturers will have to state at purchase under the EU Cyber Resilience Act.

Measure what operations care about

Useful monthly measures include incidents by priority; the proportion of response, restoration and resolution targets met; repeat incidents on the same asset; open incidents by age; the remote resolution rate; platform availability as users experience it; and outstanding security updates. Every high-priority event should also produce an incident report with its root cause and preventive action.

Service credits are not the main remedy

Service credits are often small beside the cost of a building disruption. They are useful as a signal, but the stronger remedies are escalation to named senior contacts, a formal improvement plan after repeated failure, and the right to terminate for persistent underperformance. Those remedies only bite if you can actually bring in another supplier, and that depends on owning your credentials, configurations and documentation.

Plan the exit

At the end of the contract, the supplier should hand over current configurations, backups, documentation, credentials and data in agreed formats, and support the transition to a new provider for a defined period. ISO/IEC 20000-1, the international standard for service management systems (current edition 2018, amended in 2024), sets requirements that include service transition, and it can be a useful reference when assessing a provider's service management capability.