Bespoke Software for ECO4: Keeping Evidence, Installers and Delivery Connected

01

The current ECO4 position

ECO4 is often described as a grant scheme, but its formal name is the Energy Company Obligation. The fourth phase is designed to improve less energy efficient homes and support low income, fuel poor and vulnerable households through energy efficiency measures.

The scheme originally had an end date of 31 March 2026. The UK Government confirmed a nine month extension in January 2026, so ECO4 now runs until 31 December 2026. The extension does not increase supplier targets and there is no carry-over into a future scheme. It is intended to give the market more time to complete the existing obligation, including remediation and controlled closure.

That distinction matters when planning software. A business may still be accepting, assessing and delivering work, but it also needs to know which projects can realistically complete, where evidence is outstanding and which issues could prevent a measure being notified before the deadline.

Older industry pages may still show the original March date. Operational rules should come from current Ofgem guidance, current supplier requirements and the standards that apply to the work, not from a date copied into a spreadsheet last year.

02

One project is a chain of decisions

Imagine a delivery company receiving ECO4 opportunities from several routes. A case begins with contact and property details. The team then needs to understand the eligibility route, the available evidence and whether the property may be suitable for further assessment.

If the case progresses, more people become involved. There may be survey work, assessment records, a retrofit coordinator, proposed measures, installation dates, installer evidence, customer communications, technical checks, supplier queries and notification data.

Each stage depends on information created elsewhere. A missing document near the start may not become visible until somebody prepares the final pack. A measure can look complete on a project board while a photograph, declaration or installer record is still sitting in an inbox.

The operating system needs to show the whole chain. A sales pipeline is useful for managing opportunities, but it is not enough for managing evidence. A folder can store files, but it cannot reliably explain why a decision was made. A spreadsheet can list a status, but it rarely proves which checks happened before somebody changed that status.

03

Where the usual tool stack starts to break

The problem is not that spreadsheets, email or shared drives are bad tools. They are flexible and familiar. They become risky when several people use them to control one important process.

Duplicate entry is the first warning. Staff copy household and property details from a lead form into a CRM, then into an eligibility sheet, then into a survey platform and finally into a notification template. Every copy creates another opportunity for a slightly different address, reference number or measure description.

Evidence is another weak point. Files may be present but not linked to the right project, measure or decision. Nobody can tell whether the latest version has been reviewed. Queries are answered in email, but the answer never reaches the project record.

Then there is version control. Ofgem publishes a supplier data dictionary and notification templates with defined fields and acceptable values. If a team prepares work against an old template, the problem may appear late and across many records at once.

A bespoke system should reduce these hand-offs. It should not create one enormous screen containing every field anyone has ever requested.

04

What the software should own

The most useful starting point is one operational case record. It should connect the household, property, eligibility route, project, measures, people, documents, decisions and notifications without pretending they are the same thing.

Around that record, the system can provide a configurable workflow with clear entry and exit checks, role based access, a measure level evidence register, owned tasks and queries, controlled exports, operational dashboards and an audit trail.

This is not a generic document store. It is a working view of delivery.

05

A useful control at each stage

The exact workflow depends on the business, supplier relationships and measures involved. The following table shows the kind of operational control bespoke software can provide without trying to replace professional assessment or scheme guidance.

The system does not decide whether the work is compliant simply because all the boxes are green. It makes the evidence and decisions easier for qualified people to review.

06

Build the data model around the case

Weak software often begins by turning an existing spreadsheet into a database table. That keeps the same flat structure and hides the relationships that make the operation difficult.

A household is not a property. A project can contain several measures. One measure may have several evidence requirements. An installer may work on many projects. A document can support a particular eligibility route, assessment, measure or technical decision. A query can affect one item without stopping the rest of the project.

Those relationships belong in the data model. A useful model may include household and contact records, property, eligibility route, evidence, project, assessment, measure, installer, professional role, appointment, document, task, query, notification and decision.

This structure allows the system to answer operational questions. Which projects are waiting for installer evidence? Which measures were prepared against a particular template version? Which cases have unresolved queries? Which projects contain all expected documents but have not received a technical review?

A bigger database is not the goal. Clearer questions and safer decisions are.

07

Keep scheme rules configurable

ECO4 guidance, data definitions, supplier processes and templates can change. A brittle system hardcodes every field, status and rule deep inside the application. A small update then becomes a development project, and nobody is sure which historic records used which version.

