Every utility portal project starts with the same ambition: customers will do everything online. Submit, pay, schedule, upload. Most of those projects stall, run over, or launch something the billing clerk quietly routes around. The ambition was the problem. The first version of a portal should be read-only. Earn the write access.
The Phone Call That Disappears
Here is the call a utility clerk answers a dozen times a day: what do I owe, and when is my backflow test due? It takes five minutes — look up the account, check the assembly record, read off the test due date, confirm the balance. A read-only portal answers it with a screen. The customer logs in and sees their service address, their assemblies, the test due date, the balance, the shutoff notice that went out certified mail last month, and the name of the tester who filed the last report. No submission form required. The call just stops happening.
That is what read-only delivers: account and service details, the assets attached to the property, compliance status in plain language, copies of letters sent, and the history of tests, payments, and decisions. It looks modest on a feature list. It eliminates most of the inbound phone traffic, which is overwhelmingly some version of what is my status.
How Going Transactional Too Early Breaks
The moment a portal accepts input, the failures get expensive. Three that actually happen:
- The payment lands on the wrong account. Two accounts share a mailing address — a landlord with two rentals, or a duplicate record nobody merged. The customer pays, the portal posts it to the other account, and now a clerk is reversing a payment in the billing system while the customer's real account drifts toward a shutoff notice.
- The submission creates a duplicate. A customer types their address slightly differently than the CIS has it — Ave instead of Avenue — and the portal helpfully creates a new property record. Staff find it weeks later and merge it by hand, hoping the test history attached to the right one.
- The portal shows too much. A tenant logs in with the service address and sees the owner's full billing history, including the lien letter. Nobody designed that. The data model just never distinguished owner from tenant from tester, and now it is a complaint to the city manager.
Identity, validation, queues, retention — all of it is solvable. But solving it before anyone trusts the underlying data is backwards.
Read-Only Exposes Your Data — Safely
A read-only portal puts your data quality in front of the public, which sounds like a risk and is actually the point. Customers will find the stale mailing addresses, the assembly marked active on a vacant service, the duplicate account. Better they find them on a screen that can only display — where the worst outcome is a correction call — than on a form that can accept a payment against the wrong record. Every error reported is a record cleaned before phase two depends on it.
Each Phase Pays for the Next
Launching read-only first is sequencing, not settling. The data gets cleaned because it is finally visible. Customers learn the portal actually answers their question, so they come back. Call volume drops, which is measurable, and measurable is fundable — that is the budget case for phase two. Then transactions launch onto clean data, for an audience that already trusts the screen. The everything portal, by contrast, pays for nothing until all of it works.
Trust is the actual product of a public portal; transactions are a feature. Show people their account, their assemblies, their due dates, and their letters — accurately — before you let them change anything. Start read-only. Earn the write access.