“Demand response companies” is a search that returns three different businesses stacked under one label. Voltus, CPower, and Enel North America are curtailment service providers — they sign up commercial and industrial sites, pool the load, and bid the aggregate into utility and ISO programs. Honeywell SmartConnect, Itron, AutoGrid, Tantalus, and Uplight are demand response management system (DRMS) software vendors — they sell SaaS that utilities run themselves to dispatch their own programs. Then there is a third category that the search results barely surface: software partners — engineering firms that build the platform a utility, aggregator, or hardware OEM owns end to end, often around protocol stacks like OpenADR, IEEE 2030.5, and CTA-2045.

The categories solve different problems and are bought by different people. A utility procurement team that buys an aggregator instead of a DRMS, or a hardware OEM that buys a DRMS instead of a custom integration, has paid for the wrong category. This guide separates them — and shows how to evaluate each one before procurement gets binding. For the wider architectural picture of what demand response platforms actually contain, the demand response software and platform vendor guide is the parent reference; this article zooms in on the vendor question that sits inside it.

The “Demand Response Company” Category Is Three Different Businesses Stacked in One Slot

The phrase is a category collision: aggregators, software vendors, and engineering partners all answer to the name “demand response company,” and the buyer’s first job is to pick the category before picking the company. The reason the search results conflate them is structural — generic listicles are easier to publish than category guides, so a “Top 10 Demand Response Companies” article naturally mixes a curtailment aggregator (Voltus), a DRMS software vendor (Honeywell SmartConnect), and a utility-program operator (Enel North America) on the same numbered list. From the search results’ perspective, they are all “demand response companies.” From a buyer’s perspective, only one of them is the right answer.

Why generic listicles miss the buyer’s actual question

A C&I energy manager looking for a turnkey way to monetize idle load capacity needs a curtailment aggregator. A utility procurement team looking to dispatch their own peak-shaving programs needs a DRMS. A hardware OEM that wants to launch a virtual power plant inside its own brand experience needs a software partner. Three distinct buyer profiles, three distinct purchase contracts, three distinct success metrics. A list that ranks them against each other on “best demand response company” is comparing a SaaS subscription, a revenue-share contract, and a custom-build statement of work as if they were the same product.

A short language test: aggregator, DRMS vendor, software partner

If the conversation starts with “What revenue share do you take?” — that is an aggregator conversation. If it starts with “What does the licensing model look like?” — that is a DRMS vendor conversation. If it starts with “What does an engineering scope of work look like?” — that is a software partner conversation. The phrasing is the category test.

The Curtailment Aggregator Trade-Off: Revenue Share for Operational Simplicity

A curtailment aggregator is the right answer when a commercial or industrial site has dispatchable load but no internal energy team to monetize it. The aggregator handles enrollment, market bidding, dispatch, settlement, and customer service in exchange for a revenue share that typically lands between sixty and eighty percent of the gross payment. The C&I buyer trades a majority of the revenue for the operational simplicity of not running a DR program.

Voltus, CPower Energy, Enel North America, PowerSecure, and Sympower all operate in this category, with different geographic coverage, ISO-market specialization, and minimum-load thresholds. The economics scale predictably: a site with five megawatts of curtailable load and the right ISO program can earn five-figure annual capacity payments without hiring anyone. The category’s commercial appeal is that it works without effort.

Where the model breaks down is anywhere the buyer has more than a few sites, a custom dispatch logic constraint, or an OEM-style ambition to own the customer relationship. A multi-market industrial portfolio that spans PJM, ERCOT, NYISO, and CAISO is paying revenue share five times for what could be a single in-house dispatcher. A hardware manufacturer that wants its own VPP brand cannot get there through a partner that takes the customer relationship along with the revenue share. A site with a non-standard load profile — chemical batch processes, data-center cooling, or BESS-coupled PV — often runs into baseline measurement disputes that the aggregator’s standard M&V methodology can struggle to resolve cleanly. The deeper economics of this model, including how aggregators monetize across capacity, energy, and ancillary markets simultaneously, are unpacked in the demand response aggregator business models breakdown.

