Built a Blazor-based customer engagement portal for utility providers with self-service billing, real-time outage tracking and CIS-integrated usage insights on Azure.
Utility customers increasingly expect the same self-service experience from their energy provider that they get from their bank or telecom provider - the ability to view bills, track usage, report outages and manage their account without calling a service centre. Most utility companies are running legacy billing and customer information systems (CIS) that were never designed with a modern web experience in mind.
Our client needed a customer engagement portal that would sit in front of their existing CIS, expose the most valuable self-service workflows and reduce inbound support volume - the primary cost driver in their customer operations team.
Customer portal (Blazor Server / SignalR)
We built the customer-facing portal with Blazor Server for the interactive UI. Blazor Server's component model provided the interactivity requirements - real-time bill breakdown views, usage charts that update as date ranges are adjusted - without the added complexity of a separate JavaScript framework.
SignalR WebSockets power the live features: real-time outage map updates when new outages are reported or resolved and live usage data for customers with smart meters. The connection is managed at the Blazor circuit level, keeping WebSocket overhead in line with the page's component lifecycle.
CIS integration (.NET microservices)
The CIS integration layer is a set of .NET microservices that translate between the portal's domain model and the CIS's data formats. Each microservice owns a specific integration surface - billing history, meter reads, account management, outage data - and exposes a clean internal API to the portal regardless of the underlying CIS specifics.
This isolation was a deliberate design choice. The CIS system has integration constraints - rate limiting, batch-only endpoints for some data types, a data model not designed for real-time queries - that needed to be absorbed by the integration layer rather than leaking into the portal's application logic.
Usage insights and conservation guidance
Beyond billing, the portal surfaces usage insights: daily consumption trends, comparisons against similar households and specific conservation recommendations based on usage patterns. The recommendations are generated by the integration layer using rules derived from CIS usage data - pattern matching against defined thresholds rather than an ML model, which was appropriate for the initial release scope.
Role-based access and compliance
The portal serves multiple user types: residential customers, business account holders and internal operations staff who manage account escalations. Role-based access is implemented at the API layer using .NET's claims-based authorization, with portal features conditionally rendered based on the authenticated role.
Data handling for smart meter data - which can reveal occupancy patterns - required field-level access filtering in the CIS integration microservices, ensuring the portal receives only the data needed for each request.
Blazor Server over Blazor WebAssembly was chosen for the security model. Utility customer data should not be processed client-side in a WebAssembly context. Blazor Server keeps all data processing on the server and renders UI updates through a SignalR connection - a pattern that suits the security requirements of a utility billing portal better than client-side WASM.
The microservice split per CIS integration surface enabled parallel development - teams worked on the billing and outage integrations simultaneously without blocking each other - and made it practical to update individual integrations when the CIS vendor released API changes.
The portal launched with billing history, usage insights, outage status and account management workflows live. The client's support team reported a measurable reduction in inbound calls for billing enquiries within the first month - customers self-served the information they had previously called about. The outage map reduced call volume further during outage events, where customers previously called to report outages that were already known and being worked.