Society Complaint Management Done Right: Best Practices for Faster, Fairer Resolution

Society Complaint Management Done Right: Best Practices for Faster, Fairer Resolution

By MyKutir Editorial Team — 2026-08-05

Complaints are the emotional core of society life, and most die in WhatsApp groups. These best practices — ticketing, SLAs, ownership and escalation — turn grievances into problems that actually get fixed.

Every residential society runs on a quiet, continuous stream of problems. A tap leaks. A corridor light fails. The lift jerks. A neighbour's dog barks all night. The garbage was not collected. Individually, none of these is a crisis. Collectively, how a society handles them is the single biggest driver of whether residents feel looked after or ignored. A society can have beautiful gardens and a state-of-the-art gym, but if a resident's complaint about a broken flush vanishes into a WhatsApp group and dies there, that resident will tell you the management is useless.

Complaint management is, in other words, the emotional core of community operations. And most societies do it badly — not because they do not care, but because they treat complaints as messages to be answered rather than as a process to be run. This guide lays out the best practices that separate societies where problems get fixed from societies where problems get forgotten. It is aimed at committee members, managers, and anyone who has ever watched a genuine grievance evaporate in a group chat.

Why WhatsApp is where complaints go to die

Let us start by being honest about the default tool. The vast majority of Indian societies handle complaints through a WhatsApp group. It feels convenient, but it is structurally incapable of managing complaints, and here is why:

A complaint deserves to be a tracked object with an identity, an owner, a status, and a deadline — not a message. Everything that follows is about turning grievances into managed items instead of fleeting texts.

Best practice 1 — Give every complaint a ticket

The foundational shift is ticketing. The moment a resident raises an issue, it should become a numbered ticket that exists independently of any chat. That ticket carries:

MyKutir's complaint module works exactly this way: each complaint gets a unique ticket number, a category, a priority, optional photos, and a status that progresses through its lifecycle. The resident can see their own tickets and their current state, which alone eliminates the most corrosive feeling in society life — the sense that your problem disappeared into a void. You can see how the broader operations picture fits together on the features overview.

Photos change everything

A small but disproportionately useful practice: let residents attach photos when they raise a complaint. "The ceiling is leaking" and a photo of a brown water stain spreading across the plaster are two very different pieces of information. The photo lets whoever triages the ticket judge urgency correctly and often lets the assigned worker arrive with the right tools the first time.

Best practice 2 — Categorise and prioritise deliberately

Not all complaints are equal, and pretending they are is how urgent issues wait behind trivial ones. Two dimensions matter:

Category routes the complaint to the right responder. A plumbing ticket should reach the plumber or the manager who deals with plumbing; a security concern should reach the security supervisor. Categorisation is what makes routing possible.

Priority determines the order of attention. A sensible three or four-level scheme works for most societies:

PriorityTypical examplesExpectation
Urgent / HighBurst pipe, lift trapping, electrical hazard, security threatImmediate response, same-day action
MediumLeaking tap, corridor light out, intercom faultResolved within a day or two
LowCosmetic repairs, hedge trimming, minor requestsScheduled into routine maintenance

When each ticket carries a category and a priority, the person managing complaints can look at a clean list and know instantly what needs attention now versus what can wait — instead of scrolling a chat trying to remember what was said.

Best practice 3 — Assign an owner to every ticket

A complaint with no owner is a complaint no one will fix. The discipline is simple: every ticket gets assigned to a specific person — a staff member, a manager, or a committee member — who is responsible for driving it to resolution. Assignment converts a vague collective obligation into an individual one.

In a proper system, a ticket can be assigned to a responder, and that assignment is visible. The resident knows someone owns their issue; the committee knows who to ask about it; and the assigned person knows it is on their plate. This single practice — moving from "someone should look at this" to "you are responsible for this" — resolves more complaints than any other change a society can make.

Best practice 4 — Set SLAs so "soon" has a definition

Here is the heart of professional complaint management: the Service Level Agreement, or SLA. An SLA is simply a committed timeframe — "complaints of this category and priority will be resolved within X hours." It replaces the elastic word "soon" with a number everyone can hold each other to.

Why does this matter so much? Because without a deadline, a complaint has no natural pressure to be resolved. It can sit for a week and nobody has technically failed. With an SLA, the clock is running, and a breach is visible. The society moves from hoping things get done to expecting them to.

MyKutir lets a society configure SLA rules per category and priority — a target resolution time, and an escalation window after which an unresolved ticket is bumped up. So a high-priority plumbing complaint might carry a tight SLA, while a low-priority cosmetic request carries a relaxed one. The system tracks the clock against each ticket automatically, so the committee is not manually watching deadlines.

Set SLAs you can actually meet

A word of caution: an SLA you routinely miss is worse than no SLA, because it trains residents to distrust your commitments. Set targets that reflect your real capacity — your staffing, your vendor response times, your budget — and tighten them as you improve. An honest 48-hour promise you keep beats an aspirational 4-hour promise you break.

Best practice 5 — Escalate automatically, not emotionally

What happens when a ticket blows past its SLA? In a WhatsApp world, escalation means the resident gets angry and starts tagging committee members in the group, which is stressful for everyone and often unfair to the one person who happened to see the message. Professional escalation is different: it is automatic, rule-based, and unemotional.

The idea is that when a ticket crosses its escalation window unresolved, it is automatically flagged and routed to a more senior person — from the assigned staff member up to the manager, and from the manager up to the committee. The escalation carries a note and a record, so the senior person picks it up with full context. Nobody had to shout; the process did its job.

