WATER SERVICE PROVIDERS · GUIDE 02
A requirements checklist for water and sanitation service providers.
Most comparisons of utility software start from a feature list, and most of them end badly. Every product demonstrates well on a prepared dataset in a meeting room with reliable power and a stable connection. The provider then discovers, three months in, that meter readers cannot work without a signal, that the customer list arrived without connection identifiers, and that the export the board asked for costs extra.
A better comparison starts from the work the provider already does each month and tests whether each option supports that work under the conditions staff actually face. This guide gives a checklist, a way to run demonstrations that reveal something, and a method for comparing cost over the life of the system rather than at the point of purchase.
Write down the three to five routines the system has to carry from beginning to end. Most water providers land on a similar set.
Describe who performs each routine, on what device, and under what conditions. Record how long the routine takes today and where it fails. These become the scenarios every option is tested against, and they keep the evaluation anchored to work rather than to features.
Separate essential requirements from desirable ones before any demonstration begins. An essential requirement is one the provider cannot operate without or cannot lawfully omit. Agreeing this early prevents a strong demonstration of a desirable feature from outweighing a failure on an essential one.
For every requirement below, record its priority, the evidence demonstrated, any limitation found, and the cost of meeting it. Where the provider reports to a regulator, confirm the reporting requirements before assessing anything else, because they are rarely negotiable.
These four requirements decide whether the system can run a billing cycle without a parallel spreadsheet.
These four requirements decide whether the system supports the operational half of the business rather than the commercial half alone.
These five requirements decide whether the provider still controls its own information in five years.
Give every supplier the same anonymized extract of the provider's own data and the same tasks. A demonstration on the supplier's sample data proves only that the supplier can prepare sample data.
A practical billing cycle test
Run these seven steps in order, with the same customer extract, on every system under consideration.
Include the awkward cases. What happens when a meter is replaced mid-cycle, when a tenant changes, when two readers visit the same customer, or when a reading is lower than the one before it? These situations occur every month, and they separate systems that were designed for utility work from systems that were adapted to it.
Record which capabilities exist now, which require configuration, and which depend on new development. Note the cost, timeline, and responsible party for anything not yet built.
Use the same period and the same assumptions for every option. Five years fits most providers' planning horizons and is long enough for the recurring costs to dominate.
Include in the comparison
A realistic figure covers nine lines, and the software license is only one of them.
State the assumptions about customer growth, staff numbers, and geographic expansion, then ask each supplier how the cost changes if those assumptions change. A price that holds only at today's customer count is not a five-year price.
The mWater platform is free to use, including unlimited users, data collection, storage, and export. Implementation and support services are paid and optional. A provider evaluating mWater should still budget for staff time, devices, connectivity, training, and administration, because those costs exist whichever system is chosen.
Agree the weights before the demonstrations are reviewed, and record the evidence next to each score so the reasoning stays visible to whoever reads the decision later.
Essential requirements are assessed separately
Score mandatory requirements on their own. A strong total should never conceal a failure on something the provider cannot operate without. Keep capabilities that were demonstrated separate from capabilities that were described.
Before any wider rollout, run the shortlisted system on a single meter reading route for one full billing cycle, with the staff who will operate it.
Choose a route that exposes the real conditions: weak connectivity, older meters, a mix of customer types, and at least one known data problem. A pilot on the best route proves the least.
Agree acceptance criteria in advance. Reasonable ones are a complete reading round, bills that reconcile with the previous cycle, arrears that match the manual ledger, and a member of provider staff completing routine administration without help.
Record what assistance users needed. That record sets the training and support the wider rollout will require, and it is usually the most accurate cost estimate the provider will produce.
For each requirement, capture priority, weight, score, evidence, limitations, additional cost, the person responsible, and the date of acceptance.
Keep one record per supplier, using identical requirements and identical scoring rules, so the comparison survives scrutiny from a board or a funder.
Providers evaluating mWater can test customer management, billing, meter reading, asset records, offline fieldwork, permissions, and export against the checklist above, on a free account, with their own data.
This guide covers the decision. The others cover the category, the records, lost revenue, and the first month of operation.
mWater · Water service provider series