Most councils are good at fixing potholes. Fewer are good at telling the resident who reported it. The gap is usually not the crew. It is the space between the request system and the works system. This post follows one report from a resident's phone to a closed work order, and shows where the loop breaks and how to close it. It also says plainly what Localtech Eye does today, and what is still in development.
The loop, in one picture
A closed loop has seven steps:
- A resident reports a problem.
- The report becomes a customer request.
- The council assigns the request.
- The request becomes a work order.
- The crew does the work and records the cost.
- The council closes the work order and the request.
- The resident hears that the job is done.
Every council does steps 1 and 5. The other steps are where the loop breaks.
Where the loop breaks
Between the report and the request
If the report arrives by phone or email, someone types it into the request system. Details get lost: the photo stays in the inbox, and the location becomes "near the park". When the team is busy, reports wait in the inbox.
Between the request and the work order
In many councils, the request system and the works system are separate. A supervisor reads the request and creates a job somewhere else, or adds it to a list for the crew. Now there are two records, and nothing links them.
Between the work order and the resident
The crew finishes the job and closes the work order. But the request is in another system, so it stays open. Or somebody closes it weeks later in a batch. Nobody tells the resident. The resident calls to ask, or reports the same problem again.
Closing the loop: step by step
1. Capture a complete report
The loop starts with a report that a crew can act on. That means a category, an exact location, photos, the time and the resident's contact details. A reporting app can capture all five at once.
Localtech Eye captures them in about two minutes. The resident picks the problem from the council's own list, adds up to five photos, and drops a pin that the app checks against the council boundary. The report goes with the resident's name and contact details. Today, councils receive Localtech Eye reports by email, with the photos, the map point, the address and the resident's contact details.
2. Land it as a request, with no retyping
The report should arrive in the council's system as a customer request, with every detail attached, so nobody retypes it. With Localtech Core (in development): the Customer Requests module will receive Eye reports this way, with the photos, map pin, address and the resident's contact details. The module is not available yet.
3. Assign it to the right person
In a good request system, routing rules send each request to the right team by category and area. A supervisor then assigns it to a field employee or a crew. Open requests show on a map and in a list, so staff can spot repeats, merge duplicates and see what is near a job already planned.
4. Turn the request into a work order
This is the step that matters most. When requests and works share one ERP, a supervisor can turn a request into a work order in one action. The work order keeps the link to the request. Labour, plant and materials are costed to the job and to the asset. This is the flow planned for Localtech Core (in development).
Now the council knows what the job cost, which asset it was on, and which request started it. Next time someone reports the same spot, staff can see the history.
5. Close the request when the job is done
When the crew finishes, staff close the request. Because the request and the work order are linked, there is one history of the job, not two.
6. Tell the resident
The resident should hear when the request is received, scheduled, in progress and completed. Then the resident does not need to call, and customer service takes fewer follow-up calls. With Localtech Core (in development): residents will see these status updates in Eye. Today, the council contacts the resident directly.
What the council gains
Time. No retyping, and fewer "what happened to my report?" calls.
Cost data. The cost of each type of request, by area and by asset, is visible because every request links to a costed work order.
Better answers for councillors. Response and completion times by category, area and team are ready for councillors and the annual report.
Trust. Residents who hear back are more likely to report the next problem, and less likely to report the same one three times.
What Localtech Eye does today
A council does not need Localtech Core to receive Localtech Eye reports. Today, councils receive Localtech Eye reports by email, with the photos, the map point, the address and the resident's contact details. The council then contacts the resident directly.
That closes part of the loop: the report is complete, and staff can reply. The rest of the loop, from request to work order and back to the resident, needs the request and the work order in one system. For the bigger picture of what a council ERP does, read ERP for local government: from report to work order.
Where it is available
Localtech Eye is live for Queensland councils. New Zealand, the United Kingdom, the United States and Canada are now taking councils, with no resident service there yet. See Australia and New Zealand.
See the loop with your council's data
The best way to judge the loop is to watch it. Book a demo and we will send a report from a phone and show you what your team receives. We will also talk you through the plans for Localtech Core. More detail is on the page for councils.