Designing a citizen reporting system from scratch
What questions did we ask while designing CityOS's reporting module? Three points where municipal workflows tend to break, and the answers we built.
Citizen reporting is one of the most visible service metrics for a municipality — and usually one of the weakest operationally. Call center, social media, mobile app: each channel tends to live in its own silo.
When designing CityOS's reporting module, we set out to solve three core problems.
1. A unified queue
Which channel a citizen used — phone, mobile app, web — should be a detail the assignee doesn't have to think about. CityOS pipes every channel into one queue; the assigned report looks the same regardless of source.
2. Auto-classification, but overridable
Whether a report is "park maintenance" or "road maintenance" is obvious in roughly 80% of cases. The remaining 20% needs a human.
CityOS auto-classifies the incoming report, but the assignee can always change the category. That small detail — "AI suggested it, but you have the final say" — dramatically increases acceptance.
3. Live updates for the citizen
When the internal process completes, push notifications are the fastest way to tell the citizen. But which step should we notify? Assigned, in-progress, completed?
Three pilot municipalities tested it and the result was clear: a single notification — "Your report is complete" — produced higher satisfaction than multiple updates. Notifying every step felt like nagging.
The invisible part: GDPR/KVKK
Separating identity from report content, enabling audit log from day one, and minimizing personal data — all standard. This is the most expensive layer to add later.
Takeaway
A reporting system requires far more decisions than it appears to. CityOS's module is a concrete application of the less clicking, more clarity principle.