Touchpoints logo Touchpoints

311 & Open311 · A field guide

Many doors.
One loop.

Residents reach their city through a dozen doors: a phone call, a web form, a photo, an email, a word at the counter. Most cities treat what comes through as tickets to close. This guide treats it as a signal to learn from.

311 isn't a call center. It's how a city senses what is happening on its streets, acts on it, and tells people what it did. Built well, it's the most direct feedback loop a local government has.

See the loop Skip to the how-to

The picture

From many doors to one loop

Every channel feeds one inbox. Every request then moves through the same five stages, in the same order, whichever door it came through. The sixth stage is the one most cities skip, and it decides whether next year looks any different.

Many doors, one loop Nine ways residents reach a city — phone, web, photo with a map pin, email, the front counter, a council office, social media, a park sign, and Open311 apps — all funnel into one inbox. Each request then moves through five stages: capture, clarify, organize, engage, and close the loop. Clarify hands requests that belong to another agency to their owner and merges duplicates. The loop ends with the request resolved, the resident informed, and trust earned. A sixth stage, reflect, feeds what the city learns back to the start, so fixing services upstream makes the doors quieter. Many doors One loop Good outcomes Phone call Web form Photo + map pin Email Front counter Council office Social post Park sign URL Open311 apps one front door Capture 1 Every door lands in one inbox, with a receipt. Clarify 2 Organize 3 Route to the owning team's process model. Engage 4 Work one queue; each step is timestamped. Close the loop 5 Status on demand; a notice when done. Not ours? Hand it to the county, state, or utility — and say who has it. Seen it already? Merge duplicates, but keep every reporter in the loop. Parks Streets Code Request resolved Resident informed Trust earned 6 Reflect: which requests shouldn't exist? Fix the service upstream.
The stage names borrow from David Allen's Getting Things Done: capture, clarify, organize, engage, reflect. The loop is the same; here it runs across a whole city rather than one person's desk.

The argument

311 is a cybernetic capability

Cybernetics is the study of how systems steer themselves through feedback. Three of its ideas explain why some 311 programs build trust and others become complaint boxes.

Requisite variety

W. Ross Ashby, 1956

A city faces more kinds of problems than any department can anticipate. Only variety can absorb variety. 311 lets a small staff match a large city: it sorts each signal to whoever can absorb it, and categories filter out the noise.

The good regulator

Conant & Ashby, 1970

Every good regulator of a system must be a model of that system. Your request workflow already is a model of how the city responds; usually it lives in people's heads and inboxes. Write it down as a process model, run requests through it, and the model gets better because the data shows where it is wrong.

Algedonic signals

Stafford Beer, 1972

Beer called pain-and-pleasure signals that skip the chain of command algedonic. Twelve reports about one intersection in a week are the city feeling pain. A good 311 routes that pain to someone who can act, and escalates it when it repeats.

Beer also imagined a "cyberfolk": residents linked into governance by real-time feedback. The aim was to keep the people who report, the people who do the work, and the people who set policy in the same loop, without centralizing control. A well-run 311 is a modest, practical version of that idea. It needs no new institution, only a loop that closes.

The how-to

Six moves, in order

