The operations center at a mid-sized municipal utility managing an active DER program typically has five information sources running simultaneously during a peak period: the SCADA display showing distribution feeder loads, the AMI portal showing interval data and meter events, the DERMS enrollment dashboard showing program participants, a battery vendor portal showing fleet SoC, and a weather service showing generation forecast overlaid against load forecast.
Five sources, five sessions, five different data refresh cadences. The operator's job in a demand response event is to synthesize those five sources into a single situational picture and make a dispatch decision. The synthesis step is the hidden cost. It is invisible in any staffing model, not tracked in any operational KPI, and it consumes anywhere from 20 to 50 minutes per event depending on how recently each system was refreshed and how cooperative the cross-referencing is that day.
Mapping the actual time burden
To understand where the time goes, it helps to break the synthesis task into its constituent steps.
Step one: establish current grid state from SCADA. This is typically fast, 2 to 5 minutes. The SCADA display is the system that operations teams are most fluent with, and it provides a current view of feeder load, substation status, and any active switching operations. The limitation is that SCADA shows net load on the feeder, not gross generation from behind-the-meter DERs. It tells you the demand you're seeing from the feeder perspective, not the generation activity contributing to or offsetting that demand.
Step two: check AMI for interval data. The AMI portal gives you 15-minute interval reads for enrolled customers. Depending on the AMI vendor and the head-end configuration, the most recent interval may be 15 to 45 minutes old. For an event happening right now, the AMI data shows you the situation as it was, not as it is. Connecting AMI data to SCADA feeder assignments requires knowing which meter IDs map to which feeder, which is either in a manually maintained cross-reference spreadsheet or buried in the AMI system's customer database with a query that may take several minutes to run.
Step three: check DERMS enrollment. The DERMS shows which customers are enrolled in which demand response programs, their enrolled capacity, and whether they have opted out of the current event period. Enrollment data is authoritative for program eligibility; it is not authoritative for real-time asset state. An enrolled customer with a battery is in the DERMS; their current SoC is not.
Step four: check battery vendor portal. This is where the time cost often peaks. If the DER program includes batteries from multiple vendors (common in programs that enrolled customers over multiple years as product availability changed), each vendor's portal is a separate authentication and navigation sequence. Battery SoC data may not refresh automatically; the portal may require a manual page refresh or a data export request to get current state. If the battery data is stale, the operator has to decide whether the SoC reading from 18 minutes ago is close enough to trust for the dispatch decision they are about to make.
Step five: layer in weather and generation forecast. The generation forecast tells the operator how solar output is expected to change over the next two to four hours, which matters enormously for deciding whether to dispatch batteries now or hold reserves for a larger event later. Pulling this from a weather service or a separate forecast tool, converting the generation forecast into an expected net load impact on each feeder, and comparing that against current SCADA feeder loads is cognitively intensive work that the operator is doing manually.
What this costs in real terms
In a utility running five to eight peak events per summer month, the reconciliation time compounds into a meaningful operational burden. Consider an operations team with three staff covering peak hours. Each demand response event requires a 30-minute average synthesis cycle. Five events per month, three months of peak season, three operators participating: that is roughly 225 operator-hours per season spent on data reconciliation before a single dispatch decision is made.
That number doesn't include the reconciliation work that happens outside of formal dispatch events. During shoulder periods, operators check DER fleet state as part of routine situational awareness. Every one of those checks follows the same multi-system workflow at a reduced urgency level, but the same time cost per check.
The less measurable cost is decision quality degradation. A dispatch decision made on data that is 20 to 40 minutes old carries compounding uncertainty. An operator who checks battery SoC at 2:15 PM for a dispatch decision at 2:45 PM is working with a snapshot that may not reflect a charge cycle, a curtailment event, or a change in local grid conditions that happened in between. The operator knows the data is stale but has no current alternative. They round-trip the uncertainty into their decision by dispatching conservatively or by holding back capacity that could have been put to work.
The cross-reference overhead that no one budgets for
One of the more invisible costs in the five-dashboard workflow is the cross-reference maintenance burden. Each of the five systems uses its own customer or asset identifier scheme. SCADA uses meter point addresses. The AMI portal uses meter serial numbers. The DERMS uses program enrollment IDs. The battery vendor portal uses account IDs from the vendor's customer registration system. None of these identifiers match by default.
Someone on the operations team built a spreadsheet that cross-references these identifier schemes, often years ago, often by manually matching them one by one from each system's export. The spreadsheet is updated when someone remembers to update it, which means it carries some number of stale records for customers who changed inverters, moved, or had installation changes. During a dispatch event, the operator relies on this spreadsheet as the linking key between all five systems. The reliability of the synthesis depends directly on the accuracy and freshness of this manually maintained cross-reference.
This is the kind of infrastructure debt that doesn't appear on any budget line. It is maintained informally, often by the longest-tenured operator who built it. When that person is out, the cross-reference function degrades until someone refreshes it, or an event forces a reconciliation effort that surfaces how stale the data has become.
The architectural fix vs the process fix
Operations teams facing this burden often reach for process solutions first: more rigorous shift handoff protocols, scheduled system refreshes before peak periods, cross-training so multiple operators can run the synthesis workflow. These process improvements reduce the variance in reconciliation time but don't address the fundamental issue, which is that the data the operations team needs doesn't live in a form they can access quickly.
The architectural fix is a normalized data layer that continuously ingests telemetry from all five source systems, maintains a unified asset registry with a single authoritative identifier per DER endpoint, and surfaces current asset state through one interface that operators can query without cross-referencing. The data freshness challenge doesn't disappear; IEEE 2030.5 updates can arrive faster than AMI intervals, and battery vendor API latency is what it is. But when data age is tracked and surfaced explicitly for each asset, the operator can make an informed decision about whether to trust the current view rather than guessing whether the last refresh was recent enough.
A 30-minute dispatch synthesis workflow that collapses to 3 minutes is not an incremental improvement in operator convenience. It changes the set of dispatch actions the operations team can practically execute during an event. Faster synthesis means more dispatch iterations per event window, earlier pre-positioning of reserves when forecasts show growing uncertainty, and more capacity actually put to work rather than held back because the operator couldn't confirm it was available in time.