AI energy management in hotels: how to test a vendor's promise on your own meters

AI energy management in a hotel is software that reads the hotel's electricity, gas, water and heating data and then either reports it, recommends changes, or moves setpoints itself. To test a vendor's promise, fix one metric, record a baseline on your own submeters, and compare like with like: same weather, same occupancy, same tariff.

A vendor shows a savings figure from another property and a dashboard with a line that falls. Your bill is your own, your weather is your own and your occupancy is your own, so the only test that counts runs on your meters. After reading this you will be able to classify what a vendor is actually selling, check whether your building can support it, and run a before-and-after test you can defend to an owner or an auditor.

What does AI energy management mean in a hotel?#

In a hotel it means software that reads electricity, gas, water and heating and cooling data and then does one of three things: reports it, recommends a change, or moves equipment setpoints itself. The AI label can sit on any of the three, and only the third changes your bill without a person.

Set the scope at the start. This is the energy the hotel consumes for rooms, kitchens, laundry, pool plant and public areas, not the electricity that AI systems themselves use elsewhere. The distinction matters because a vendor's marketing may blur it.

Monitoring and reporting means dashboards, per-floor or per-room consumption, and alarms when a number moves outside its normal range. Nothing changes by itself; the value comes from what a person does next. A recommendation product suggests setpoints, schedules or maintenance actions and a person applies them, so value depends on whether your team has the time and the authority to act. Closed-loop control writes setpoints to the building system for heating, ventilation, air conditioning and lighting, inside limits a person sets; savings and risk both live here.

Ask which of the three the product is, in writing, and which equipment points it can write to. A dashboard with an AI label is still a dashboard. The label is not the mechanism: energy falls when a setpoint moves, a schedule changes, a fault is fixed or equipment switches off, so ask which of those the product actually performs. Separate measuring from acting. A system that measures well but cannot act still helps, but the saving then belongs to your team, not to the software.

What has to exist before the software can save anything?#

Three things: interval consumption data from submeters, stay data from the property management system, and a building system that accepts commands. Without all three the software can only report whole-building totals after the fact.

A single incoming bill cannot show whether a change worked. Start submetering with kitchens, laundry, pool plant, and floors or wings; per-room or per-circuit data is better where the wiring allows it. Readings at 15-minute or hourly intervals let you compare the same hours of the same kind of day, while monthly totals hide the effect of a schedule change. If you are starting from daily manual readings, the habits in daily meter readings a hotel can act on are the natural first step.

Stay data from the property management system matters as much as the meters: occupied rooms, arrivals and departures, room moves and out-of-order rooms. Without it you cannot separate "less energy because fewer guests" from "less energy because of the change". You also need a building management system that accepts commands, plus a documented list of which points are writable. Read-only connections are common and are not a fault; they simply limit the product to the first two classes.

Add weather for the same period, from your own sensor or a nearby station, because heating and cooling load follows outdoor temperature and humidity. Name an owner inside the hotel: someone who reads the data every week and can authorize a setpoint change without waiting for a meeting. Finally, record a baseline before anything is switched on: a clean recent month plus the same months last year, with any building or outlet change written down beside it.

Who approves a change to heating or cooling, and who answers the guest?#

The technical service keeps authority over plant and safety limits, the software works inside limits a person writes down, and the front desk keeps a one-touch override for a guest.

Write the limits before go-live: minimum and maximum room temperature, how far an empty room may drift, and the hours in which automatic changes may run. Some plant a person must always control: boilers, domestic hot water, pool plant and water treatment, kitchen gas, and any check the law, the insurer or the manufacturer requires. The software may read these; it must not be able to write to them.

Guest comfort is a revenue question, not only an energy one. One refund or one bad review can cost more than the kilowatt-hours saved, so the escalation path belongs in the commissioning document. Give the front desk a single action that returns a room to normal, and a log of who overrode what and why, reviewed weekly.

Use two tiers of approval: changes inside the band run automatically and are logged; anything outside the band waits for the technical service. This is the same logic good hotel software uses for sensitive actions, and the wider questions are covered in energy management and room controls: what to check before investing. Every comfort complaint that follows an automatic change should be reviewed, and repeated complaints tighten the limits rather than being argued away. Name the accountable person and the escalation contact in the contract, not in an email that leaves with the person who wrote it.