Each move is something your staff do, whatever software you run. Under each one, the last line says how Touchpoints supports it today.

  1. 1

    Capture

    Every door leads to one inbox, and every request gets a receipt.

    • Publish one short web address on signs, the city website, and staff scripts.
    • Have phone and counter staff enter requests on the same form residents use.
    • Ask for a photo and a map pin rather than a typed address.

    Avoid: a separate inbox for each department. A request nobody owns is a request lost.

    In Touchpoints: a public report form with photo upload and a map pin; every submission is issued a receipt token.

  2. 2

    Clarify

    Answer three questions before anyone is assigned: what is it, where is it, and is it ours?

    • When it isn't yours, tell the resident who owns it and pass it along.
    • Merge duplicates, but keep every reporter attached so everyone hears the outcome.
    • Answer simple questions directly; not every request needs a work order.

    Avoid: closing "not ours" requests without a word. To the resident, the city simply didn't answer.

    In Touchpoints: requests store real latitude and longitude, so location rules and maps work on clean data.

  3. 3

    Organize

    Route each category to an owner who follows a written process.

    • Start with three to five categories, named the way residents describe problems.
    • Give every category one owning team.
    • Begin with route, assign, work, resolve, notify. It is enough.

    Avoid: categories that mirror the org chart. Residents don't know which division fixes a sidewalk.

    In Touchpoints: each category's process is a BPMN model that actually runs. Change the diagram and the workflow changes.

  4. 4

    Engage

    Do the work from one queue and record it as it happens.

    • Set a response target for each category, then watch it.
    • Update the status when it changes, not at the end of the week.
    • Let crews mark progress from the field.

    Avoid: work that happens in side emails and spreadsheets. The data leaves with it.

    In Touchpoints: the workflow engine records when each step starts and finishes, for every request.

  5. 5

    Close the loop

    Tell people what happened. This is the single most trust-building thing a 311 can do.

    • Give every reporter a way to check status without calling.
    • When it's done, say so, and say what was done.
    • When you won't fix it, say why.

    Avoid: "closed" without a word to the person who asked.

    In Touchpoints: each request's status can be looked up by its receipt token through the Open311 API.

  6. 6

    Reflect

    Each quarter, ask which requests shouldn't have been needed, then fix the service upstream.

    • Separate failure demand, requests caused by a service not working, from value demand.
    • Link request volume to the process step that generated it.
    • Publish a short State of Service report and act on one finding.

    Avoid: judging the program by tickets closed. A busier 311 is not a better city.

    In Touchpoints: because requests run on the process model, cycle time and step-by-step dwell time come straight from the workflow record.

The standard

Open311: the city's requests, in an open format

Open311 GeoReport v2 is an open API standard for service requests, built by the civic technology community. It defines what a service is, what a request is, and how to file one or check on one.

It matters for three reasons. Your data stays yours, in a format any vendor can read. Resident-facing apps can file straight into your queue. And standard data makes it possible to compare cities fairly: how long a pothole takes here, compared with places like here.

Touchpoints implements GeoReport v2 in both JSON and XML. Request IDs can't be guessed, and public submissions are rate-limited.

/open311/v2
GET /services.json What residents can request
GET /services/:code.json Fields one service asks for
POST /requests.json File a request
GET /requests.json Recent requests
GET /requests/:id.json One request's status
GET /tokens/:token.json Look up a request by receipt

What to measure

Count what the loop is telling you, not only the tickets you closed

Counting closed tickets rewards closing tickets. These measures show whether the loop is working and where the service is failing.

Measure What it tells you
Failure-demand share How many requests exist only because a service failed somewhere upstream. This is the number to shrink.
Loop-closure rate The share of resolved requests where the reporter was told. This builds trust more directly than speed.
Time to first response How long a resident waits before learning a person has seen their request.
Step dwell time Where requests wait inside the process, and which handoff is the bottleneck.
Repeat reports The same problem at the same place, reported again: a sign the fix didn't hold.
Channel mix Which doors residents actually use, and which ones staff still have to re-key.

Getting started

Start with 90 days and three categories

You don't need a phone center, per-seat licenses, or a capital project. You need one front door, a few categories with named owners, and a promise to tell people what happened.

Weeks 1–2

Set up

Choose the categories with staff, name an owner for each, and configure the channel and its default workflow.

Weeks 3–10

Live

Open the front door, put signs in a park or two, and check in weekly while staff learn the queue.

Weeks 11–12

Reflect

Deliver a State of Service report: volumes, resolution times, the loop-closure rate, and one process change to make.

Talk about a pilot How workflows run Service design analytics