A Complaint-to-Resolution Workflow for Property and Retail Operations
Most complaint handling fails at one of two points: nobody owns it, or nobody can prove it was fixed. A workflow with six stages, one owner per stage and evidence at closing fixes both — and the reason-code data it produces is what finally stops the same complaint arriving every month.
Every complaint follows the same path whether it comes from a tenant, a customer, a shopper or an outlet manager: someone reports a problem, someone should own it, someone should fix it, and someone should confirm it is fixed. Most operations lose it at stage two or stage four — nobody owns it, or nobody can prove it was done — and the visible symptom is always the same: the same complaint arrives again next month, and the person who complains twice is far angrier than the person who complains once. This is the workflow that fixes both, and it works on a shared sheet before it needs any software.
The six stages
| # | Stage | Done when | The failure it prevents |
|---|---|---|---|
| 1 | Capture | It has a reference number | The complaint that scrolled past in a group chat |
| 2 | Acknowledge | The complainant has been told it is logged | Repeat complaints made because of silence |
| 3 | Classify | Priority and category assigned | Everything treated as urgent, so nothing is |
| 4 | Assign | One named owner, with a due time | Ten people assuming someone else has it |
| 5 | Resolve | Work done and evidence attached | Paying for work you cannot verify |
| 6 | Close and inform | Complainant told, with what was done | The complainant re-reporting because nobody told them |
Stage 2 and stage 6 are the two that cost nothing and are skipped most often. They are also the two that determine whether people think you are competent — a complainant who is acknowledged within an hour and informed at closing will describe a slow fix as good service.
Define priority as a test, not an opinion
Priority arguments disappear the moment priority is defined by an observable condition:
| Priority | Definition | Acknowledge | Resolve target |
|---|---|---|---|
| P1 | Safety risk, or the space cannot be used | 15 minutes | Same day, or made safe the same day |
| P2 | Usable but materially degraded | 2 hours | Next working day |
| P3 | Cosmetic or minor inconvenience | Same day | Within 7 days |
"Made safe the same day" is deliberate. A lift that cannot be repaired today can be taken out of service today, and that is a legitimate P1 resolution. Without that distinction, teams either miss the target or take shortcuts to hit it.
Capture in whatever channel people actually use
The mistake is insisting complaints arrive through your preferred channel. They will not. People will use whatever is in their hand — a WhatsApp message, a phone call, a note at the counter, an email.
Accept all of them, and make one person responsible for turning each into a numbered record within a defined time. The record needs six fields and no more to start: reference, what, where, who reported it, priority, owner. If capturing a complaint takes more than thirty seconds, it will not happen during a busy shift, and a workflow that only works on quiet days is not a workflow. Why the chat channel alone cannot be the record is covered in running your business on WhatsApp without losing the records.
Close with evidence, always
A complaint closed without evidence is a complaint you will hear about again. Closing evidence means: a dated photograph of the resolved condition, the name of who did the work, and one line on what was actually done — "replaced tap cartridge", not "fixed".
That one line is worth more than it looks. Repeated across a hundred jobs it becomes the thing that tells you a tap is being repaired every six weeks and should be replaced. Without it you have a hundred jobs that all say "fixed" and no way to see the pattern.
Reason codes: the part that actually reduces complaints
Everything above manages complaints. This is the only part that reduces them.
Give every closed complaint a cause category, not just a subject category. A short list works better than a long one — six to ten codes, chosen so that each one implies a different fix:
- Equipment failure — age. The fix is replacement planning, not repair.
- Equipment failure — no preventive maintenance. The fix is a service schedule; see the multi-outlet maintenance SOP.
- Contractor did not perform. The fix is the SLA and evidence — see managing cleaning and security vendors.
- Process not followed. The fix is training or a checklist.
- Design or layout problem. The fix is capital, and it will keep recurring until it is spent.
- Expectation mismatch. Nothing is broken; the fix is communication or signage.
Review the distribution monthly. In almost every operation, two codes account for more than half the volume, and both have a specific, affordable fix. That review is the difference between a team that handles complaints well and a team that gets fewer of them.
Four numbers on one page
Keep the monthly review to four figures:
- Volume by priority — is P1 rising?
- Percentage acknowledged within target — the cheapest number to fix and the one complainants feel most.
- Percentage closed with evidence — below about 80%, your closing data is not trustworthy enough to analyse.
- Repeat rate: complaints about the same asset or location within 90 days. This is the single best measure of whether you are fixing causes or symptoms.
For strata committees specifically
A JMB or MC committee has an additional reason to run this properly: the committee's records are the evidence base for its accountability to owners and to the Commissioner of Buildings, and complaint handling is where most of the friction with residents originates. A committee that can show, at an AGM, what was reported, what was done and what it cost has a very different meeting from one that cannot. See the JMB and MC guide for the statutory context.
Frequently asked questions
Do I need software for this?
No. Six stages, six fields and a shared sheet will run a small operation properly. Software becomes worth it when you have multiple locations, external contractors to hold to evidence, or someone you must report to — not before.
How do I stop everything being reported as urgent?
By defining priority as an observable condition rather than a feeling, publishing those definitions, and applying them consistently. If most reports still come in as P1 after that, either the definitions are unclear or the site genuinely has a problem — both are useful findings.
What if the complainant is unreasonable?
Run the same workflow. Log it, classify it honestly — "expectation mismatch" is a legitimate cause code — resolve what is genuinely resolvable, and inform them at closing. A documented, consistently applied process is also your best protection when a complaint escalates.
Should complainants see the status?
Where it is easy, yes — acknowledgement and closing notifications alone remove most follow-up contact. A full status portal is rarely worth the effort at small scale; two messages are.
How long should I keep closed complaint records?
Long enough to see 90-day repeat patterns at minimum, and longer where warranty, contractor disputes or statutory obligations apply. Digital records make several years cheap, and the historical data is what makes the reason-code analysis useful rather than anecdotal.
Sources: this guide is operational practice rather than statutory requirement. The strata context it refers to arises under the Strata Management Act 2013 [Act 757], covered in our JMB and MC guide; record-keeping obligations relating to personal data are covered in our WhatsApp records guide and arise under the Personal Data Protection Act 2010 [Act 709].
Estimate it in under a minute with our free calculator.