Before comparing features, it's worth being honest about what your billing and metering systems can deliver today. A portal is only as capable as the data feeding it, and the most common evaluation mistake is shopping for capabilities your current systems can't yet support, then discovering the gap mid-implementation. Utility customer information system (CIS) integration is the ceiling on everything else you evaluate.
If your customer information system can support real-time API calls, a portal can show customers the same account data your customer service reps see the moment they see it, and let customers complete transactions like payment arrangements or service transfers instantly rather than submitting a request that a human processes later. If your CIS can't yet support that level of integration, real-time self-service isn't available no matter which vendor you choose, but consumption and billing analytics fed by file transfer from your meter data and CIS still is. And if you're a sewer district or another non-metered utility, consumption analytics may not be relevant to you at all, while self-service account management still is.
The point isn't to settle for less. It's to ask any vendor directly: what can this platform actually deliver against my systems as they exist right now, and what does the path to the next level of integration look like. A platform built to flex across that range, rather than assuming every utility starts from the same technical position, is worth more than one that only shines in a best-case integration scenario.
There's a real difference between a portal that shows a customer their balance and one that lets them resolve the reason they were about to call. Viewing a bill is table stakes. Completing a budget billing enrollment, setting up a payment arrangement, or requesting a start, stop, or transfer of service, entirely online and reflected instantly in your CIS, is what actually keeps the phone from ringing.
When you evaluate a platform, ask for a live demonstration of a transaction completing end to end, not just a screenshot of an account summary. Ask what happens if the customer's request needs something the portal can't handle automatically. A platform that gracefully hands off to a human when needed, without making the customer start over, is doing self-service right. One that dead-ends into "please call our office" for anything beyond viewing a balance isn't really self-service. It's a read-only mirror of your CIS.
High bills and unexplained usage spikes are consistently the top driver of avoidable calls. The strongest portals get ahead of that by explaining a bill increase in the customer's own usage terms before the bill even arrives, flagging a likely leak automatically rather than waiting for the customer to notice their bill doubled, and showing customers how their usage compares to similar households so a spike reads as informative rather than alarming.
Ask vendors to show you the actual customer-facing explanation a high bill alert produces, not just the backend dashboard your team would see. The backend view matters too, since your team needs consumption dashboards, leak reporting, and the ability to filter and message specific customer segments (top consumers, customers over budget, accounts in the highest rate tier), but the customer-facing explanation is what prevents the call.
A portal that only holds information behind a login is passive by design. Customers have to remember to check it. The more effective model pushes relevant information to customers through the channel they actually use: text, email, mobile push, or even print for the customers who still need it, rather than assuming every customer will proactively log in to look for news.
Ask specifically how a platform handles outbound communication: can it send targeted alerts and reminders through multiple channels, not just one. Can it push outage detection and restoration updates the moment your operations team knows about them. Does it support the kind of periodic, personalized usage report that reaches non-portal users too, since not every customer will register for an account no matter how good the portal is. A platform that only communicates with customers who already logged in is only solving part of the problem.
Most portal evaluations focus entirely on the residential customer, and most portals are built that way too. But a meaningful share of the interactions your team handles involve someone else: a property manager overseeing continuous service across a portfolio of rental units, a nonprofit agency trying to apply a payment pledge on a customer's behalf, a contractor requesting a new service connection for new construction, a title company needing consumption history to close a home sale.
If any of these describe a real slice of your call volume, ask whether the platform has a dedicated, secure way for those users to do what they need without a phone call to your office either. A landlord who can manage an entire portfolio of accounts online, or an assistance agency that can search an account and submit a pledge directly rather than mailing a check and a form, is call volume you've deflected that most portal evaluations never even think to measure. This matters even more for utilities focused on getting struggling customers current before they fall into arrears: a platform that makes it easy for assistance agencies to act quickly is doing real work upstream of collections, not just downstream cleanup.
A portal that only works well in English, only renders cleanly on desktop, and only meets baseline accessibility standards is quietly excluding a portion of your customer base from the self-service option you're trying to get them to use. Ask whether the platform supports multiple languages beyond a browser-level translation plugin, whether accessibility compliance is a stated commitment rather than an afterthought, and whether the mobile experience is a genuine app-quality experience rather than a shrunk-down version of the desktop site.
Use these seven questions in any utility customer engagement portal evaluation, whether you are writing an RFP or sitting in a second demo.
None of these criteria show up cleanly on a feature comparison spreadsheet, which is exactly why they get skipped. But they're the difference between a portal utilities buy and a portal customers actually use. The right question isn't "does it have a feature for that." It's "does a customer's actual problem get solved here, without a phone call," for as many of the real reasons customers call as the platform can reasonably cover.