Machine Learning for Facilities Management

An FM contract is thousands of small predictions

A facilities management company lives or dies on its service levels. Miss the four-hour response on a failed chiller at a data room and the penalty lands. Send the wrong engineer to a boiler fault, without the right part, and the return visit eats the margin on the job.

Take an FM provider with 120 mobile engineers covering 800 client sites, handling 60,000 reactive jobs a year alongside planned maintenance. The helpdesk assigns jobs by postcode and trade. Job durations come from a standard schedule. Every day the plan is wrong in small ways, and those small ways add up to overtime, subcontractor call-outs and missed SLAs. Machine learning for facilities management is mostly about making that plan less wrong.

Facilities management machine learning use cases

• Reactive job volume forecasting. Predicting jobs by trade and region for the coming days and weeks, including weather-driven spikes such as heating failures in the first cold snap.
• Job duration prediction. Estimating real time on site from asset type, fault description, site and engineer history, so schedules fit the day.
• First-time fix prediction. Flagging jobs likely to need a second visit, so the right skills and parts are sent first.
• Asset failure warning. Using BMS readings, run hours and fault history to spot chillers, boilers, pumps and air handling units heading for failure.
• Energy anomaly detection. Finding buildings whose consumption does not match occupancy or weather, often a stuck valve or a schedule left on overnight.
• Helpdesk triage. Classifying incoming requests by trade, priority and likely cause, now mostly done with language models reading the free-text description.
• Contract margin prediction. Estimating the real cost of servicing a new site from its asset register and building type before pricing a bid.

The data is usually in two places

Most FM providers have the ingredients already. The CAFM system holds job history, and the building management system holds sensor and plant data. They are rarely connected.

BMS data retention is the surprise. Many systems keep trend logs for only a few weeks, so the history needed to learn failure patterns simply does not exist. Starting to store it centrally is a cheap step that pays off later, even before any model is built.

Predictive maintenance: realistic expectations

Planned preventive maintenance is often a contractual and legal requirement, and machine learning does not remove it. What it can do is add early warning for the assets where unplanned failure is expensive, such as chillers serving server rooms, lifts in busy buildings or pumps in critical systems.

A model learning that a chiller's compressor current creeps up and its discharge temperature rises in the weeks before a trip can send an engineer before the failure. That only works if failures have been recorded against the asset, and enough of them have happened. Our post on predictive maintenance for smaller operations covers how to decide which assets justify it.

The cheapest predictive maintenance win is often a simple rule on BMS data nobody was watching. Start there, then model what the rules miss.

How much does it cost?

1. CAFM and BMS data consolidation into one store: six to ten weeks
2. Job duration and first-time fix models feeding the scheduler: eight to twelve weeks
3. Reactive volume forecasting by trade and region: six to eight weeks
4. Asset failure warning for a defined set of critical plant: ten to sixteen weeks, depending on sensor history
5. Energy anomaly detection across a portfolio of meters: six to ten weeks

The return is easiest to show in fewer return visits and less subcontractor cover. If a provider pays for thousands of return visits a year, each costing an engineer's time and van, even a modest improvement in first-time fix is visible in the numbers within a quarter.

When machine learning is the wrong fix

• Fault descriptions are so vague that no model could infer the trade or cause, and helpdesk scripts need fixing first
• Engineer app data is unreliable because jobs are closed hours after they finish
• The scheduler cannot accept variable job durations
• The real problem is recruitment, and there are simply not enough engineers for the contract

Much of this is workflow software and integration work rather than modelling. Our piece on automation for waste and facilities services covers that ground and is often the better first step.

How we would start

SpiderHunts would usually begin with job duration and first-time fix, because they need only CAFM history and affect every single day of scheduling. We would measure how far standard durations are from reality today, build a model, and run it alongside the scheduler for a month. Where the helpdesk is the bottleneck, AI integration for triage often comes first and improves the data the models learn from.

Frequently asked questions