Every complaint tied to the right meter.
A low-pressure complaint, a new connection or a disputed bill can pass through a call desk, a section office and a field crew before anyone tells the customer what happened. We build request and field software around those handoffs.
Requests that bounce between desks.
Dozens of calls about one burst main.
A pipe fails overnight and the call desk logs every caller separately. Without a way to group them under one incident, crews get duplicate tickets and customers hear different answers.
The application waits on a site visit.
An applicant uploads property papers, pays the fee and waits. The section office needs a feasibility visit booked, the result recorded and the applicant told what is still missing.
The reading looks wrong.
A customer disputes a high bill. A meter reader rechecks, photographs the meter and takes a fresh reading. Billing needs that evidence on the dispute itself, not in a staff chat group.
Back at the same address.
A crew is sent to a leak it repaired last month. If the history sits against the account and service point, the crew arrives knowing what was done before.
Log it, route it, fix it, tell them.
Capture it against a record
Whether it arrives by phone, a customer portal, WhatsApp or a walk-in, the request is matched to a consumer number, a service point or at least a pin on a map. Anything that can't be matched waits in a queue for a person to resolve instead of being guessed.
Route by area and type
Rules send leaks to the maintenance crew for that zone and connection applications to the section engineer. Supervisors can reassign, and each change is kept.
Close the job in the field
A mobile app shows crews their jobs, the account history and the address. They record what they found, the work done, materials used and photos, even where the network drops.
Update the request and the customer
The field result closes or advances the original request. The customer gets a plain status message, and internal notes stay internal.
Where utility projects go wrong.
Which identifier is the truth?
Accounts, meters, service points and addresses rarely match one to one. A request linked to the wrong one sends a crew to the wrong door and tangles the history, so we map these before anything else.
What will the billing system allow?
Most utilities already run a billing or customer system that is not being replaced. We study what it exposes and build API integrations around it, instead of copying accounts into a second database that slowly drifts.
What may customers see?
A customer should see that a crew is assigned and when the job closed. They should not see internal remarks, other customers' addresses or a lineman's personal number.
What counts as resolved?
Agree the closure codes and who may reopen a request. Any report on response times is only as honest as those definitions.
We would not start with every request type. Picture a city water supplier whose biggest pain is leak and supply complaints: the first release would cover that one category, from intake to field closure, for two or three zones. Once crews trust the app and supervisors trust the queue, new connections, billing disputes and meter replacements can follow on the same record.
Field conditions shape the design as much as office rules do. Crews work in rain, in basements and on roadsides, often with gloves and poor signal, so screens stay short, photos upload in the background and nothing is lost if the phone goes offline for an hour.
Systems we would expect to connect.
Bring us a request that went in circles.
Describe how one complaint travelled through your teams and we will show where software would shorten its path.