The category is the right answer for the small-to-mid C&I buyer with no internal team. It stops being the right answer the moment the buyer has scale, a custom requirement, or a brand they want to build around the energy program.

The DRMS Vendor Trade-Off: Standard Features Against Custom Roadmap

A demand response management system vendor is the right answer when a utility or large aggregator wants to run its own DR program on an enterprise software platform without building one. The DRMS handles enrollment, event scheduling, dispatch signaling, telemetry collection, settlement, and reporting through a packaged SaaS — the buyer keeps the customer relationship and the program revenue, and pays the vendor a multi-year license. The trade is between the speed of a standard feature set and the friction of waiting for the vendor’s roadmap to catch up to a custom requirement.

Honeywell SmartConnect, Itron, Tantalus, Uplight, and AutoGrid all operate in this category, with different protocol coverage, ISO-market depth, and orientation toward utility versus aggregator buyers. Codibly’s engine partners include Uplight, AutoGrid, and EnergyHub — they sit alongside the broader DRMS ecosystem rather than against it. The shared category attribute is that the buyer rents a working platform on subscription terms.

The category-evaluation criteria utilities actually apply at procurement are concrete: certification evidence (OpenADR 2.0b/3.0, IEEE 2030.5, CTA-2045), ISO market interface depth (which RTOs are bid into directly versus through a partner), measurement and verification baseline coverage (which baseline methodologies are supported, with what audit trail), scaling economics (per-asset, per-site, or per-program licensing), customization mechanism (configuration, per-customer modules, or platform-level work the vendor takes on the roadmap), and exit cost (data portability, customer-relationship transfer, contract sunset terms). The full evaluation framework lives in the demand response management system evaluation guide; the vendor categories shape the conversation, but the criteria above decide which vendor to sign with.

For automated demand response platforms specifically — where the dispatch loop is OpenADR-driven and runs without a human in the loop — the same six criteria apply with extra weight on certification depth and protocol-library completeness, because automated dispatch is where vendor protocol gaps become operational outages.

The Software-Partner Trade-Off: Build Cost Now Against Optionality Later

A software partner is the right answer when the buyer needs a demand response platform that is owned end to end — the codebase, the certification, the customer relationship, the dispatch logic, and the protocol stack. A hardware OEM building a virtual power plant under its own brand, a utility with a proprietary algorithm that no SaaS DRMS will accommodate, an aggregator outgrowing the per-asset economics of a packaged platform, or a multi-market operator that needs the same codebase to participate in PJM, ERCOT, CAISO, and NYISO simultaneously: these are the buyer profiles where custom development pays back.

The honest cost of this category is three to nine months of build, depending on protocol scope and certification depth. The honest return is codebase ownership, certification independence, custom dispatch logic, multi-protocol coverage from a single platform, and the ability to move into adjacent markets without renegotiating a vendor contract. The business case for demand response covers the financial model that makes a custom build pencil out — typically inside twenty-four months for any operator running more than a single ISO program or supporting more than one protocol stack.

Accelerators are the middle path inside this category. The OpenADR Alliance’s certified implementations, the IEEE 2030.5 CSIP profile, and the OCPP 2.0.1 reference stacks let a software partner ship a certified platform faster than a clean-sheet build, with the same ownership model at the end. Codibly’s OpenADR Accelerator is the engine-level example; the broader category includes equivalent accelerators from the protocol alliances themselves and from a small number of specialist engineering firms. The accelerator option compresses the build calendar without conceding the ownership trade.

Six Questions to Ask Before Signing With Any Demand Response Company

The selection scorecard cuts across all three categories so the buyer can self-select. Each question has a different right answer for an aggregator, a DRMS vendor, and a software partner — and the buyer’s correct vendor is the one whose typical answer pattern matches the buyer’s own business model.

The six questions are: Who owns the customer relationship — you or the vendor? Who owns the codebase or platform — you, the vendor, or both? Which protocols does the platform certify against — OpenADR 2.0b/3.0, IEEE 2030.5, CTA-2045, FERC 2222 ADER readiness? What is the measurement-and-verification baseline approach, and is it auditable? What is the exit cost — and how is data portability priced? Which ISO markets are bid into directly, and which go through a partner? Each question has procurement consequences; the table below maps the typical answer pattern by category.

