#502 Farenheit 311 - Ottawa's Funky Trouble System

Ward 13 · Rideau-Rockcliffe Civic accountability notes

What 311 Data Can (and Can't) Tell You About Ottawa

The system doesn't need a new app. It needs its own data to mean what it says.

Ottawa's 311 — Service Ottawa, run through myservice.ottawa.ca and the ServiceOttawa app — works fine as a way to file a complaint. Call, click, or tap, and a ticket gets created. What it doesn't do well is function as a record the public can actually trust. That distinction matters more than it sounds, because 311 isn't just a complaint line. It's supposed to be the city's most granular, most current dataset on where things are broken and how fast the city fixes them. Right now it can't reliably do that job.

The gap isn't a technology problem. It's an information management problem — the kind that gets missed because it's boring, and because "we have an open data portal" sounds like transparency even when the data inside it doesn't hold up.

The core problem

When a large batch of tickets closes on the same date without differentiated resolution codes, the closure timestamp stops meaning "this got fixed" and starts meaning "this got cleared." Anyone using that data to measure response time — a resident, a journalist, a councillor — gets a false read on how the city is actually performing.

Where the system breaks down

1. Status is binary when it shouldn't be My ServiceOttawa shows only "Open" or "Closed." There's no assigned, dispatched, or in-progress state — so a resident can't tell the difference between "nobody has looked at this yet" and "a crew is scheduled for next week." Cities running proper Open311 implementations expose that granularity because the backend already tracks it. Ottawa's doesn't surface it.
2. Closure codes don't distinguish outcomes "Resolved," "duplicate," "referred to another agency," and "administratively closed" all collapse into the same "Closed" flag. Without that distinction, every downstream metric built on the open data — average time-to-resolution, ward-level comparisons, SLA compliance — is unreliable at the source.
3. No link between a ticket and the project already addressing it File a pothole complaint on a street that's slated for reconstruction next year, and 311 has no way to tell you that. The resident gets a ticket instead of an answer, and the city gets a redundant complaint it has to process anyway.
4. Categories follow the org chart, not the problem A flooding complaint often touches roads, stormwater, and forestry root intrusion at once, but the intake taxonomy assumes one department owns it. The reassignment loops that follow don't show up anywhere in the public data — they just show up as delay.
5. Nobody publishes the accountability loop The raw monthly data dumps exist. A standing dashboard that turns them into resolution-time-by-category-by-ward — the thing that would let council or the public actually monitor performance — doesn't.

What would actually fix it

None of this requires a new platform. It requires the city to treat its own operational data with the same discipline it would demand of any other system of record — and most of it is a backend and API decision, not new infrastructure.

1. Fix closure-code granularity first The cheapest, highest-leverage change. It's a field-mapping problem, not a new build, and it's the one fix that restores trust in every dataset downstream of it.
2. Expose the intermediate status states The backend almost certainly already tracks assigned, dispatched, and in-progress. Show them.
3. Publish a standing resolution-time dashboard By category and by ward, refreshed on the same cadence as the existing monthly data, so there's a real feedback loop instead of a CSV nobody parses.
4. Link tickets to capital and maintenance project records geospatially Tell residents when their street is already scheduled, instead of silently collecting a duplicate complaint. This is the change that actually reduces call volume — it's an efficiency argument as much as a transparency one.
5. Audit the data the way you'd audit any CRM Bulk-closure incidents, category-reassignment rates, duplicate-ticket rates — publish it annually. Right now nothing forces the system's own data quality to be checked at all.

The fix here is backend data discipline applied to the system Ottawa already has — not a new app. That's a harder story to sell at a ribbon-cutting, and it's the one that would actually change what residents can trust when they file a ticket.

This is the same pattern that shows up across most of what I write about city hall: the gap is rarely a missing tool. It's a missing discipline around the tools that already exist — and no one's job is to close that gap unless a councillor makes it their job.

Peter Karwacki — Candidate, Ward 13 (Rideau-Rockcliffe)
peterkarwacki.blogspot.com