Utility Energy Efficiency Program Management Software: What Happens When the Evaluator Asks for Your Dataset and the Realisation Rate Comes Back Low

The dataset the evaluator asks for

An implementation contractor runs a commercial lighting and HVAC portfolio for a utility. Applications arrive from 300 trade allies, get screened, sampled for inspection, paid, and the claimed savings are reported quarterly. In the autumn the independent evaluation contractor arrives and asks for the tracking data: every claimed measure with quantity, the deemed savings value applied, the technical reference manual version that value came from, the install date, the site, the inspection outcome, and the incentive paid.

Three problems surface within a day. A block of records carries a measure code retired between programme years, and nobody recorded which version was in force at claim time. Custom projects reference engineering calculations that exist as workbooks attached to emails, so the savings number in the tracking system has no traceable derivation. And several hundred lighting projects have quantities that were revised after inspection without the original values retained, so the evaluator cannot tell what was claimed versus what was verified.

The realisation rate comes back well below one. For a utility that means a shortfall against a mandated savings target. For an implementer paid on verified savings it means the invoice gets adjusted, and the difference between what you claimed and what survived evaluation comes straight out of margin. That is the actual product of a programme management system: not the rebate cheque, the defensible record behind it.

Problem one: the measure list is a versioned artefact and most systems store it as a lookup table

Deemed savings values, eligible measure definitions, baseline assumptions and incentive amounts change every programme year, usually by regulatory order, sometimes mid year. A project submitted in December and installed in January may fall under a different version depending on the rule your programme operates under.

If the measure catalogue is a table that gets updated in place, every historical claim silently re-points at the new value the moment it is edited, and reproducing what you originally claimed becomes impossible. The correct design is a versioned catalogue where each measure has effective dates, a citation to the technical reference manual section it came from, and where every application line stores the measure version identifier it was evaluated against. Then a claim from two years ago can be reproduced exactly, and the evaluator's question about which value applied has a one line answer instead of an archaeology project.

This single design choice is the difference between an evaluation that goes smoothly and one that consumes two analysts for a month.

Problem two: custom projects live in engineers' spreadsheets

Prescriptive measures are the easy half. Custom projects, where savings are calculated from engineering analysis rather than a deemed value, are where the large kilowatt hours and the large incentives sit, and they are almost universally managed as workbooks passed around by email.

What gets lost is the chain. A measurement and verification plan was agreed. Pre installation data was collected under some set of assumptions about operating hours and baseline. An engineering reviewer approved the calculation. Post installation data confirmed or adjusted it. Six months later the workbook exists in three versions across two inboxes, and the one referenced in the tracking system is not obviously the approved one.

A build does not need to replace the engineering calculation. It needs to make the artefacts first class objects: the plan, each data collection event, the reviewer's approval with identity and date, the calculation file with a hash so nobody wonders which version it is, and the resulting savings figure linked back to all of it. Engineers keep their spreadsheets. The system keeps the provenance.

Problem three: the trade ally network is a payment and fraud surface

Allies submit on behalf of customers, and the volume concentrates. A handful of contractors will generate a large share of your applications, which is efficient until one of them is submitting the same rooftop unit under two premise addresses, or splitting a project to stay under a per project cap, or applying to two utility programmes for the same equipment.

Detection is a data problem you can only solve if premises, equipment and customers are modelled properly. Address normalisation matters more than people expect, because the same site appears as a street address, a suite number and a utility premise identifier. Serial numbers, where captured, are the strongest signal. Cross programme checks require a shared premise key, which is precisely what a per programme spreadsheet cannot provide.

The other half is money. Incentives paid to allies rather than customers bring tax reporting obligations, banking details, participation agreements, performance flags and suspension workflows. Programme teams handle these in email and finance handles them in the accounting system, and reconciling the two at year end is a recurring fire.

Problem four: budget commitment, not budget spend

Efficiency portfolios are funded from ratepayer collections against a budget approved by measure category and programme year. The number that matters operationally is not spend, it is commitment: applications approved but not yet paid, reservations held for projects in flight, and the pipeline that has been told it qualifies.

