Vulnerable Household Flexibility Safety & Comfort Layer

NESO’s CrowdFlex research found vulnerable groups were more likely to report using less electricity than needed, switching off essential appliances or changing care routines, while low-energy users were less well suited to volume-based rewards. Without explicit safety constraints, providers face consumer-harm, trust, complaints and regulatory risks as flexibility becomes more automated and granular.

The economic buyer is likely to be an energy retailer or aggregator already monetising flexible devices or household demand. Front-line users would be product managers, flexibility operations teams, vulnerability leads and data scientists. The household remains the protected end user rather than the software buyer, so adoption depends on fitting into existing device-control, tariff and flexibility stacks.

The evidence supports a specific implementation gap: flexibility programmes need to distinguish technically available load from ethically and practically safe load. It does not prove buyers will purchase a standalone safety product, so the strongest route is likely an API/module sold into existing suppliers and aggregators rather than a new consumer brand.

Interview 10–15 vulnerability, flexibility and product leads across suppliers/aggregators; ask for examples where consumer-protection rules currently block or complicate automation. Secure one design partner willing to replay historic flexibility events against a prototype safety engine and measure avoided unsafe actions, retained flexible capacity, opt-out rates and operational workload.

Defensibility would need to come from specialist consumer-vulnerability logic, consent and override models, thermal/essential-load constraints, auditability and cross-provider integrations rather than generic optimisation. A shared rules engine mapped to Ofgem expectations and tested against real household outcomes could become infrastructure that incumbents prefer to integrate rather than rebuild.

Allow suppliers and aggregators to automate more domestic flexibility while demonstrating that vulnerable and low-income households are not being pushed into unsafe or unacceptable behaviour.

Proxy based — medium confidence.

Commercial hypothesis: £25,000–£60,000 for a paid integration and historic-event replay pilot, followed by roughly £50,000–£150,000 per year for an enterprise licence/API tier depending on households, integrations and assurance requirements. Direct competitors generally use enterprise sales rather than public pricing, so these figures should be treated as a test range, not a market quote.

Evidence basis: Sigma Sustainability and Energy (£1,995–£100,000 per year) is the closest verified adjacent anchor used here. Its buyer, duration and scope are not assumed to be identical; implementation is separated where the opportunity requires integration, assurance or managed delivery.

Ask one regulated operator, developer, utility, system planner or accountable programme owner to fund a paid test of Vulnerable Household Flexibility Safety & Comfort Layer lasting 8–12 weeks, using an opening price of £25,000–£60,000 and covering one live programme and 5–10 assets, submissions, connections or compliance evidence packs. Paid scope: A B2B API and operations console that calculates a household or device portfolio’s 'safe flexibility envelope' before a flex event. Charge by regulated organisation, project, asset portfolio or site and compare the fee with engineering, regulatory, data-reconciliation and programme-assurance effort. Measure evidence gaps, review/commissioning time, exception rate, forecast accuracy and avoided rework. Continue only if evidence or decision time improves by at least 20%, no critical compliance gap is missed and the buyer commits to portfolio reuse. Stop or reprice if integration effort outweighs savings, outputs fail engineering review or the buyer will not fund expansion.

Raise above 90 if a supplier/aggregator confirms current systems cannot encode these safeguards and pays for a standalone API. Reduce below 75 if Piclo, Electron, Axle, Kaluza or major suppliers already provide equivalent configurable vulnerability/comfort constraints as standard, or if buyers treat the requirement solely as internal policy rather than software.