You Can't Shave a Peak You Can't See: QSR Demand-Charge Control

Demand charges, not kilowatt-hours, drive most of a multi-site restaurant's electric bill. The hard part is seeing the peaks before they set the rate.

Lower kWh doesn't always lower the bill. A QSR can trim consumption all month and still get hit with a demand charge set by a single 15-minute spike. Across 2026 commercial-rate analyses, demand charges run 30 to 50 percent of a restaurant's electricity bill, calculated from the single highest 15-minute interval in the billing cycle. That math is unforgiving. The peak you set at 2:15 on one bad afternoon becomes the rate you pay on every kilowatt for the rest of the month, at one store or across two hundred.

Managing peaks beats chasing kilowatt-hours alone. That part is correct. The question for an operator running 50 or 200 stores isn't whether peaks matter. It's how you control them across a fleet, and who keeps the savings when you do.

The real gap is per-site visibility

Knowing that peaks matter is the easy part. Seeing per-site demand intervals across a fleet that nobody is metering at that resolution is the hard part. A regional manager can read a monthly utility bill. Very few can tell you which store spiked, at what hour, and why. Without that, peak mitigation is guesswork, not strategy. You can't shave a peak you can't see.

Where QSR peaks actually come from

Three drivers account for most unplanned peaks in a restaurant:

• HVAC short-cycling and simultaneous startup. Rooftop units kicking on together after a setback, or one unit short-cycling from a fault, stack load into the same 15-minute window.
• Walk-in and reach-in faults. A failing defrost cycle or a door left ajar forces compressors to run hard at the wrong hour, often midafternoon when the grid is already charging peak rates.
• Setpoint and schedule drift. After a service call, a thermostat gets left on the tech's setting. Multiply that across a fleet and the peaks quietly rebuild every month.

None of these show up on a utility bill. They show up in interval data, if you're collecting it. And because the demand charge keys off a single interval, the fix is narrow. You don't have to flatten load all day. You have to keep the worst 15 minutes at each site from running away. That is a monitoring problem before it is a hardware problem.

Two ways to respond, and what each costs you

Budderfly's model is Energy as a Service. The provider funds and installs the hardware, then keeps a share of the savings. The tactics in their guide follow from that model. Battery storage and staggered equipment startup shift load off the peak. They work. They also commit you to a provider and a hardware footprint, and the savings spread stays with the provider for the life of the contract.

The other path is software-first. Continuous monitoring of per-site demand intervals, anomaly detection that catches a peak-driving fault in real time, and setpoint discipline that holds across every store after every service call. This controls peaks at the source instead of offsetting them with batteries, and the savings stay on your P&L.

Both reduce demand charges. The difference is ownership. Capital and hardware shift the load and keep the margin. Software gives you the data and the controls, and you keep the spread.

What anomaly detection catches that a battery doesn't

A battery discharges to cap a peak. It does nothing about the fault that caused the peak. A stuck defrost or a short-cycling rooftop unit keeps running, keeps wasting energy, and keeps generating service calls.

Real-time anomaly detection works the other way. On a multi-unit QSR fleet, the platform watches every site's interval data and flags the compressor running hard at 3 p.m. or the rooftop unit cycling every few minutes, before that behavior sets the monthly demand ratchet. The operator gets an alert, dispatches a fix, and the peak never forms. A battery would have paid to hide that same fault behind stored power, month after month, while the equipment kept degrading. Catching the cause is cheaper than offsetting the symptom, and it compounds. The same visibility that protects the demand charge also cuts service calls and extends equipment life. Well-run programs land around 10 percent energy savings in the first year and roughly 15 percent fewer service calls, with payback inside a month.

Five questions to ask any energy partner

Whether you're talking to GlacierGrid, Budderfly, or anyone else, these five questions separate the models:

1. Can I see per-site demand intervals myself, or do I get a monthly summary?
2. Who owns the data and the controls, me or the vendor?
3. What catches a peak-driving fault in real time, before it sets the demand charge?
4. What's the demand-charge math without taking on capital or hardware financing?
5. What does year three look like, after the upfront install is long paid for?

The answers tell you who keeps the savings once the peaks are under control.

What to do next

Pull one month of interval data for your three highest-bill stores. Find the single 15-minute peak that set each demand charge, then ask what was running at that moment. If you can't get that data at all, that's the gap to close first.

GlacierGrid runs a free 90-day pilot on a slice of your fleet. No hardware financing, no savings-share contract. You see the per-site peaks, we flag the faults driving them, and you keep every dollar of the savings.