The question every buyer asks and almost nobody answers straight is: what would this actually look like in our building? The usual reply is a dashboard screenshot, which shows the least interesting layer.
Here is the whole shape of one, in order, including the parts that are unglamorous and the point where it stops.
Layer one: collection, which is most of the work
Nothing intelligent happens until the data is flowing, and this is the part every proposal underestimates.
A typical site already generates most of what is needed and none of it is connected: half-hourly data sitting with the electricity supplier, a building management system logging heating and ventilation, sub-meters fitted during a refurbishment and read by nobody since, plant that reports its own consumption to a system that reports it to no one, fuel on cards, and one process whose readings are genuinely on a clipboard.
The first month is not sensors. It is establishing what exists, what will talk to what, and what has to be bridged — meter feeds, the building system's interface, IoT sensors where there is a genuine gap, weather data because consumption moves with it, and the operational logs that say what the site was actually doing at the time.
That last one matters more than it sounds. Energy data without production context tells you a number moved. Energy data alongside what the line was running tells you why.
Layer two: visibility
Consumption against time, by site and by circuit where the metering allows it. This is the dashboard, and it is table stakes rather than the product.
What earns its place is not the chart but the comparison: consumption against how this circuit normally behaves at this hour, on this day, at this production volume, in this weather. A fixed threshold produces alerts nobody reads. A pattern comparison produces the one that matters — this is not what this normally does.
Layer three: analysis, which is where the interesting part lives
Rather than one model asked to be generally clever, the useful shape is several narrow jobs, each with a defined remit and a defined output. Roughly:
Consumption analysis. Watches the energy-intensive processes — refrigeration, compressed air, boilers, cleaning cycles — and identifies where energy is going that the process does not require. Baseload that nothing explains. A plant running through a shutdown. A cycle that got longer.
Equipment condition. Degrading plant announces itself in its energy signature before it fails: a motor drawing more for the same work, a compressor cycling more often against a leak. This tends to justify itself on the maintenance side rather than the energy side, which is worth knowing when you write the business case.
Timing and grid carbon. The carbon intensity of UK electricity varies substantially through the day with the generation mix. Work that can move — pre-cooling, batch processes, charging — has a cleaner hour and a dirtier one. Shifting it changes your reported emissions without changing what you produce, and it is one of the few genuinely free wins available.
Product-level carbon. Tying consumption to output, so a footprint exists per product or per line rather than per site per year. This is what customer ESG questionnaires increasingly ask for, and it is very difficult to produce retrospectively.
The prompt to a person. The layer people forget. A finding that reaches nobody changes nothing, so the output has to arrive where the decision gets made — the supervisor who can adjust the schedule, the engineer who can look at the compressor — in language that says what to do rather than what was observed.
Layer four: the evidence
Everything above generates the reporting as a by-product rather than as an annual project. SECR figures, carbon-neutrality evidence, product footprints, board packs — assembled from the same data every time, with versioned conversion factors and a record behind every number.
This is the part we care most about, and it is the part that most resembles the rest of our work: what the system touched, what changed, who reviewed it. A financial regulator and a carbon certifier are asking the same three questions in different vocabulary.
Where it stops
Two lines, both worth being explicit about.
It recommends; it does not control. A system that changes setpoints on live plant is a different risk category, needing different safeguards and a different conversation with the people responsible for that plant. Recommendation with a human deciding is the right default, and where control is genuinely wanted it is a deliberate, separately scoped step.
It measures savings; it does not guarantee them. Establishing that an intervention worked — separating its effect from weather, production volume and occupancy — is formal measurement and verification, and it is a profession. We build the data layer that discipline depends on. We do not substitute for it, and anyone offering you a percentage before a baseline exists is quoting you someone else's building.
The sequence that works
Collection first. Then a baseline period where the system watches and reports and nothing is optimised — which feels like doing nothing and is the step that makes every later claim defensible. Then analysis on top of a baseline that exists. Then, if it is wanted, control, scoped separately.
A project that skips the baseline can still produce improvements. It just cannot prove they were improvements, which means it cannot be reported, defended, or repeated with confidence — and for a business under a net-zero commitment, unprovable is close to useless.
What to ask for
If you are scoping something like this, the questions that separate a serious build from a demo: what data exists here and what has to be bridged? What is the baseline period and what happens during it? What does the system control, if anything? Where does a finding actually land, and who acts on it? And what record survives, so a figure can be traced to source a year later?
This is the layer we build, to the same standard we build for financial regulators. If you want to know what your existing meters and systems could support before anyone buys anything, a Reality Check is one week and a fixed fee to map exactly that.
This is the part we do — the crossing from a demo to a system that survives production.