Citizen Service Request Best Practices for Municipalities

Most residents only deal with the public works department when something is broken: a pothole, a street light that is out, water in the basement, a missed trash pickup. How that one request goes has a large effect on what they think of the city. This article covers how to set up the process behind it so residents can see the work your crews are doing.

What residents want when they submit a request

1. Submitting takes less than a minute.
2. They get a confirmation that someone received it.
3. They get a tracking code so they can follow up without explaining the problem again.
4. They hear about it when the status changes.
5. They are told when the work is finished.

A callback, a portal login and a required account are all missing from that list. Residents rarely want any of them. Each account or login step you add costs you some requests and annoys some of the people who get through it.

What a good intake form looks like

Three principles:

• No login required. Tracking codes (for example SR-12A4F8B9) take the place of accounts. Residents can bookmark or save the link that includes the code.
• Fewer fields and sensible defaults. The address field autocompletes as people type, geocodes to a lat/lng and snaps to the nearest known asset, such as a hydrant, manhole or curb cut. Keep the category list short. A 40-item dropdown slows people down.
• Photo early. A photo with EXIF location data tells you more than a 200-word description. Put the photo upload second on the form, not at the bottom.

Add a CAPTCHA and basic IP rate limiting. Any public form needs both in 2026.

Triage as requests come in

In the past, citizen requests went to a supervisor's inbox and waited until that supervisor had time to read, classify and route them. In a small department that could mean hours. In a large one it could mean days.

Many departments now use AI to do a first pass. It reads the title, description and photo, then suggests a category (water main break), a division (Water) and a priority (P1 emergency), and drafts a work order before the supervisor looks at it. The supervisor confirms or corrects it in a couple of clicks. For the obvious cases, the time from request to assignment goes from hours to seconds, and the supervisor has more time for the requests that need a closer look. More on AI in operations here.

Status updates residents receive

The most common problem with citizen request workflows is the long quiet stretch in the middle. A resident submits a request, gets a confirmation and then hears nothing for two weeks. The crew may have finished the job days ago, but nobody told the resident.

Three updates should go out automatically:

• Acknowledged: "We received your request and assigned it to Streets. Tracking code: SR-12A4F8B9."
• In progress: "A crew has been dispatched" or "Work is scheduled for [date]." This goes out when the work order moves to In Progress.
• Resolved: "Work has been completed. If you still see the problem, reply to this email or submit a new request."

Each update goes to the email address or phone number the resident gave and is posted on the public status page for that tracking code. The supervisor does not have to remember to send any of them.

Handling duplicates without losing the resident

When five residents report the same pothole, you want one work order, and you also want each of the five to get their own updates. A linked request setup handles this. The system spots likely duplicates (same address, same category, same week) and groups them under a parent work order. When the parent's status changes, each resident is notified separately. From the resident's side, they get updates on the problem they reported.

What the public status page should show

• Tracking code
• Date submitted
• Current status (Received → Assigned → In Progress → Resolved)
• The most recent public comment (written for residents, not copied from internal notes)
• Address, or the nearest landmark if your privacy policy calls for it

Leave off technician names, internal categories, cost and parts used. Those are operational details and should stay inside the system.

Working with an existing third-party intake

Many cities already use SeeClickFix or a similar intake tool, and there is no need to replace it. Connect it to the CMMS in both directions:

• Requests created in SeeClickFix appear in the CMMS as work orders
• Status changes in the CMMS post back to SeeClickFix as updates
• Residents see the same status in whichever channel they used

Avoid any setup where staff copy and paste between the two systems. Requests get lost that way.

Measuring whether it is working

Three measures cover most of it:

• Time to acknowledgment. Under a minute, since it is automated.
• Time to first status update. Under one business day.
• Time to resolution. Track it by category and look into the outliers.

Publish the first two on the public status page. Residents trust the process more when they can see the city meeting its own targets.

---

WorkmanIQ includes a citizen portal, AI triage and two-way SeeClickFix integration in the base platform. See the platform →