What Can Go Wrong with Battery Contract Demand Management?

You bought a battery for demand management, but a single missed peak can wipe out an entire year of savings. What if you could anticipate the real-world failures before they happen?

The biggest things that go wrong are misinterpreting the utility's demand window, underestimating coincident loads that drain the battery, and relying on flawed forecasts. One missed billing peak can matter more than many successful dispatches, reversing the project's economics entirely.

I have seen too many promising battery projects fail. They fail because the discussion starts with a product spec sheet instead of the customer's actual problem. The real risks are not in the battery's chemistry; they are buried in the details of your utility bill and your site's interval data. My entire approach is built on avoiding these common but costly mistakes. Let’s look at how I break down the problem to ensure a battery system actually delivers the savings it promises.

Start with the Battery Contract Demand Management Customer Problem, Not the Product?

You see a battery advertised with a specific kW and kWh rating. But that rating means nothing if it doesn't solve your unique demand charge problem, which is defined by your utility.

The core customer problem isn't needing a battery; it's needing to reliably reduce a specific demand charge on a utility bill. This means defining the required financial outcome first, then identifying the site-specific constraints that can prevent that outcome, like coincident loads or timestamp errors.

My approach is simple and always starts the same way. First, I define the buyer's required outcome in plain financial terms. Second, I identify every constraint that could possibly defeat that outcome. Third, I test the proposed design against those constraints using real site data. I don't even talk about specific products, like a Moletong 261 kWh system, until I've completed this process. Starting with the product is starting at the end. You must start with the problem.

Define the Required Outcome

The goal is never "install a battery" or "shave the peak." It is always a concrete financial target. For example, the real goal is "reduce the monthly billing demand charge by keeping the 15-minute peak demand below 500 kW during the 2 PM to 7 PM summer window." This is a clear, measurable outcome that the entire project can be judged against.

Identify the Real Constraints

With a clear outcome defined, the next step is to find what could go wrong. These are the details that can reverse an apparently obvious answer. I focus on the variables hidden in the data.

Only after I fully understand these constraints can I begin to think about what kind of hardware is needed.

How Demand Window Shapes the Battery Contract Demand Management Design?

You think you know when your facility's peak demand happens. But the utility's official "demand window" might be much longer, forcing you to buy a battery with more energy than you planned for.

The demand window isn't just when your load is highest; it's the specific block of time the utility uses to calculate your billing demand. A four-hour window requires a different battery design (more kWh) than a one-hour window, even for the same peak kW reduction.

The most common design mistake I see is confusing a site's natural peak load with the utility's billing demand window. Your factory might have a predictable spike at 3:15 PM every day when a specific process starts. It's easy to think you just need a battery to cover that one event. However, the utility tariff might state that your billing demand is calculated from the single highest 15-minute average recorded anytime between 2 PM and 7 PM. That five-hour block is the real constraint, not the 15-minute event.

This completely changes the battery specification. You need enough power (kW) to shave the peak whenever it happens. But more importantly, you need enough stored energy (kWh) to be ready to perform that shave for the entire duration of the window. I once reviewed a project where a customer bought a 1-hour battery (250 kW / 250 kWh) to shave a 250 kW peak. The problem was their peak could occur anytime within a 3-hour window. If the battery discharged early based on a false peak, it was empty when the real, higher peak occurred an hour later. That one miss wiped out their savings for the month. The design failed because it was based on the peak event, not the demand window.

When Forecast Error Changes the Economics?

Your control system uses a sophisticated forecast to predict the daily peak. But what happens when that forecast is wrong? A single prediction error can cost you thousands of dollars in demand charges.

Forecast errors mean the battery might dispatch too early, too late, or not at all on the day of the actual billing peak. This turns a planned saving into a major expense. The entire economic model depends on a level of prediction accuracy that is rarely achievable.

No forecast is perfect. An unexpected heatwave can drive up HVAC loads, or a last-minute production run can create a new monthly peak out of nowhere. Relying on a forecast alone is a recipe for failure. There are two ways this can go wrong, and one is much worse than the other.

First is a "false positive." The system predicts a peak, and the battery dispatches, but it turns out not to be the highest peak of the month. This isn't great, as it wastes a discharge cycle and consumes energy, but it's usually not a financial disaster.

The second, and much more dangerous, error is the "false negative." This is when the system fails to predict the actual monthly peak and the battery does not dispatch. This is the catastrophic failure. All the successful dispatches from other days mean nothing. You still get hit with the high demand charge, and the project's return on investment is destroyed for that month.

My strategy is to design for these errors. I would rather dispatch the battery on five days that might be the peak than miss the one day that is the peak. This means the system must be designed to be more conservative. It might require more energy storage (kWh) to handle multiple partial dispatches or a more robust battery chemistry to handle more cycles. It's a trade-off that adds some upfront cost but significantly de-risks the long-term financial performance.

Turning Battery Contract Demand Management into Clear Specifications?

You are ready to buy a battery system for your facility. But a generic request for a "demand management battery" will get you a generic product, not a tailored solution that works.

A clear specification translates your required financial outcome into testable engineering requirements. It must include the target demand limit in kW, the exact demand window from the tariff, and an acceptable failure rate, all validated against your site's actual interval data.

This is how I make the entire process practical and credible for a technical buyer. I turn my analysis into a simple but non-negotiable set of requirements for any potential supplier. I would never just ask for a quote on a Moletong 627 kWh system. Instead, I would provide a performance specification and ask suppliers to prove their system can meet it.

My specification would include a redacted set of 12 months of our site's 15-minute interval data and a copy of the utility tariff. The supplier must then run a simulation of their proposed battery system (whether it's a 261 kWh or 627 kWh model) against our real-world data.

I don't want to see marketing materials; I want to see the simulation output. This must include:

1. A Dispatch Trace: A timestamped log showing exactly when their control algorithm would charge and discharge the battery on every single day.
2. A Utility Bill Reconciliation: A spreadsheet showing the "before" and "after" utility bills for each of the 12 months, proving the claimed savings.
3. An Exception Log: A list of every single 15-minute interval where the system failed to keep the demand below the target.

Finally, I include the conditions under which I would change the recommendation. For example, "If the simulation shows more than one missed peak in the 12-month period, the proposal is rejected." This process forces the focus away from hardware specs and onto the guaranteed financial outcome. It makes the entire engagement transparent and holds everyone accountable.

Conclusion

To succeed, define your financial goal, understand the constraints hidden in your utility data, and demand a simulation-proven solution. This turns a risky purchase into a reliable, predictable investment.