Municipal Complaint Tracking with Response Deadlines

The problem residents face with local complaints

Reporting a broken street light, an overflowing drain or an uncollected pile of rubbish usually means a phone call into a void, a message in a residents' WhatsApp group, or a visit to an office. There is no reference number, no visible deadline and no way to know whether anyone acted. Departments, in turn, have no clean data on what is reported where, and no way to show when they are doing well.

This applies to city councils, but also to smaller bodies that get little software attention: municipal committees, cantonment boards, housing societies, industrial estates and university campuses with their own estates office.

What already exists and the gap

• FixMyStreet (mySociety, open source) lets people report street problems on a map and sends them to the responsible council, with a public history.
• SeeClickFix (now part of CivicPlus) is a 311 request platform sold to US local governments.
• Open311 is an open standard (GeoReport v2) that lets reporting apps and council back-office systems talk to each other.
• Pakistan Citizen's Portal is a government app, launched in 2018, for lodging complaints with public departments.

These are either national systems or built for councils with IT budgets and back offices. Smaller bodies still run on registers and WhatsApp. None of them put a per category deadline and public overdue statistics at the centre. The gap is a small, self hostable tracker where the clock and the numbers are public by default.

What you build

Three roles:

• Resident: reports a problem, gets a reference number, follows progress.
• Department staff: see their queue, update status, close with a resolution.
• Administrator: manages categories, areas, departments and deadlines.

Main flows: report, route, work, close, and the public statistics page, which should be the front page.

The technically interesting part

Duplicate reports. Twenty people report the same pothole and each becomes a separate case, which distorts every statistic. Before a report is submitted, query open cases within a radius and the same category with PostGIS and ask "is this the same problem?". After submission, cluster reports that slipped through, and let staff merge cases while keeping every reporter informed. Show your supervisor the distance threshold you chose and how you tested it.

Deadlines that mean something. Define exactly when the clock starts and stops (received, acknowledged, resolved, reopened), how weekends are handled, and how reopened cases count. Compute statistics from status history events, never from editable fields, so the numbers cannot be quietly improved.

How to evaluate it

• Pilot: run it for at least three weeks in one real setting such as a housing society or your campus estates office. Report cases, median resolution time and overdue rate.
• Duplicate handling: seed 100 reports with known duplicates and report precision and recall of your matching at two or three thresholds.
• Reporting speed: time five residents submitting a report on a phone; aim under 90 seconds.
• Statistics correctness: unit tests on status histories with reopen and merge cases.

Suggested plan

1. Week 1: interview a department or estates office about categories, deadlines and current process.
2. Weeks 2 to 4: data model, reporting flow, map and routing.
3. Weeks 5 to 7: staff workflow, status history and notifications.
4. Weeks 8 to 10: duplicate detection and the public statistics page.
5. Weeks 11 to 14: pilot, evaluation, write up.

Path to a product

Start with a housing society, private estate or university, where one decision maker can say yes. Charge a small monthly fee per site, or offer it free and charge for setup and support. Municipal bodies buy through slower procurement, so treat them as a later step, supported by an Open311 compatible API that makes the tool easy to plug into larger systems.

Scope warning

Do not build a general workflow engine or a full CRM. Fixed categories, fixed routing rules and fixed deadlines configurable by an administrator are enough. Do not build a native app; a responsive web app with SMS or email updates works.

Learn what you need on Sefism

• Backend roadmap : APIs, databases and background jobs in order.
• Backend cheat sheet : quick reference for the routing and notification logic.
• Django REST Framework : the API layer between your Django models and the React front end.
• PostgreSQL Documentation : indexes and queries behind the statistics page.
• GOV.UK Design System : proven patterns for simple public service forms.

Get help with this idea

This is a good first complete product if a real office uses it during the project. Tauseef can help you define deadlines and statistics, choose a pilot site, and plan an evaluation your examiners will respect. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session