Keep scheme-specific configuration visible. Record the rule set or template version used for a decision or export. Allow controlled changes to required evidence, accepted values and stage checks. Test a new version against representative cases before making it live.

Historic projects should retain their context. If a field changes in September, the system should not silently make an August decision look as though it used the new rule.

This is also how the investment can outlast ECO4. The stable parts of the system are case management, property records, measures, evidence, roles, tasks, decisions and audit. The ECO4-specific route, fields and templates sit above that foundation as configuration.

08

Connect specialist tools instead of rebuilding them

ECO4 delivery already involves specialist products and professional systems. Assessment software, PAS 2035 workflow platforms, accreditation services, supplier portals and finance tools may each have a valid role.

Bespoke software should not recreate all of them. It should define which system owns each important fact and connect the operation around those boundaries.

For example, an assessment platform may remain the authoritative source for an assessment record. The bespoke portal can store its reference, current status, responsible person and the documents the wider team needs. A supplier template may remain the required notification format. The portal can prepare and validate the controlled export without inventing a parallel scheme.

This approach reduces duplicate work while keeping specialist responsibility where it belongs. It also makes replacement easier. If one external tool changes, the whole operation does not need to be rewritten.

09

Design for installers and reviewers, not just managers

Software is often designed from the dashboard backwards. Managers receive attractive totals while the people collecting evidence face a long form on a phone, poor signal and filenames that only make sense in the office.

Start with the working conditions. An installer may need to see today's properties, open one measure, follow a short evidence checklist, take photographs, add a note and confirm that the upload completed. A reviewer needs to compare the evidence with the requirement, record a decision and send a precise query back to the right person.

Keep each screen focused on the next useful action. Show why information is required. Reuse known property and measure details instead of asking staff to type them again. Save progress safely and make failed uploads obvious.

Adoption is not achieved by training people to tolerate a complicated system. It comes from making the correct route easier than the workaround.

10

Keep people responsible for judgement

Automation can check that required fields are present, dates follow an expected sequence and values use an accepted format. It can flag possible duplicates, expired documents, conflicting records and work approaching a deadline.

Those controls are valuable because they focus attention. They do not replace the judgement of assessors, coordinators, suppliers or compliance teams.

The system should make exceptions visible and provide a clear human route. A reviewer should be able to reject, request more evidence or approve with a recorded reason. Sensitive changes should require the right role. Automated suggestions should be distinguishable from completed professional decisions.

Eligibility is another important boundary. Household and property information may indicate a route worth reviewing, but Ofgem makes clear that eligibility does not guarantee installation. Suppliers choose which projects and delivery partners to fund. The software must not promise an outcome the operation does not control.

11

Replace spreadsheets in controlled steps

The safest build does not begin by importing every spreadsheet and switching the old process off on Friday afternoon.

Start with discovery. Follow several real projects from referral to completion, including awkward ones. Record every system, document, decision, hand-off and piece of duplicated data. Identify the point where work is most likely to stop or become unclear.

Then design a small end-to-end slice. It might cover case creation, measure tracking, installer evidence and technical queries for one delivery route. Use realistic examples and prototype the difficult screens before building the full platform.

Clean the data before migration. Agree one project reference and one owner for each important field. Decide what must be migrated, what can remain in a read-only archive and what should not be retained.

Run the new workflow alongside the old one for a controlled period. Compare outputs, missing evidence and staff effort. Test current notification formats with the people who submit them. Only retire a spreadsheet when the replacement has proved that the operation can recover from mistakes and exceptions.

12

Build for delivery beyond one scheme name

ECO4 now runs until 31 December 2026, but software built today should not become useless when the scheme closes.

The durable business capability is managing retrofit work: properties, people, assessments, measures, installers, evidence, queries, decisions and reporting. ECO4 adds a specific eligibility and notification layer. Keeping those concerns separate leaves the business with a platform that can support remediation, warranty work, other funding routes or a future scheme without pretending they all have identical rules.

That is the real value of bespoke software here. It is not a digital copy of the current forms. It is a controlled operating system that can change when the scheme changes.

For an ECO4 delivery business, the first useful step is to map one real project across every system and hand-off. That usually reveals where evidence becomes detached from decisions, where staff enter the same information twice and where a focused portal could remove the most risk.