Most multi-site sensor rollouts do not fail at the sensor. They fail at week six.

The pilot worked. Twelve sites, clean data, a dashboard the board liked. Then the pallet arrived - three thousand devices, unconfigured, addressed to a head office with no warehouse. Nobody had booked site access. Nobody had a commissioning list. The dashboard that convinced the board in March is still showing twelve sites in November.

Nothing broke. That is what makes this failure mode hard to see coming. The devices work, the platform works, the business case was sound. What ran out was the assumption that installation was a detail to be sorted once the important decisions were made.

By week six the pilot budget is spent, the board is asking for estate-wide numbers, and your engineers have quietly absorbed an install programme that appears on nobody's PPM schedule and in nobody's headcount.

The pilot is not the project

Pilots succeed partly on merit and partly because every condition that breaks a rollout has been removed from them.

Twelve sites means one region, one or two building types, and engineers who can drive between them in a day. It means the sites were chosen because they were straightforward. It means somebody senior was watching, so access got booked and problems got escalated the same week. It means the device count was low enough that configuration happened on someone's desk.

Three hundred sites has none of that. Mixed building stock, some freehold and some with a landlord who requires 14 days' notice and a contractor induction. Trading hours that rule out most of the working day. Sites where the plant room key is held by a third party. Twenty-year-old fabric where the assumption about mounting positions made during the pilot does not survive the first survey.

The pilot proves the sensor reads accurately in your environment. That is worth knowing, and it is a smaller finding than it appears. It tells you nothing about whether you can get 3,000 devices installed, commissioned and reporting across an estate you do not fully control.

Week six: the four things that stall a rollout

Every stalled deployment we have been called into has stalled on the same four items. In each case the item had no owner in the contract, which meant it defaulted to the client's FM team.

Delivery and storage. Devices ship in bulk to whatever address was on the purchase order. Head offices do not have goods-in. Sites cannot store 200 units. Somebody's meeting room becomes a warehouse, and by week eight nobody can tell which boxes have been opened.

Pre-configuration. Devices out of the box are not deployable. Each one has to be joined to the network, named, and mapped to a site and an asset before it means anything. Done centrally before dispatch, it is a production line. Done in the field by an engineer standing on a ladder with a phone, it is roughly twenty minutes per device that nobody costed, multiplied by the device count.

Site access. Three hundred installs is 300 access bookings, sequenced around trading hours, landlord notice periods, inductions and key holders. This is a scheduling function, not a technical one, and it is the single most common reason a rollout that is technically complete is operationally three months late.

Commissioning validation. Somebody has to confirm that every device is reporting, on the right site, against the right asset. Skip it and you get the outcome that damages the project most: a dashboard with gaps, which the board reads as a platform that does not work and your team reads as a data set they cannot trust.

None of these four is difficult. All four are somebody's job. The question to put to any supplier is not whether their devices are accurate - it is which of these four they are contractually responsible for, and what happens to the timeline if they miss.

Outcome: devices arrive configured, addressed and commissioned, not on a pallet

The problem it solves. Three thousand unprovisioned devices delivered to a building with no goods-in, and a configuration task that was never resourced.

What changes:

• Devices procured, warehoused and pre-configured before dispatch, then delivered per site against an install schedule
• Each device mapped to its site and asset on arrival, so nothing is named in the field
• Every unit validated as reporting before the site is signed off

The outcome. The install crew fits devices that already know where they are, and the dashboard fills in site order rather than in fragments.

Deployment reality: roughly 6,000 sensors across 335 sites, 2,000 staff onboarded, inside seven months.

‍Solution: Smart Buildings.

What warehousing and pre-configuration actually remove from your team

The reason this matters to a Facilities Director rather than to a procurement lead is that the work does not disappear when it is unowned. It relocates onto the people who already have a PPM schedule to run.

An FM team absorbing an install programme is a team not doing statutory inspections, not closing reactive work orders, and not managing contractor performance. That cost never appears in the project budget, because it is paid in deferred maintenance rather than in invoices. It shows up two quarters later as a compliance backlog.

Procurement, warehousing, pre-configuration, installation and support sitting with one accountable partner is not a convenience argument. It is the difference between a project with a delivery date and a project that becomes your team's second job.

Device selection works the same way. With 300+ device types and protocols available, the unit is chosen for the environment rather than for the supplier agreement - a deep freeze needs an ELSYS ELT-2 because a display cabinet sensor will not survive it, and a display cabinet needs something else entirely. An estate standardised on one manufacturer's range gets the compromise device in half its locations, and the compromise device is what generates the false alerts that make your team stop trusting the system by month four.

Where existing assets can be read, they are integrated rather than replaced. Meters, BMS points and controllers that already work stay in place and become inputs. That is what keeps a mixed, aging estate from turning into a rip-and-replace programme with a rip-and-replace price.

Outcome: your engineers keep doing PPM instead of becoming an install crew

The problem it solves. An install programme with no crew attached, absorbed by the FM team, paid for in deferred statutory work.

What changes:

• Installation delivered by the supplier's engineers against a booked schedule, not by your team in gaps between callouts
• Access bookings, landlord notice and inductions handled as a scheduling workstream with an owner
• Site sign-off on completion, so nothing sits in a partial state waiting for someone to notice

The outcome. Your PPM schedule survives the rollout, and the deployment has a date that someone other than you is accountable for. Across hard FM work, the same data has cut technician time by 78%.

Deployment reality: up to 400 sites mobilised simultaneously within a single project phase.

‍Solution: Smart Buildings.

What it looks like when the timeline is contractual

The distinction worth holding onto is between a supplier who sells you capability and a partner who owns a date.

The delivery model runs to fixed gates. Day 1 is contract and provisioning. Day 30, install booked and site prep complete. Day 60, install complete and data validated. Day 90, live dashboard and handover. Each gate is reviewed, and a gate review that fails is a supplier problem rather than a conversation about your team's availability.

That model has been run at scale: 335 sites, roughly 6,000 sensors, 2,000 staff onboarded, seven months end to end, across a delivery footprint covering 22+ markets. Up to 400 sites have been mobilised simultaneously inside a single project phase - which is the number that matters, because simultaneous mobilisation is precisely the thing a pilot cannot tell you anything about.

None of that removes risk from the first thirty days. It relocates it. The risk of a stalled rollout moves from your operations budget to a contract with gates in it, which is where it should have been sitting from the start.

Outcome: a validated data set at day 60, not a pilot that never scaled

The problem it solves. A rollout that is technically working on twelve sites in November and cannot be reported on for the estate.

What changes:

• Every site validated at install, so coverage is a known figure rather than an estimate
• Data landing in one dashboard across energy, compliance, occupancy and soft services instead of in seven portals
• Gate reviews at day 30, 60 and 90 with a named owner for each miss

The outcome. At day 60 you have estate-wide data you can put in front of a board, and at day 90 you have a handover rather than an open project.

Deployment reality: day 60 validation across a 300-site estate.

‍Solution: Smart Buildings.

Where to start, if the pilot is already stalling

The useful first step is not a bigger order. It is a scope that includes the four things above with an owner written next to each.

Thirty minutes, no obligation, and you finish with a scoped and costed deployment plan for your estate - device selection per environment, the install schedule against your trading hours and access constraints, and the gate dates. If your existing hardware covers more of it than you expected, you will find that out before the next purchase order, not after the pallet arrives.

‍