Most articles about utility CIS RFPs read like generic B2B SaaS procurement guides. The advice is fine: define requirements, score vendors, check references. It's also useless. Utility billing systems aren't generic SaaS, and the buyers aren't generic either.
A regional sewer district serving more than 1 million people recently published an RFI for a Customer Information System and Customer Self-Service portal replacement. Public-records statutes make this kind of procurement document widely available, which turns it into a clean window into what real utility buyers ask. The district bills more than 400,000 accounts at close to $50 million per month. They're replacing a CIS implemented in 2004 and upgraded in 2015.
Here's what the RFI tells you about what experienced utility CIS buyers actually care about, and where most vendor pitches miss the point.
1. Premise-based billing isn't a feature. It's the foundation.
The district bills based on the property, not the customer. When a homeowner sells, the bill stays with the address. They don't even collect customer signups: title companies handle that on closing. The RFI requires the CIS to be configurable for premise-based billing in one section, and asks for prior implementation experience in the next.
Most CIS pitches lead with customer experience features. For a sewer district, the customer is barely the entity being billed. The premise is. A vendor that talks about customer journeys without first proving they handle premise-based architecture is signaling they didn't read the RFP.
If your billing model is premise-based, your shortlist should start with vendors who have shipped this in production. It's not a setting you flip on. The data model, the meter-to-cash flow, and the collections logic all change.
2. Multi-utility on one bill is the real test of a billing engine.
The district bills wastewater and stormwater services together. They started stormwater billing in early 2025 and added more than 25,000 new accounts in a single quarter, generating over $1 million per month in new revenue. The RFI explicitly requires CIS proof points for billing both services on one statement.
Adding a new service line in six months tells you what kind of billing engine the buyer needs. If onboarding a new service requires a 9-month custom development cycle, the utility misses windows like this. The buyer's signal in the RFI is direct: the CIS can't be the bottleneck when the next service line gets added.
When evaluating, ask vendors how many service types they've configured for live customers. Ask which were billed on a single statement. Ask what custom code was written for each. The question is not whether customization exists. The question is whether the billing model is already understood, already implemented, and already supportable without turning the CIS into a one-off science project.
3. SOC 2 Type II is table stakes, not a differentiator.
The RFI requires SSAE 18 engagements, with the district noting they prefer Type II reports. It asks for cloud architecture details. The CSS section repeats both requirements.
A few years ago, vendors could win a deal with a SOC 2 Type I and a roadmap to Type II. Today utilities want both reports current and ongoing, and they want it contractually obligated. If a vendor can't produce a current SSAE 18 Type II report on request, they're already out.
The RFI also requires North American headquarters, support staff, and data center locations. That's a hard requirement now, not a procurement preference. Compliance reviews on utility customer data keep tightening, and offshore support models increasingly get flagged. Vendors with US-based teams and infrastructure remove a category of risk that buyers don't want to argue with their boards about.
4. Real-time CIS to CSS integration. Not nightly batch.
The RFI requires the customer self-service portal to integrate with the CIS in real time, not on a scheduled sync. It asks for EBPP integration details and a preferred provider with reasoning.
Most legacy CIS architectures rely on batch sync between billing and the customer-facing portal. A customer makes a payment online, and the CIS sees it 4 to 24 hours later. That model doesn't survive a modern customer interaction. When a customer pays to avoid a shutoff and the CIS doesn't know about it, the operational consequences are real.
When evaluating CSS partners, ask whether the integration to the CIS is API-based and event-driven or batch-and-poll. Ask what happens when the API is unavailable. Ask which EBPP processors are supported, and which are in-house.
5. Track record at similar scale, with the right utility type.
The RFI requires a proven track record at 300,000+ multi-service accounts. It specifically asks for wastewater and stormwater experience. It asks about wastewater billing using water meter data sourced from another utility, which is the operational model of many sewer districts.
Most CIS vendors will claim experience at scale. Few have shipped sewer-district-specific architecture. Even fewer have integrated meter reads from multiple separate water utilities to bill against premise data on a fourth utility's records.
Reference quality matters more than reference count. A vendor with three sewer-district customers in the 200,000 to 500,000 account range is more useful than a vendor with 50 generic municipal references.
What this means if you're writing an RFP
The bigger pattern across these five points: experienced utility CIS buyers don't ask "do you have feature X." They ask "show me the implementation where you shipped X for an organization like ours." The first version is generic. The second forces vendors to either produce a relevant case study or admit they can't.
If you're drafting an RFP for a CIS replacement, look at the questions in a peer district's RFI. They're stricter than most generic templates because they're pre-qualifying out vendors who don't fit before sinking time into a full RFP cycle. That's the right design. RFPs are expensive on both sides.
The vendors who land on the shortlist after a tight RFI like this one are the ones who can answer fast and specifically. The rest go quiet for a week, send a generic capabilities deck, and get filtered out.
If you're working through a CIS evaluation and want to compare what enQuesta CIS has shipped for premise-based, multi-service utility billing at scale, request a demo. 50 years of utility-specific CIS implementations. 250+ communities. The questions in the RFI are the ones we get every week.