What a DSO actually does

The term "distribution system operator" has accumulated so much conceptual baggage that it now obscures more than it explains. Depending on who is speaking, a DSO is a market operator, a regulatory construct, a software platform, or an existential threat to the wires business. Strip the label away and the picture is simpler. A DSO does five things. Most distributors already do two of them, and the useful question is not whether to "become a DSO" but which of the remaining three to build, in what order, and with whom.

The five functions

The first function is visibility: knowing what distributed energy resources are connected to the network and what they are doing, in something close to real time. Not a spreadsheet of connection agreements — an operational picture. A register that says a 500 kW solar array exists on a feeder is administration; knowing it is currently exporting 380 kW into a lightly loaded section is operations.

The second is forecasting, and specifically net-load forecasting at the feeder level. System-peak forecasting is a solved problem and has been for decades. What changes with high DER penetration is that the binding constraint moves down the network. A system that peaks comfortably can still have a feeder in trouble at noon on a mild Sunday because rooftop export has inverted the flow. Forecasting where the network will actually hurt, days to hours ahead, is a genuinely new discipline for most distributors.

The third is dispatch, or more precisely flexibility: the ability to call on DERs when the network needs them, whether that is curtailing export ahead of a thermal constraint or drawing on storage to defer a feeder upgrade. This is the function people usually mean when they say DSO, and it is the one furthest from current practice.

The fourth is settlement. If a distributor asks a resource to do something, it must be able to measure what was actually delivered and pay for it — at the meter, at the interval, against a baseline that both parties accept. Flexibility without credible settlement is a favour, not a market, and favours do not scale.

The fifth is interface: presenting one coherent face upward to the system operator and outward to aggregators. When a transmission-level operator dispatches a resource that sits on a constrained feeder, someone has to reconcile the two views of that asset. That someone is the distributor, whether it has prepared for the role or not.

What distributors already do

Measured against that list, most local distribution companies are further along than the rhetoric suggests — partway into two of the five functions. The first is visibility, in its foundational form. Distributors generally know what is connected, at what capacity, and where: between the DER register, the GIS, and the connection files, the raw material for the operational picture is on hand. It is still the register, not the real-time view — administration rather than operations — but every operational picture is built on exactly this foundation, and having it clean is most of the early work. The second is the connection-facing half of the interface function. Managing the boundary where resources join the network — application intake, impact assessment, cost recovery, commissioning — is mature practice, and it is the same boundary the full interface function extends toward aggregators and the system operator.

The remaining three — forecasting, dispatch, and settlement — are where the gap is, and the gap is operational. Feeder-level net-load forecasting is rare. Anything resembling dispatch — a repeatable, contracted, settled call on customer-owned resources — is rarer still, and settlement follows dispatch. The distance between "we know what is connected" and "we can lean on it when the network is tight" is where nearly all of the DSO work actually lives.

Why scale matters

Here the honest arithmetic intrudes. Running dispatch and settlement properly implies a control-room market desk: people who watch constraints, issue instructions, verify delivery, and manage disputes, around the clock in some form. A distributor with two hundred thousand customers cannot staff that function economically, and pretending otherwise produces business cases that die on their first serious review.

The realistic path for mid-size distributors is shared capability. That can mean a common platform operated across several neighbouring utilities, joint procurement of forecasting and flexibility-management tools, or a services arrangement where one party operates the desk on behalf of others. Adjacent distributors face the same DER growth, draw on the same contractor pool, and answer to the same regulator; the case for building the operational layer once and sharing it is strong. What the arithmetic rules out is the big-bang DSO program — the five-year enterprise transformation that tries to stand up all five functions simultaneously. Capability should arrive in phases, each phase paying for itself before the next begins.

Where to start

Three starting points survive contact with reality. First, DER register data quality. Every downstream function — forecasting, dispatch, settlement — inherits the errors in the register, and most registers were built for billing and connection administration, not operations. Cleaning that data is unglamorous and it is the foundation.

Second, feeder-level forecasting on the handful of feeders where DER penetration is already changing behaviour. Not the whole network; the feeders that matter. This builds the discipline, exposes the data gaps, and produces planning value immediately.

Third, one flexibility use case with measurable value — a storage contract that defers a specific upgrade, a curtailment arrangement on a specific constrained feeder. One use case forces the settlement question to be answered concretely, in contract language, rather than debated in the abstract.

Do those three things and a distributor has quietly built the core of the DSO role without ever launching a program by that name. Which is, in most cases, exactly how it should happen.