02 / Product concept
UtilitGate
A utility customer portal built around the customer, not the bill run.
- Status
- Concept
- Domain
- Utility software
- Focus
- Customer self-service
Most utility portals are organized around the utility's internal model: accounts, meters, bills, and transactions. Customers arrive with different questions. How much do I owe, why did it change, and how do I deal with it without calling anyone?
UtilitGate is a design and product concept for a customer-facing portal that starts from those questions. It is informed by implementation work in utility software, where the gap between the billing system and the customer experience is usually visible.
This is a concept, not a deployed product. There is no public build to point to yet.
What it covers
A clear account picture
Balance, due date, recent activity, and the next action a customer needs to take, presented in that order.
Self-service that closes the loop
Requests a customer can complete without a call, and an honest status when one needs a person.
Billing and usage, explained
A bill is a calculation. The portal should make the calculation legible instead of only presenting the total.
Digital service interactions
Starting, stopping, or moving service presented as a guided sequence rather than a set of disconnected forms.
Integration with billing platforms
Designed around the assumption that the portal sits on top of an existing billing or CIS platform, not beside it.
Modern, accessible interface
Responsive layouts, readable typography, and keyboard access as baseline requirements, not a later phase.
Technical notes
The integration is the product
A utility portal is only as good as the data behind it. Account state, billing history, payment status, and service requests usually live in different systems, owned by different teams, with different ideas about freshness.
The interesting design work is deciding what the portal is allowed to promise. A balance that might be an hour stale needs different language than a payment confirmation that must be exact.
Designed for low-attention visits
Most customers visit a utility portal a handful of times a year, often because something went wrong. There is no learned behavior to rely on. The interface has to be obvious on the first visit, on a phone, by someone who is already mildly annoyed.
What this is not
UtilitGate is not a claim that a better portal is easy, or that one design fits every utility. Billing platforms, regulations, and service models vary too much for that. It is a direction: fewer dead ends, clearer state, less need to call.
What comes next
- 01Complete the interaction flows for billing questions and payment.
- 02Define the data contracts a portal would need from a billing platform.
- 03Build a static prototype to test the flows end to end.