Closing the loop between 311 requests and public works work orders

Reference article · 6 min read

A resident reports a pothole through a web form, a phone call to the call center, or a mobile app. Downstream, a supervisor assigns the repair, a crew goes out, and the hole gets filled. In many agencies those two events live in systems bought years apart for different reasons, and the only connection between them is a person retyping information from one screen into another. That holds up until volume rises, until a council office asks why a resident never heard back, or until the person who knew the workarounds retires.

Closing the loop means building a defined, tested path from intake to field completion and back to the resident. The technical work is usually smaller than it looks. The governance work, deciding who owns which field and what a word like "closed" means, is usually larger, and skipping it is what produces integrations that technically pass testing and still frustrate everyone who uses them.

Decide what each system is the record for

Write this down before any code is scoped. The typical split:

• The 311 or CRM system is the record for the request. Who reported it, how they want to be contacted, the narrative in their words, which duplicate reports were merged into it, and the status shown to the public.
• The work order or asset management system is the record for the work. Crew assignment, labor and equipment hours, materials, the asset touched, condition after the work, and cost.

Every shared field needs exactly one writer and one or more readers. Status is where this usually breaks, because both systems have a status field and both vendors assume theirs is authoritative. A workable default is that the work system owns operational status and the request system derives a resident-facing status from it, never the reverse. Put the rule in an interface control document that both vendors and your staff can read.

Match the request to a location and an asset

Intake produces an address, a dropped pin, or a description. Crews work from asset IDs and centerlines. The integration has to bridge that.

• Geocode at intake against your own authoritative address points and street centerline layer, not a generic public geocoder, so the result lands in the same coordinate space the work system uses.
• Where the request type implies a known asset, such as a streetlight, hydrant, catch basin, or traffic sign, offer the resident a way to identify it and carry that ID through. Otherwise pass a point plus a short list of nearby candidate assets and let the dispatcher confirm.
• Keep the resident's original reported location and the resolved location as separate fields. Overwriting the first destroys your ability to audit bad matches later.
• Decide the rules for right of way versus private property, and for roads or facilities inside your boundary that another jurisdiction maintains. Those requests need a documented referral path and a resident-facing status that says so honestly.
• Maintain the mapping from service request type to work order type as configurable data, not as logic buried in the interface. It will change every budget cycle.

Translate status vocabularies deliberately

Crews need operational granularity: assigned, dispatched, parts on order, deferred for weather, referred to contractor, needs engineering review. Residents need a short, stable set: received, under review, scheduled, completed, closed with no action taken, referred elsewhere.

Build an explicit many-to-one mapping between them, include a default for any value that is not mapped, and never display raw internal codes on a public page. Pay particular attention to "closed." To a crew it means the work order is done. To a resident it means the problem is gone. Separate the resolution codes so the notification can be accurate: repaired, inspected and no defect found, not our jurisdiction, duplicate of an earlier request, or scheduled into a future capital project.

Make completion flow back automatically

When a crew closes the work order in the field, the integration should carry the completion timestamp, the resolution code, any resident-safe notes, and optionally a photo back to the request, close it, and trigger notification on the channel the resident chose. Three cases deserve design attention:

1. One work order, many requests. A block resurfacing may answer dozens of reports. Closure has to fan out to every linked request.
2. Reopening. If a resident responds or files again at the same location within a defined window, link the new report to the old one rather than starting a fresh, unrelated case.
3. Backfill. The first sync after go-live can fire a large batch of stale notifications. Suppress notifications for records older than a cutoff you choose in advance.

Design against the common failure modes

• Duplicate entry. If dispatchers still retype requests into the work system, the integration is not finished, regardless of what the status report says. Measure how often it happens.
• Divergent closure. A one-way interface eventually leaves requests open in 311 that were finished months ago in the field. Run a nightly reconciliation that compares linked pairs and produces an exception list a named person reviews.
• Silent failure. Require queuing, retries, and a dead-letter destination. An interface that drops messages quietly is worse than no interface, because staff stop checking.
• Attachments. Photos are the most common payload and the most common cause of size and timeout errors. Test them with real field images, not small samples.

What to ask for before you buy

• Ask each vendor for current API documentation at the field level, including authentication, rate limits, whether events are pushed or polled, and whether a sandbox environment is available to your staff and your integrator.
• Ask whether the product supports Open311 GeoReport, an open specification for service request exchange that some 311 platforms implement. Support varies by product and version, so confirm the specifics rather than relying on a checkbox in a response.
• Require that your staff can change type mappings, status mappings, and notification text without a vendor change order.
• Make an interface control document, a field-level mapping, and test cases covering reopen, duplicate merge, multi-request closure, and cross-jurisdiction referral into contract deliverables, and tie a payment milestone to their acceptance.
• Confirm in writing that integration traffic does not carry per-transaction fees, and that you can export your own request and work order data in bulk.

Start with one or two high-volume request types, run them end to end including notifications, and expand only after reconciliation comes back clean for several weeks.

HQT works with state and local agencies on systems engineering and integration between resident-facing and operational systems.

Frequently asked questions