Energy Efficiency Program Management Software Problems: The 7 That Sink Your Realisation Rate, and How to Avoid Them

Why does a programme project get scoped around forms and workflow so often?

Because that is what the day looks like from the outside. Applications arrive, get screened, sampled for inspection, approved and paid, so the proposal describes an intake form, a review queue, a document upload and a status board. All of that is necessary, none of it is the product.

The product of a programme management system is not the rebate cheque. It is the defensible record behind it. Every claimed measure with quantity, the deemed savings value applied, the version of the technical reference manual that value came from, the install date, the site, the inspection outcome and the incentive paid, all with lineage. That is what the evaluator asks for in the autumn, and everything else in the system exists to produce it correctly.

The scoping defence is to specify the evaluation export first and make the developer design backwards from it. Ask what a per measure row looks like and whether they have ever built one. If the answer describes a status report rather than a row carrying quantity, deemed value, catalogue version, install date, inspection outcome and incentive with lineage, they have quoted you a case management tool with rebate vocabulary attached, and the evaluation cycle will be the moment you find out.

What goes wrong when you migrate historical claims and a changing measure list?

This is the workstream that decides whether your first evaluation under the new system goes well, and it is routinely treated as a data load.

The measure list is the hard part. Codes get retired between programme years, values change by regulatory order and sometimes mid year, and baselines get revised. Historical claims reference codes that no longer exist and values that were never recorded alongside them, so migrating them into a current catalogue quietly restates your own history. A project submitted in December and installed in January may fall under a different version depending on the rule your programme operates under, and that rule has to be encoded rather than remembered.

Custom projects are the second problem. Their savings numbers reference engineering workbooks that exist as email attachments in three versions across two inboxes, and the one referenced in the tracking system is not obviously the approved one. There is no automated way to resolve that. Somebody has to decide, project by project, which calculation stands.

What to require: a versioned catalogue built before any historical import, each claim migrated with the version identifier that governed it or explicitly flagged as unverifiable, and a named owner for the custom project reconciliation with a time box. Do not let unresolved history flow into the new system unlabelled, because at evaluation an unlabelled record and a wrong record are treated the same way.

Why do the utility and payment integrations break after launch?

The two integrations that carry the most operational value are also the two that decay quietly.

• Customer information system eligibility. Checking an account against the utility system turns a manual verification into an instant one, and it is worth doing early. It breaks when rate classes are reorganised, when premise identifiers change after a service upgrade, or when an account transfers and the eligibility answer changes without the application being rechecked.
• Address and premise matching. The same site appears as a street address, a suite number and a utility premise identifier, and normalisation rules that worked for one service territory fail on the next.
• Payment and tax handling. Banking details go stale, participation agreements lapse, and tax reporting obligations for incentives paid to allies rather than customers sit between the programme team and finance. Reconciling those two at year end is a recurring fire that nobody owns.
• Multi utility differences. An implementer serving several clients inherits several interfaces, several eligibility rules and several reporting formats, and a change at one client should not be able to disturb the others.

The defences are an adapter per utility rather than one generic connector, eligibility answers stored with the date and the version they were obtained under, and a scheduled recheck for applications that sit in the pipeline long enough for the answer to change.

What happens when evaluation lineage and inspection evidence are not covered?

These are the two gaps that produce low realisation rates, and both look like nice to haves during scoping.

Lineage first. Quantities revised after inspection without retaining what was originally claimed is one of the most common findings there is, because the evaluator cannot tell what was claimed versus what was verified. The correct design keeps both, with the revision recorded as a new value carrying an author, a date and a reason, and the original preserved. The same applies to any post approval adjustment. Evaluators can only verify what you can evidence, so a gap in the chain becomes an adjustment rather than a question.

Inspection evidence is the second. Photographs, measurements, nameplate captures and sign off are the substance of a verification, and if they are collected on paper or in a separate app they arrive detached from the claim. Worse, inspections happen in basements, mechanical rooms and rural sites with no signal, so an app that assumes connectivity loses a morning of an inspector's work and destroys adoption faster than any missing feature.

What to require: offline capture with deferred sync and defined conflict handling, evidence attached to the specific measure line rather than to the project generally, and revisions as append only records. None of this is exotic engineering. It fails when it is written as guidance rather than as a rule.

Should you build custom or configure what you already own?

Configure, if you run a single residential rebate programme with a stable measure list and modest volume. Clean Power Research PowerClerk will run it, it is genuinely configurable for forms, workflow and document collection, and it is the workhorse of this category for good reason. The configuration cost is far below a build and there is nothing distinctive about your programme to protect.

Do not build either if your programme is likely to be re-bid to a different implementer inside two years and the utility holds the tracking obligation. Ownership of the system should follow ownership of the reporting duty, and building a platform you will hand over is misplaced capital.

Uplight is a sensible partner for the customer facing and acquisition end of a residential programme, particularly engagement and marketplace journeys. Where it stops is that it is not primarily a back office administration system, so inspection, payment and evaluation machinery stay underserved if you rely on it for those.

The strain on PowerClerk shows in two verifiable places. Its centre of gravity is not the savings engine, so versioned measure catalogues tied to reference manual sections tend to be worked around rather than expressed natively. And substantial configuration changes route through the vendor or a trained administrator, which matters when your measure list changes by regulatory order with weeks of notice. If both of those describe your year, that is the line.

How do hidden costs get into the quote?

Four places in this domain.

• Programme count. Each programme carries its own measure set, eligibility rules and reporting format. A quote written for two does not scale linearly to six.
• Custom projects. They add an engineering review workflow with its own approvals and artefacts, and they are frequently assumed to be covered by the prescriptive path.
• Multi tenancy. An implementer serving several utilities needs genuine data separation while its own operations team works across all clients. That is architecture, not configuration.
• Offline field capture. Deferred sync with conflict handling is a specific engineering problem, and a developer who has not solved it before will underquote it and deliver something inspectors abandon.

What holds the number down is launching with your two highest volume prescriptive programmes and leaving custom projects on the existing process until the catalogue and the evaluation export are proven in a real cycle.

What separates a build that works from one that fails here?

The builds that work version the measure catalogue properly and store the version identifier on every application line rather than the value alone. Each measure carries effective dates and a citation to the reference manual section it came from. Then a claim from two programme years ago reproduces exactly, and the evaluator's question has a one line answer. This single design decision is the largest determinant of how painful an evaluation cycle becomes.

They capture provenance for custom projects without trying to replace the engineering. The measurement and verification plan, each data collection event, the reviewer approval with identity and date, the calculation file with a hash so the version is unambiguous, and the resulting savings figure, all linked. Engineers keep their spreadsheets. The system keeps the chain.

They track commitment rather than only spend. Applications approved but unpaid, reservations that expire, and pipeline that has been told it qualifies, against category level thresholds. Programmes that watch spend alone find in the autumn that commitments already exceed budget, and the abrupt suspension that follows damages the ally relationships the programme depends on.

And they settle ownership in writing before kickoff. You should own the repository and the infrastructure accounts. At Digital Heroes the client owns the code from the first commit. One thing worth doing this week regardless of what you build: take twenty 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.