How do you test a savings claim on your own meters?#

Fix the metric and the method before the system is switched on, then compare like with like: same season, same weather, same occupancy, same tariff, and a control area if you have one.

Pre-register the test: the metric, the measurement period, the comparison area and the threshold that will count as a result. Agree it in writing with the vendor before go-live, so the goalposts cannot move afterwards. Your baseline needs at least one clean month of interval data before switch-on, plus the same months last year if the operation has not changed, with every change to the building noted in between.

Normalize for weather. Use heating and cooling degree days, or plot consumption against outdoor temperature, so a cold week does not look like a failure and a mild one does not look like a success. Normalize for occupancy using occupied rooms or guest-nights from the property management system, not the occupancy rate alone, and exclude out-of-order rooms and closed outlets from both sides of the comparison.

Use a control if you can: a wing, a floor or a building left on the old settings gives a far stronger answer than a year-on-year comparison. If there is no control, say so when you report. Measure consumption before cost: a tariff change, a demand charge or a fixed fee can move the bill with no saving at all, so keep the price history beside the meter data.

Check the instrument too. Submeter accuracy, a missing interval, a sensor in the wrong place, a new chiller or a closed restaurant can all explain a difference that has nothing to do with the software. Report the result whether it is positive or not, and keep the raw data. For example, a test that shows no difference in a mild month is still a result if the method was fixed in advance. The broader discipline of building the business case from your own numbers applies to any AI purchase, not only energy.

Where does a timer or a fixed rule do the same job?#

For most hotel loads a schedule plus an occupancy signal already captures the saving; software that adjusts itself pays only where many variables interact and the pattern changes often.

Loads a timer handles well include outdoor lighting and signage, pool filtration on a fixed schedule, restaurant ventilation during service hours, and laundry shifts. An occupancy signal handles room setback when a room is empty, and corridor and public area lighting by time of day and daylight. Genuine complexity appears where heating and cooling fight each other, where chiller staging runs against outdoor temperature and occupancy, where kitchen extract follows service load, or where hot water meets arrival peaks.

Work in the right order: write the simple rule first, commission it properly, measure it for a month, then ask what the AI adds on top of that number rather than on top of the old bill. Count the cost of complexity: sensors, commissioning time, staff training, a subscription, and a control that is hard to explain to a guest, an auditor or an insurer. A rule can be read in one line and defended in one sentence. If nobody at the hotel can explain why a setpoint moved, a complaint or an inspection becomes an argument.

What should the contract pin down before you sign?#

Three things: who owns the meter and stay data, what exactly the savings claim rests on, and what happens to the building when the software or the contract changes.

Data ownership and export come first: interval data, the baseline and the results belong to the hotel, exportable in a usable format on request and at exit. The savings claim must be in writing, with the baseline period, the normalization method, the measurement period, who measures, and whether the figure is a guarantee or an estimate. A guarantee needs a defined remedy, not an adjective.

The vendor will update the product. Ask how a change is announced, whether the baseline is re-run after it, and whether the old version can stay in place for the measurement period. On access and liability, pin down the exact list of points the software may write to, what happens if it writes outside the band, who carries the insurance, and who pays for a spoiled stay or damaged plant. Agree the exit: what happens to the submeters, the historical data and the control settings when the contract ends. The building must run without the vendor, on your settings.

Ask for fees split into hardware, commissioning, subscription and support, so you can see what you are still paying for in year two. Have your own legal and financial adviser read the contract; this article is a checklist, not a legal opinion. The specific clauses worth insisting on are covered in more detail in AI clauses in hotel software contracts.

What to do next#

Pick one meter and one month, write the metric and the normalization method on a single page, and ask the vendor to run the test on your numbers before you sign anything. The parts fit in that order: decide which of the three product classes you are buying, check that the meters, the stay data and the writable points exist, agree who may change plant and who answers the guest, run the before-and-after test with weather and occupancy taken into account, and put the baseline, the data ownership and the exit terms into the contract.