Question Curtailment aggregator DRMS software vendor Software partner
1. Who owns the customer relationship? The aggregator. The C&I site is enrolled under the aggregator’s ISO registration. The buyer. The DRMS sells software to the operator who keeps the customer. The buyer. The platform is built around the buyer’s brand and contracts.
2. Who owns the codebase or platform? The aggregator. The buyer has no platform — they have a service contract. The vendor. The buyer licenses a working platform on subscription terms. The buyer. The codebase ships to the buyer’s repository at build close.
3. What protocols are certified? Whatever the aggregator’s existing platform supports — usually OpenADR 2.0b plus ISO-specific market interfaces. New protocols come on the aggregator’s roadmap. Vendor-specific. Confirm OpenADR 2.0b and 3.0, IEEE 2030.5 CSIP where applicable, CTA-2045, and FERC 2222 ADER readiness in writing before signing. Buyer-specified. The platform certifies against whatever the buyer’s market access requires, with no inherited protocol gaps.
4. How is M&V baselined, and is it auditable? Aggregator’s standard methodology — usually a regression-based baseline with limited per-site tuning. Disputes resolved on the aggregator’s terms. Configurable across multiple methodologies (10-of-10, regression, weather-normalized) with audit trail. The buyer’s regulatory exposure stays with the buyer. Whatever the buyer’s program requires, with full audit trail. M&V is a build requirement, not a vendor capability.
5. What is the exit cost? High. The customer relationship and historical event data live with the aggregator. Exit means re-enrolling sites under a new vendor, with discontinuity. Medium. Data portability is contractual but rarely free. Migration cost depends on which platform the buyer is moving to. Zero — the buyer already owns the codebase, the customer relationship, and the data. “Exit” means switching engineering vendors, not platforms.
6. Which ISO markets are bid into directly? Whichever the aggregator is registered in. Multi-market participation requires either a multi-region aggregator or multiple aggregator contracts. Whichever the vendor’s market interfaces support. Confirm in writing — DRMS vendors often partner with aggregators for ISOs they do not bid into directly. Buyer-specified. Multi-market participation is a build requirement; the platform interfaces directly with each ISO the buyer needs.

The protocol-certification question (number three) deserves special attention because protocol gaps are the most expensive category of vendor surprise. A vendor whose OpenADR certification is at 2.0a but not 2.0b cannot serve a California Rule 21 program. A DRMS that does not yet support IEEE 2030.5 CSIP-Australia cannot dispatch a SolarEdge BESS fleet in NSW. The full certification matrix is unpacked in the article on why DR protocol certification is your market-access ticket; the procurement-side translation is that protocol coverage is a hard gate, not a roadmap aspiration.

Where the Categories Blur — and Why That Matters for Procurement

The three vendor categories are converging fast, and the convergence changes how procurement teams should write contracts. Aggregators are buying or building DRMS capabilities to keep larger customers from migrating to in-house platforms. DRMS vendors are buying aggregator-style market-bidding capabilities to handle FERC Order 2222 distributed-energy-resource aggregation natively. Software partners are pre-building accelerators that compress the build calendar enough to compete with packaged DRMS on time-to-market. The category lines that were clean five years ago are blurry by 2026, and they will keep blurring.

The forcing function is regulatory. FERC Order 2222 requires every regional transmission organization to allow distributed energy resources to aggregate into wholesale market participation, which pulls aggregators upstream into platform territory and DRMS vendors downstream into market-interface territory. CAISO’s ERS-25 program, NYISO’s ADER framework, ERCOT’s small commercial DR participation rules, and PJM’s Demand Response Auction Mechanism all push the same direction: programs that used to be either utility-dispatched or aggregator-pooled are now both, with the same DERs participating across program types depending on hourly economics. The platform that handles this in 2026 needs to handle it across at least three market interfaces simultaneously — a depth that single-program DRMS were not originally architected for, and that single-market aggregators cannot serve from their existing footprint without expanding it.

