What you will learn
- How work orders are created from calls, inspections, and alerts
- What crew dispatch and scheduling need for water fieldwork
- What a field app must do for a crew at a repair site
- How materials, time, and costs are captured per job
- What completion records feed billing, asset history, and reporting
What the project is
A work order is the unit of fieldwork: a main repair, a meter replacement, a valve exercise, a hydrant flush, a leak investigation. It carries a location, a problem description, a priority, an assigned crew, materials used, time spent, and a completion record with photos. The management system moves the order through states, from created to dispatched to in progress to completed, and keeps the history attached to the asset it concerned, so the next crew to visit that main or meter can see what was done before.
The system connects to everything around it: customer calls create orders, leak alerts create orders, inspections create orders, and completed orders feed asset histories, customer notifications, and cost reporting. A work order system that stands alone becomes a second inbox; one that connects becomes the utility's memory of its own network.
Core features
The field app is the feature that decides adoption. A crew that cannot complete a job on a phone in the rain will complete it on paper, and the record will be worse.
- Work order creation from customer calls, inspections, sensor alerts, and planned maintenance, with duplicate detection.
- Prioritisation and scheduling: emergency, urgent, and routine queues, with crew calendars and skill matching.
- Crew dispatch with location, problem details, asset history, and safety notes for the site.
- Field app with offline mode, photo capture, materials logging, and time recording, usable with gloves and wet hands.
- Materials and cost capture per job, including stock drawn, contractor time, and equipment used.
- Completion records with before and after photos, feeding asset history and customer notifications.
- Reporting: backlog, completion times, repeat visits per asset, and cost per job type, for planning and budgeting.
How it is built
Build the field app with crews, not for them. A work order system designed in an office will be redesigned in the field, badly, on paper.
- Work study: ride with crews, list the job types, and learn what information a crew actually needs at the site versus what the office wants afterwards.
- Order model: define job types, states, priorities, and the asset link, and import the asset register the orders will attach to.
- Field app: offline completion, photos, and materials logging, tested with two crews on real jobs before wider rollout.
- Dispatch and reporting: crew scheduling, backlog views, and the reports managers need for planning.
- Integration: connect customer calls, leak alerts, inspections, and outage notifications, so orders are created once, in one place.
Tech considerations
Offline capability and asset linking are the technical core. The scheduling and reporting layers follow from a clean order model.
- Offline-first mobile storage with conflict handling, so two crews updating related jobs do not overwrite each other.
- Asset register integration, so every order attaches to a main, valve, meter, or hydrant with its history.
- Photo capture with compression and location tagging, stored against the order and the asset.
- Scheduling logic for crew calendars, skills, and emergency pre-emption, kept simple enough that dispatchers trust it.
- APIs to customer service, leak detection, and outage systems, so orders flow in from every source without retyping.
Challenges to plan for
Work order systems fail when crews bypass them, when the backlog grows invisible, or when completion records are too thin to be useful.
- Crew bypass: an app that adds taps without saving time will be ignored, and the office will learn about jobs days late.
- Backlog invisibility: a queue that only managers see does not get prioritised, and emergency jobs crowd out planned maintenance silently.
- Thin records: a completed order with no photos, no materials, and no notes cannot answer the next crew's questions or a customer's dispute.
- Duplicate orders: the same break reported by five customers becomes five crews unless duplicates are detected and merged.
Who it is for, and honest limits
This fits water utilities of any size with field crews, from a city department to a rural district with a handful of operators. It fits less well for a utility that contracts all fieldwork to one firm with its own system, where the requirement is a shared job feed rather than a full management platform.
It does not create crews or prioritise politically. It makes the work visible, scheduled, and recorded. If the backlog is larger than crew capacity, the system will show that plainly, which is the evidence for a staffing or contracting decision.
Frequently asked questions
How are duplicate reports handled?
Reports from the same area about the same problem are grouped into one work order, with each reporter linked so they can all receive updates. Grouping should be visible to dispatchers, who can split a group if it turns out to be two problems.
What if a crew has no signal at the site?
The field app works offline and syncs when connectivity returns. Completion records, photos, and materials are stored on the device until sync, so a rural repair is recorded as fully as a city one.
How are emergency jobs prioritised?
Emergency orders pre-empt routine schedules and dispatch to the nearest available crew. The system should show what was displaced by the emergency, so routine work is rescheduled rather than silently dropped.
Does it track contractor work too?
Yes, where contractors are assigned orders and complete them through the same field flow or a contractor portal. Contractor time and materials should be captured the same way as in-house work, or cost comparisons become guesswork.
What feeds asset history?
Every completed order attaches to its asset: the main repaired, the valve exercised, the meter replaced. Over years, that history shows which assets fail repeatedly, which is the evidence for replacement planning.