Traditional demand response was designed around a phone call. A utility program manager would identify a need for load reduction, contact enrolled commercial customers, and request a curtailment. The customer would manually turn down HVAC setpoints or defer industrial processes. Hours later, a meter read would confirm whether the reduction happened. Settlement followed weeks after that.
That model made sense when demand response was a last-resort tool activated a few times a year during extreme heat events. It doesn't make sense when the grid needs flexible load reduction multiple times per week to absorb solar over-generation, manage duck curve ramps, or respond to forecast errors. The operational cadence of a modern DER-rich grid has outrun the program-based DR paradigm.
What "Automated" Actually Means
When people talk about automated demand response, the term covers a range of things, and not all of them represent a meaningful step change from the manual program model.
At the minimum, "automated" means digital notification rather than a phone call. A utility sends an event signal via email or API, the customer's building management system receives it, and an operator at the facility reviews and approves a curtailment action. This reduces response time from hours to maybe 15 minutes, but the human in the loop at the customer site is still a rate-limiting step.
The more meaningful version of automated DR is what utilities sometimes call Auto-DR or OpenADR-compliant automated demand response: a device or building management system that has been pre-programmed to execute a specific curtailment strategy upon receiving a validated signal, without requiring a human approval step at execution time. The building's HVAC controller receives an OpenADR 2.0 event signal, compares it to the customer's pre-configured response profile, and reduces cooling setpoints automatically within seconds.
The third and most operationally useful version integrates demand response into a real-time dispatch optimization loop, where enrolled flexible loads are treated as controllable resources alongside batteries and solar curtailment, and the system dispatches them based on current grid conditions rather than predefined program event calendars.
The OpenADR Foundation
OpenADR (Open Automated Demand Response) is the communication standard that makes the second and third levels of automation possible. Developed originally at Lawrence Berkeley National Laboratory and now maintained by the OpenADR Alliance, OpenADR 2.0b is the current production standard. It defines a REST-based communication protocol between a Virtual Top Node (the utility or aggregator system issuing signals) and Virtual End Nodes (the demand-side devices or building systems receiving them).
What OpenADR standardizes is the signal format and handshaking: event type, start time, duration, and the payload that describes the requested action. What it doesn't specify is what action the end device takes in response. That's left to the device's pre-programmed response profile, which the customer defines during enrollment.
For an aggregator building a portfolio of enrolled commercial DR customers, OpenADR compliance at the customer device level is the technical prerequisite for anything beyond phone-call DR. Without it, you cannot issue a dispatch signal and have any confidence it will be acted on within a known time window.
The Dispatch Integration Problem
Getting DR resources into a real-time dispatch optimization loop is harder than just having OpenADR-connected endpoints. The fundamental challenge is that DR resources are fundamentally different from dedicated storage in ways that matter for optimization.
A battery storage asset has a precisely known state, ramp rate, and available capacity at any given moment. A demand response resource at a commercial building has an available capacity that depends on the building's current operating state, the current HVAC load, occupancy, outdoor temperature, and how many curtailment events have already been called that day or week. If the building was just run through a pre-cooling cycle two hours ago, its thermal flexibility may be nearly zero right now.
This means the dispatch optimizer needs a model of each DR resource's current available flexibility, not just its enrolled rated capacity. Building thermal mass models, occupancy schedules, and event history all feed into that estimate. Without this, you'll either under-dispatch DR (leaving flexibility on the table) or over-dispatch it (calling events that the building can't actually deliver, damaging customer trust and program credibility).
We're not saying this problem is unsolvable. But operators who treat enrolled DR capacity as always-available rated capacity will run into non-performance events when they try to integrate DR into real-time dispatch. The model has to reflect real-world availability.
Response Time and Grid Services
The grid service that automated DR can realistically provide depends heavily on achievable response times. This is where the limits of DR become important to state clearly.
Primary frequency response and fast-acting regulation service require response in under 30 seconds, often under 4 seconds for high-value ancillary markets. Dedicated battery storage can do this. Demand response, even with OpenADR, cannot reliably deliver sub-minute response at scale. OpenADR event delivery, endpoint processing, and actual device actuation typically total 30 seconds to a few minutes at best.
This means DR is most useful for services with 10-minute or longer response requirements: economic load curtailment, distribution-level congestion relief, demand charge management, and hour-ahead load reduction for duck curve management. These are still valuable grid services, and there's significant available capacity in commercial and industrial loads that can participate in them. The mistake is trying to use DR for the high-speed ancillary markets where batteries are the right tool.
A practical portfolio approach: use dedicated storage for regulation and fast frequency response, use automated DR for economic curtailment and day-ahead/hour-ahead load reduction, and use the combination to provide a range of grid services across different timescales. Voltsynth's dispatch model treats these resources as serving different parts of the services stack, not as substitutes for each other.
Settlement and Performance Measurement
The other operational gap in traditional demand response programs is after-the-fact settlement based on a customer baseline. The standard approach calculates a DR customer's load reduction by comparing their actual metered load during an event to a "customer baseline load" (CBL), typically an average of their metered load on comparable non-event days.
CBL methodology has well-documented problems. Customers who know their baseline will be calculated from recent days can inflate it by increasing consumption before events. Weather adjustments to baselines add complexity and dispute surface area. And for a load that naturally varies significantly from day to day, the CBL may not reflect what the actual non-event load would have been.
Automated dispatch with sub-15-minute meter data improves this significantly. When you have a model of the facility's expected load trajectory in real time, you can compare actual curtailment delivery against that modeled trajectory rather than against a statistical baseline from prior days. This is more accurate, reduces dispute frequency, and aligns settlement much better with actual grid value delivered.
What Changes When DR Becomes a Dispatch Resource
When automated DR is fully integrated into a dispatch optimization loop rather than managed as a separate program, a few things change operationally that operators need to plan for.
Event frequency increases. A program-based DR model might call 15 events per year. An automated dispatch resource in a grid with significant solar penetration might be dispatched 80 to 120 times per year, including many short-duration events of 30 to 90 minutes. Enrollment agreements need to reflect this higher call frequency, and customers need to understand that their building control systems will be actively managed, not just occasionally called upon.
Notification lead times shorten. Program-based DR typically provides customers with a day-ahead or two-hour-ahead notice of an event. Real-time dispatch integration may provide 10 to 15 minutes of notice for economic dispatch events, and even shorter windows for urgent curtailment. Not all commercial customers can operate under those constraints. Enrollment screening needs to identify which customers are candidates for real-time dispatch versus day-ahead scheduled curtailment.
The operational benefit is proportional to those constraints. A DR resource that can respond in 15 minutes with 95% reliability is a genuinely useful grid resource. The technical infrastructure to achieve that, OpenADR integration, real-time flexibility modeling, and automated dispatch signals, is not trivial to build and maintain. But for aggregators building a business on flexible load management, it's the difference between running a program and operating a grid resource.