Programmes that track spend alone discover in September that commitments already exceed the annual budget, and the response is an abrupt suspension that damages the trade ally relationships the programme depends on. A commitment ledger with reservations that expire, category level thresholds and forward visibility turns that into a managed slowdown months earlier.

Where PowerClerk, Uplight and Franklin sit

Clean Power Research PowerClerk is the workhorse of this category and deserves the position. It is genuinely configurable, it handles forms, workflow and document collection well, and a great many programmes run on it successfully. Two limits show up at scale. The savings engine is not its centre of gravity, so versioned measure catalogues with reference manual lineage tend to be worked around rather than expressed natively. And configuration depth means substantial changes route through the vendor or a trained administrator, which matters when your measure list changes by order with weeks of notice.

Uplight is strong on the customer facing side, particularly engagement and marketplace journeys, and it is a sensible partner for the acquisition end of a residential programme. It is not primarily a back office programme administration system, and using it as one leaves the inspection, payment and evaluation machinery underserved.

Franklin Energy is an implementer with its own tooling. If you are a utility contracting with them, you inherit their platform and that can be a perfectly good outcome. If you are a competing implementer, it is not available to you, and the tooling gap against a large implementer is precisely the competitive problem that pushes mid sized firms to build.

What this costs and how long it takes

From the programme and case management platforms Digital Heroes has delivered, the shape is consistent. A first release with a versioned measure catalogue, eligibility and cap rules, multi channel application intake including an ally portal, document handling and an evaluation ready export runs $70,000 to $160,000 and ships in 12 to 18 weeks. Extending to offline capable field inspection with photo and location capture, incentive payment with tax data handling, the commitment and budget ledger, custom project measurement and verification artefacts, and cross programme duplicate detection takes the total to $200,000 to $500,000 across 9 to 15 months.

Cost drivers particular to this domain: the number of distinct programmes, since each carries its own measure set, eligibility rules and reporting. Custom project handling, which adds engineering review workflow. Utility system integration, because account eligibility checks against a customer information system turn a manual verification into an instant one and are worth doing early. And if you are an implementer working for several utilities, multi tenancy, since each client's data must be genuinely separated while your operations team works across all of them.

What holds cost down: launching with your two highest volume prescriptive programmes and leaving custom projects on the existing process until the catalogue and evaluation export are proven.

When you should not build

Do not build for a single residential rebate programme with a stable measure list and modest volume. PowerClerk will run it, the configuration cost is far below a build, and there is nothing distinctive to protect.

Do not build if your programme is likely to be re-bid to a different implementer inside two years and the utility owns the tracking obligation. Ownership of the system should follow ownership of the reporting duty.

Build when you are paid on verified savings, because the accuracy of your dataset is directly your revenue. Build when you administer several programmes whose measure lists change annually by order and your team spends the first quarter of every programme year reconfiguring. Build when you are an implementer competing against firms with proprietary platforms, since the tooling is visible in your bid and in your evaluation outcomes.

How to choose a developer for programme management work

Ask how they would reproduce a claim made two programme years ago after the measure list changed twice. If the answer is not versioned catalogues with the version identifier stored on the application line, evaluation will hurt.

Ask how they detect the same rooftop unit submitted twice under different addresses. Listen for premise normalisation and equipment identity, not for a duplicate check on customer name.

Ask how field inspection works with no signal in a basement mechanical room. Offline capture with deferred sync and conflict handling is a specific engineering problem, and someone who has not solved it will hand your inspectors an app that loses a morning of work.

Ask what the evaluation export looks like and whether they have ever built one. The right answer describes a per measure row with quantity, deemed value, catalogue version, install date, inspection outcome and incentive, all with lineage.

Ask who owns the repository and the infrastructure accounts, and settle it in writing before kickoff. At Digital Heroes the client owns the code from the first commit. The next step worth taking this week: pick 20 claims from your last programme year at random and try to reproduce each savings number from your own records. However many you cannot reproduce is the size of your exposure at the next evaluation.