The question we hear most often in early conversations with new operators is some version of: "How long does it actually take before this does something useful?" It's the right question. Integration projects in the utility and DER space have a well-earned reputation for taking longer than promised and producing less than expected in the first months. This piece is our honest account of what the first 30 days look like, what typically slows things down, and what you should have ready before we start.
We're not saying every integration is the same. A distribution utility with a well-maintained OSIsoft PI historian and 10 years of 15-minute substation data is in a materially different position from a DER aggregator running a portfolio of 30 battery sites across three ISO markets with metering from four different vendors. Both operators need load forecasting and dispatch optimization. But the path to getting there differs significantly. What follows is grounded in real integration experience rather than an idealized onboarding flow.
What We Need Before Day One
The most common reason an integration takes 6 weeks instead of 1 week is not our software. It's that the data we need isn't in the format, at the latency, or with the history depth that the forecast model requires. The earlier these issues are surfaced, the better.
The core data requirement for the load forecast model is 15-minute interval load data at your point of interest, typically a substation or feeder, for at least 12 months of history. Two years is better, especially if you have any seasonality in your load that we need to model. Data gaps of more than a few days during that history period degrade model training quality and need to be handled explicitly.
For the dispatch optimizer to work, we additionally need current DER asset inventory: what resources you have, their rated capacity, location, state of charge history if available, ramp rate limits, and any contractual constraints on dispatch (must-run hours, minimum state of charge for emergency backup purposes, etc.). This information often lives in a mix of places: the energy management system, a spreadsheet maintained by the operations team, and contracts in a PDF folder somewhere. Getting it into a structured format before we start speeds things up significantly.
Weather data is something we pull from our own feeds, but if you have local weather stations on your system, that data improves forecast quality for localized effects. Not required, but worth knowing if it exists.
Days 1 through 7: Data Connection and Audit
The first week is primarily about establishing data connectivity and auditing what we receive. This is not glamorous work, but skipping it produces forecasts that are wrong in ways that are hard to diagnose later.
Data connectivity for utilities typically goes through one of three paths: a direct connection to an OSIsoft PI historian via the PI Web API, a connection to an Advanced Metering Infrastructure (AMI) data platform that exposes an API, or a CSV/SFTP file transfer process for utilities that don't yet have API access from their data systems. The PI Web API path is our preference; it gives us authenticated near-real-time access to the historian without requiring the utility to stand up new infrastructure. File transfer processes work, but the latency is higher and operational issues like missed file drops need monitoring.
For DER aggregators, connectivity is typically site-by-site through the battery management system API, the inverter telemetry feed, or through an existing SCADA or EMS if one is in place. Aggregators using a charging management platform for EV fleets will typically use that platform's API. This is where mixed-vendor portfolios add complexity: each vendor has a different API, different authentication mechanism, and different data model. We maintain connectors for the major BESS and inverter vendors, but there will often be one or two sites in a portfolio that require custom integration work.
Data audit includes: confirming that interval data arrives at the expected latency and completeness rate, checking for systematic errors like meter scaling issues or timestamp misalignments, identifying structural data gaps in the historical record, and verifying that asset metadata (capacity, location coordinates, connection voltage) is correct. This audit is what distinguishes a forecast that's useful from day one versus one that produces confidently wrong outputs for the first three months.
Days 8 through 14: Initial Model Training
With clean historical data in place, model training runs in the background. The load forecast model is a gradient-boosted ensemble trained on the historical load data with weather covariates. For a well-instrumented utility substation with two years of clean 15-minute data, initial training takes a few hours of compute time and produces an initial forecast that we can evaluate against held-out data before deploying operationally.
The first forecast evaluation is a cross-validation over the most recent 90 days of data not used in training. We look at mean absolute error, the distribution of forecast errors by hour of day and season, and specifically at the model's performance on peak load events. For most distribution substations, a well-trained initial model will produce 15-minute-ahead forecasts with MAPE in the range of 3 to 7% depending on load variability and solar penetration. We won't quote you a number before seeing your data; the right benchmark is relative to your historical load variability, not an industry average.
For new operators, this is also the point at which we review the forecast together and discuss any load characteristics that the model needs to learn but may not have captured yet: special customers with unusual load patterns, recent large load additions or departures, planned infrastructure changes that will affect future load. The model is not a black box you hand off to; it's a tool we build and refine with your operational knowledge contributing to its structure.
Days 15 through 21: Dispatch Optimizer Configuration
The dispatch optimizer requires more explicit configuration than the forecast model because it encodes your specific operational constraints and objectives.
The key configuration inputs: battery state of charge bounds (minimum and maximum SoC you want to operate within, which may differ from the technical limits if you're maintaining emergency reserve), ramp rate limits, contract-based dispatch obligations or restrictions, and market objective function (are you minimizing grid cost, maximizing arbitrage revenue, providing ancillary services, or some combination?). These are not parameters you set once and forget; they reflect your operational strategy and will evolve as your portfolio and market participation change.
The first dispatch schedule is run in shadow mode: the optimizer produces a recommended schedule, but dispatch decisions are still made by your operations team. This is not a slow-trust phase; it's genuinely useful. Shadow mode lets your operators compare the optimizer's recommendations to their intuition in real time, surface cases where the optimizer's constraints are misconfigured, and build confidence in how the system reasons through dispatch tradeoffs before any dispatch authority is delegated.
The common issues found in shadow mode: the optimizer is dispatching a battery below a minimum SoC that the operator maintains for emergency backup reasons but that wasn't encoded in the initial configuration; a contract obligation to a utility requires advance notification before dispatching, and the current configuration doesn't account for that lead time; a battery site has lower usable capacity than its rated specification due to degradation, and the asset model needs to be updated. These are straightforward to fix once identified.
Days 22 through 30: Live Dispatch and Monitoring
Transition to live automated dispatch is incremental, not a single cutover. We typically start with one asset or one asset class, run live for a week, review daily, and expand from there. This is not because we're uncertain about the software; it's because the first real-world dispatch cycles reveal site-specific behavior that shadow mode can't fully replicate.
A concrete example: a battery site that performed normally in shadow mode may show a 5-minute communication delay between receiving a dispatch setpoint and the inverter confirming execution. In shadow mode, this doesn't matter. In live automated dispatch, a 5-minute lag means the asset misses its dispatch window for the first interval. The edge controller configuration needs to be adjusted to compensate. These site-specific timing characteristics are always present in real hardware and are found and corrected in the first week of live operation, not before.
By day 30, most operators are running live dispatch on their primary assets, receiving daily forecast reports, and have a clear picture of where additional work is needed: assets that need telemetry upgrades, data gaps in the historical record that need to be filled for seasonal model accuracy, or market opportunities that the current configuration doesn't yet capture. The goal at the end of month one is not perfection; it's a running system with a known set of improvement priorities. That's a much better position than having waited six months for a comprehensive implementation before turning anything on.