Escalation done this way has a second benefit: it surfaces systemic problems. If the same category keeps escalating, the issue is not the individual tickets — it is that your plumber is unreliable or your electrical infrastructure is failing. The pattern is the diagnosis.

Best practice 6 — Keep a complete history on every ticket

Every action on a complaint — who raised it, when it was assigned, each status change, each comment, the escalation, the resolution note — should be recorded on the ticket itself. This history is what makes complaint management fair and defensible.

It matters for three reasons. First, continuity: if the assigned person is on leave, whoever picks up the ticket can see everything that has happened. Second, accountability: at the AGM, when someone claims "my complaints are never addressed," the committee can show the actual record. Third, learning: reviewing resolved tickets reveals which problems recur and where the money should go. A ticket that carries its full comment and status history is an asset; a WhatsApp thread is not.

Best practice 7 — Close the loop with the resident

A complaint is not resolved when the work is done. It is resolved when the resident knows the work is done. The final, frequently skipped step is closing the loop: notify the person who raised it, ideally with a resolution note explaining what was fixed, and let them confirm.

This costs almost nothing and pays enormous dividends in goodwill. A resident who gets a message saying "the corridor light on the 4th floor has been replaced" feels heard even about a trivial issue. A resident who never hears back assumes nothing happened, even when it did. When resolution triggers a notification to the resident automatically, this best practice happens by default instead of depending on someone remembering.

Where AI quietly helps

One modern addition worth mentioning: drafting assistance. Residents often struggle to describe a problem clearly, and staff often struggle to write a professional response. MyKutir includes an AI complaint draft-assist feature that helps turn a rough description into a clear, well-structured complaint, and can help staff phrase updates. This is not the AI "deciding" anything about your complaint — a human still owns and resolves the ticket. It simply lowers the friction of writing, so more issues get reported clearly and responses read professionally. You can read more about the platform's AI capabilities on the AI platform page.

A short illustrative scenario

The following is a made-up illustration, not real measured data.

Consider "Lakeview Heights," a society that ran everything through a single WhatsApp group. One resident, Mrs. Iyer, reported a persistent water seepage in her bathroom ceiling. Her message arrived at 9pm, was seen by a few people, got one "will check" reply, and was then buried by the morning's flood of school-bus updates. Ten days later, with the seepage now damaging her wardrobe, she raised it again — angrier, publicly — and the committee scrambled, embarrassed, with no record of the first report.

Now replay it with a ticketing system. Her 9pm report becomes ticket number such-and-such, categorised as plumbing, marked medium priority, with a photo of the stain. It is assigned to the maintenance supervisor with a two-day SLA. When it is not actioned by the escalation window, it is automatically flagged to the manager, who sees the full context and dispatches a plumber. On completion, the supervisor adds a resolution note — "traced to a leaking joint in the flat above; sealed and tested" — and Mrs. Iyer gets a notification. The problem took the same physical work to fix, but the experience for everyone was completely different, because the process carried it instead of a person's memory.

WhatsApp group vs a complaint management system

DimensionWhatsApp groupComplaint management system
IdentityA message among hundredsA numbered, trackable ticket
OwnershipAddressed to everyone / no oneAssigned to a named responder
StatusUnknownOpen / in-progress / resolved / closed
PriorityAll messages look the sameCategory and priority set explicitly
DeadlinesNoneSLA per category and priority
EscalationPublic angerAutomatic, rule-based, with context
HistoryBuried in the scrollFull audit trail on the ticket
Loop closureResident guessesResolution notification

Frequently asked questions

What is an SLA in the context of society complaints?

An SLA — Service Level Agreement — is a committed timeframe for responding to or resolving a complaint of a given category and priority. It replaces the vague promise of "soon" with a defined deadline, so the society can be held to a standard and unresolved tickets become visible rather than forgotten.

How many priority levels should we use?

Three or four is usually enough — something like urgent, medium, and low, optionally with a separate top tier for genuine emergencies. Too many levels create decision paralysis at logging time; too few fail to separate the burst pipe from the hedge trim. Keep it simple and consistent.

Won't a ticketing system feel too formal for a small society?

It feels less formal in practice, not more, because it removes the awkwardness of chasing people in a group chat. A resident quietly raising a ticket and tracking it is far more comfortable than publicly complaining. Even a small society benefits from every issue having an owner and a status.

What happens if a complaint is unfairly raised or is not the society's responsibility?

It still gets a ticket, but the resolution note records the reasoning — for example, that the issue falls inside the flat and is the owner's responsibility, or that it was investigated and not substantiated. Recording the decision, rather than silently ignoring the complaint, is what keeps the process fair and defensible.

Can residents track their own complaints?

Yes — that is one of the biggest advantages. In a resident-facing app, a member can raise a complaint, see its ticket number and current status, and get notified when it is resolved, without depending on anyone in a chat to reply. The mobile experience is described on the mobile app page.

How does escalation actually work?

You configure an escalation window per category and priority. If a ticket remains unresolved past that window, the system flags it and routes it to a more senior person with the full history attached. The escalation is automatic and unemotional, which is far healthier than a resident publicly tagging committee members.

Does AI resolve complaints on its own?

No. The AI draft-assist feature helps residents and staff write clearer complaints and updates — it lowers the friction of describing and responding to a problem. The actual triage, assignment, and resolution remain firmly with people. The AI helps with words, not decisions.

Key takeaways

← Back to Blog