A systems-focused redesign of Bengaluru's official civic complaint platform.
A complaint journey redesigned around visibility, verification, and accountability.
Sahaaya 2.0 is an official civic complaint app used by Bangalore residents to report local issues like potholes, garbage pile-ups, and failed streetlights.
Users submit a complaint by selecting an issue type, and the platform routes the ticket to the assigned department or official.
Backend operational workflows and external department schedules cannot be modified by the interface.
After filing a report, citizens often have no visibility into administrative progress or assignment detail.
To test the system firsthand, I submitted a report for irregular garbage accumulation in Indiranagar. The initial submission went smoothly—I immediately received a ticket ID and contact details for the assigned field officer.
However, immediately after submission, operational transparency vanished. The interface provided no timelines, progress logs, or milestone estimates. Following up on the ticket's future depended entirely on calling the representative's personal mobile phone directly.
If complaints could already be submitted successfully, why were so many citizens frustrated?
To verify if my experience was isolated, I audited Play Store reviews, city subreddits, and BBMP grievance files.
“The complaint often gets marked as done. what a joke!”
“I've complained a garbage issue in Whitefield, the ticket was closed without cleaning up.”
“How is one supposed to know what dept acronym is for what.”
Users knew their complaint existed but struggled to find who held responsibility, what actions were scheduled, or whether anyone was actively addressing the issue.
Complaints were frequently closed and marked "resolved" on municipal records without giving citizens any prior notification or visual confirmation mechanism.
When assignments stalled, citizens lacked system-mediated pathways to raise attention or escalate delays—leaving them forced to endure endless delays.
The problem was not complaint submission.
The system successfully collected complaints.
The breakdown occurred afterwards — when citizens lost visibility, trust, and agency.
Status and timeline in one place.
Proof of work visibility.
Escalation from the same screen.
Latest update on the issue.
See before/after proof before accepting resolution.
Reject closures when work isn’t actually done.
Prevent false “resolved” states from closing complaints.
Shift control from system → citizen.
Recognize when system has stalled.
Exit the app to contact BBMP directly.
Escalate publicly if needed (social media).
Continue the resolution outside the system.
Complaint inactivity is surfaced instead of hidden.
Escalation becomes part of the primary workflow.
Closure requires citizen confirmation before completion.
The final solution emerged after challenging several early assumptions about accountability, trust, and complaint resolution.
The problem was complaint submission.
Submitting complaints was not the primary failure. The system already allowed complaints to be filed successfully.
The redesign focused on what happens after submission: visibility, accountability, and resolution tracking.
More status updates would improve trust.
Users did not need more notifications. They needed evidence that work was actually happening.
Proof of work, ownership visibility, and progress timelines became more important than update frequency.
Resolution should be controlled entirely by departments.
Issues could be marked resolved without giving citizens a way to verify the outcome.
Citizen confirmation became a required step before final closure.
Escalation was an edge case.
Many complaints stall because operational processes break down after assignment.
Escalation became part of the primary workflow rather than a hidden fallback action.
Officials can still upload inaccurate or misleading proof.
Citizens can review evidence, reject closure, and trigger further escalation.
Service speed depends on field teams, contractors, and department execution.
Delays become visible through timelines, ownership records, and escalation triggers.
The platform only works when departments actively participate and update records.
Users retain visibility and alternative escalation paths even when updates stop.
The issue wasn't submitting complaints. It was everything that happened after. No visibility, no proof, and no agency.
Clarity comes from showing what's actually happening. Trust comes from proof, not just status. Control matters when users can act.
From passive reporting → active resolution. Users can trace accountability, verify work, and enforce SLAs directly.
.png)
.png)