Multi-protocol convergence is the moat that survives the regulatory forcing function. A platform that ships OpenADR 3.0 alongside IEEE 2030.5 CSIP and CTA-2045 alongside FERC 2222 ADER signaling can participate in any program regardless of which protocol the local utility chose. A platform that picked one protocol and built around it has a market-access ceiling that no vendor roadmap can lift overnight. The demand response software and platform vendor guide covers the protocol stack in detail; the procurement-side takeaway is that multi-protocol depth is now a 2026 baseline, not a differentiator.

The 2026 Demand Response Vendor Shortlist by Use Case

The right shortlist is not a numbered ranking — it is a use-case map. Four buyer profiles cover most procurement conversations: a small commercial or industrial site with under five megawatts of curtailable load, a mid-to-large utility running its own DR program, a hardware OEM building a virtual power plant under its own brand, and a multi-market aggregator outgrowing a packaged-SaaS platform. Each profile has a recommended vendor category and a representative shortlist of named vendors operating in that category, alongside the trade-off the buyer is accepting.

Buyer profile Recommended vendor category Representative vendors What you trade off
Small/mid C&I site (≤ 5 MW curtailable) — single facility or small portfolio with no internal energy team Curtailment aggregator Voltus, CPower Energy, Enel North America, PowerSecure, Sympower 60–80% revenue share; aggregator owns the customer relationship; standard M&V methodology; limited custom dispatch logic.
Mid-to-large utility running its own DR program with internal operations team DRMS software vendor Honeywell SmartConnect, Itron, Tantalus, Uplight, AutoGrid Multi-year licensing; vendor’s roadmap dictates feature pace; customization runs through vendor’s professional-services org; non-trivial data-portability cost at exit.
Hardware OEM building a virtual power plant under its own brand (battery, inverter, HVAC, EV-charger manufacturer) Software partner with accelerators Custom-development engineering firms with OpenADR, IEEE 2030.5, OCPP, and CTA-2045 accelerator depth (Codibly is an example operating in this category) 3–9 month build calendar; internal operations team to run the platform post-launch; certification responsibility stays with the buyer; full ownership of the codebase, customer experience, and dispatch logic.
Multi-market aggregator outgrowing packaged-SaaS economics, bidding into 3+ ISOs simultaneously Software partner (build) or DRMS vendor with deep market interfaces (rent) Build-side: same accelerator-capable engineering firms as above. Rent-side: AutoGrid, Uplight, Honeywell SmartConnect — confirm direct ISO interfaces in writing. Build trade: 6–12 month calendar to consolidate onto one platform with multi-market depth, in exchange for unit-economics breakeven within 18–24 months. Rent trade: continued per-asset licensing scaling, vendor-managed market interfaces, faster start.

The named vendors in each row are representative, not exhaustive, and not ranked. The category is the recommendation; the vendor names are illustrations of who operates in that category at sufficient scale to be a serious procurement candidate. A buyer in any row should run all three categories’ candidates through the six-question scorecard above before issuing a final RFP — the category recommendation tells the buyer where to start the conversation, not where to end it.

The Vendor Question Is a Build-vs-Partner Question in Disguise

Demand response vendor selection is, at its core, a decision about how much of the DR stack the buyer wants to own. An aggregator is a “rent the whole stack” decision: rent the platform, rent the dispatcher, rent the market access, share the revenue. A DRMS vendor is a “rent the platform, keep the customer” decision: own the customer relationship and program revenue, license the software, accept the roadmap. A software partner is an “own the whole stack” decision: own the platform, the certification, the customer, and the dispatch logic, in exchange for a build calendar and an internal operations team to run it.

The right answer changes with scale and ambition. A small C&I site has no business owning a stack; an aggregator captures most of the value an internal team would. A regional utility has no business renting one; the customer relationship is the franchise. A hardware OEM building a VPP has no business leasing the platform that will define its brand experience; ownership is the product. The vendor categories exist because the buyer profiles are different — and the procurement question that looks like “which company should we hire” is really “how much of this should we own.”

For operators ready to make that decision with a real plan rather than a vendor pitch, Codibly offers demand response software and program integration services and the OpenADR Accelerator as the engineering baseline for build-side engagements. The vendor selection conversation is downstream of the build-versus-partner conversation; this guide is for buyers who want to start with the upstream decision instead.