Designing a 311 service request catalog: types, routing, and response times

Reference article · 7 min read

A 311 service request catalog is the list of things a resident can report or ask for, together with everything the system does after they make that choice. The catalog decides which department owns the request, which crew queue it lands in, how urgent it appears, what the resident is told about timing, and which bucket it occupies in every report that follows. It is often handled as a configuration step late in an implementation, after the contract is signed and the interfaces are built. It is closer to a policy decision, and it deserves the attention of the people who own the field work, not only the people who own the software.

Catalog problems are cheap to fix before go-live and expensive afterward, because routing rules, published targets, and historical reporting all hang off the same list. The work below is mostly analysis and negotiation between departments. The system configuration is the easy part once those decisions are settled.

Build the catalog from the work, not from the complaint list

Start with an inventory of what crews actually do. For each candidate request type, write down the department that owns it, the crew or contractor that performs the work, the equipment involved, and whether the work is scheduled or dispatched on demand. If two proposed types resolve to the same crew performing the same task with the same materials, they are one type with an attribute, not two types.

Attributes carry the detail that departments use to justify separate types. A single pothole type with location, lane, and size fields routes better than separate types for arterial, residential, and alley potholes. Attributes are also easier to change later, because they do not carry routing rules and reporting history in the same way a type does.

Test every proposed type against three questions:

• Does it route somewhere different? If the owner, queue, and crew are identical to an existing type, it is an attribute.
• Does it carry a different response expectation? Types that share a target and a workflow can usually share a record.
• Would anyone report on it separately? If no one will ever ask for that number on its own, it does not need to exist as a type.

Why three hundred request types collapse into forty

Long catalogs come from predictable sources. Departments submit wish lists that mirror their internal work order codes. Legacy systems contribute decades of accumulated categories, including duplicates created because someone could not find the existing one. Internal maintenance activities get mixed in with resident-facing requests. Synonyms multiply because different neighborhoods and different departments use different words for the same thing.

Separate the two lists. Internal work order types can stay as detailed as operations needs them to be. The resident-facing catalog should be short enough that a person can scan it without giving up. One internal type can be presented under several resident-facing labels and search aliases, so residents who type the word they know still land in the right place without adding a routable type.

Routing: owner, queue, and default priority

Every type needs three assignments before it goes live.

• One accountable owner department. Shared ownership means no ownership. If two departments genuinely split a type by condition, encode the condition in a rule rather than leaving the assignment ambiguous.
• A named queue, not a named person. Individual assignment breaks the first time someone takes leave. Supervisors assign from the queue.
• A default priority with narrow override rules. Write down who may raise priority and on what basis, and record the reason on the record. Priority that anyone can change for any reason stops meaning anything within a few months.
• A geographic exception layer. Ownership frequently varies by district, maintained-road status, or ownership of the underlying asset. Keep these as rules layered on the type, not as extra types.
• A defined fallback. When no rule matches, the request must land in a monitored queue rather than an unattended one.

Publishing response-time targets crews can meet

Decide first what the clock measures. Acknowledgment, first assessment, and completion are three different commitments, and mixing them is the most common source of disputes about performance. Many agencies publish acknowledgment and assessment targets and describe completion as dependent on scheduling, weather, and material availability.

Set targets from your own historical performance rather than from another jurisdiction's published numbers. Define stop and pause conditions in writing: waiting on a property owner, waiting on a utility locate, waiting on a contractor, seasonal suspension. Decide whether those pauses stop the published clock, and make sure the resident-facing language matches the internal rule. It is better to publish a small number of targets you consistently meet than a full set you miss.

Aging, escalation, and the "other" bucket

Keep a general intake option, but treat it as a triage queue with a named owner and a short review target, not as a category. Nothing should close from that queue without being reclassified to a real type first, which keeps reporting honest and reveals the types you are missing. Review the volume on a regular cycle: a rising count usually means a label is confusing, a type is hidden too deep in the menu, or a genuine new type is needed.

Aging and escalation are different mechanisms. Aging rules change the state of a record based on elapsed time: raising priority, flagging the queue, or notifying a supervisor. Escalation directs human attention to a specific person who is expected to act. Configure both deliberately, and keep the notification volume low enough that supervisors still read the alerts.

Changing the catalog after go-live without breaking history

Retire types, do not delete them. A retired type stops appearing to residents and staff while its historical records remain intact and reportable. Keep stable internal identifiers separate from display labels, so wording can be improved without altering stored records.

Maintain a reporting rollup layer of broad categories that changes rarely, and let type-level detail change underneath it. Trend lines then survive catalog revisions. When a type splits or merges, record an effective-dated mapping so reports spanning the change can be assembled correctly, and note the change in a catalog change log that analysts can consult later.

Handle seasonal work through visibility windows rather than by creating and deleting types each year. A leaf collection or snow-related type that exists year round with a date-controlled display window keeps its identifier, its history, and its routing rules, and it can be opened early when the season arrives.

What to ask vendors and how to start

Put these questions to any vendor during evaluation, and reflect the answers in contract requirements:

• Can a type be retired while its historical records stay reportable, and can effective-dated mappings be defined for splits and merges?
• Are display labels separate from stable identifiers, so relabeling does not rewrite stored records?
• Can agency staff configure types, routing rules, targets, and aging rules without vendor services work or a software release?
• Can one internal type be exposed through multiple resident-facing names and search aliases?
• Can targets vary by type and geography, with documented pause conditions that are reflected in resident-facing status?
• What can be exported in an open format, including the full audit history of type and assignment changes?

To start, inventory the actual work by crew, draft a short resident-facing catalog, and dry run the routing rules against a period of historical request volume before configuring anything. Publish targets only after you have measured what current performance looks like under the definitions you have chosen.

HQT works with state and local agencies on software design, systems engineering, and data work of this kind.

Frequently asked questions