The 5-step tenant complaint workflow every property manager needs

If you handle complaints for a living and you have never written down your workflow, you have one anyway. It just lives in your head and shifts slightly every Tuesday. This article maps the canonical 5-step workflow that every property management business eventually converges on, and points out the four places where most managers leak information.

Step 1: Capture

The complaint is reported. This is where 80% of all problems start, because the capture format determines everything downstream.

Bad capture: “The lift is broken.” Posted in a building chat at 11 p.m.

What’s missing? Which lift, if there is more than one. Which floor it is stuck on. Whether anyone is inside. Whether it has been broken for an hour or three days. Whether the tenant has tried anything.

Good capture: a structured form with a title, a description, an optional category, and an optional photo. Even when tenants fill it out lazily, you get more usable information than a chat message provides, because the structure forces them to answer the basic questions.

The single biggest win in moving off chat is forcing the capture format. Tenants provide better information when the form asks for it than when they type freehand.

Common failure mode: capturing complaints by phone. The information lives in the manager’s head, gets transcribed unreliably (or not at all), and never shows up in any system. By the time the manager forgets to act on it, there is no trace.

Step 2: Triage

The complaint exists. Now someone has to decide: who handles it?

In a small operation, this is the manager doing it manually. In any operation past three buildings, this is automated by category:

• Plumbing → plumber on roster
• Electrical → electrician on roster
• Pest control → pest control vendor
• Common areas / fire safety / “other” → manager

If the complaint has no category, it routes to the manager by default. If it has a category but no one is registered for that category, it also routes to the manager, and that gap becomes a hint that you need to onboard a fixer for that skill.

We support routing every complaint to the manager regardless of type, and plenty of teams run it that way. But it is the less efficient option: the manager becomes a router, and the routing layer turns into the bottleneck. Routing by category instead, with the manager overseeing the operation rather than handling each handoff, is the single highest-leverage change in the whole workflow.

Step 3: Acknowledge

The handler (manager or fixer) receives the issue and acknowledges it. In a ticket system, this means moving the status from New to In Progress. The tenant sees the status change and knows the issue is being worked on. They do not need to ask.

This step eliminates the entire “any update?” loop. About 30% of all communication overhead in a chat-based workflow comes from tenants asking for status because they have no other way to know. Make the status visible and it disappears.

Common failure mode: acknowledging in your head but not in the system. The handler knows about the issue, but the tenant does not know that they know. The tenant assumes nothing is happening and reports it again, often more aggressively.

Step 4: Resolve

The work is done. Plumber fixed the leak. Electrician replaced the breaker. Cleaner cleared the corridor.

In the ticket system, the handler marks the issue as resolved (or “Awaiting Confirmation”: same thing, different label). This sends the issue back to the tenant for confirmation. The handler does not close the ticket. Only the tenant can do that, by confirming the fix.

This is a deliberate design choice. It prevents the failure mode where a fixer half-fixes something and marks it closed, then the tenant comes back two days later complaining and now there is a fight about what was actually done.

Common failure mode: handler closes the issue themselves; tenant is never notified; tenant reports the same issue again two weeks later because the original fix did not hold.

Step 5: Confirm or reopen

The tenant gets a notification. Two buttons: Confirm Fixed, or Reopen with a reason.

• If they confirm, the issue closes. Done. No further action needed from anyone.
• If they reopen, the issue goes back to New with the tenant’s reason attached. The handler sees it again with full context.

The reason field on reopen is mandatory. This prevents the lazy “still broken” reopen with no information, which forces another round trip.

Common failure mode: no confirmation step exists. The handler closes; the tenant is never asked. The handler thinks the issue is resolved; the tenant is still living with it. This shows up later as a complaint to the owner, or worse, a churned tenant.

Where information leaks (and why)

Across the five steps, here are the four places information typically goes missing:

1. Between Step 1 and Step 2, when capture is unstructured. Information that did not make it into the message never gets recovered. Solution: structured capture form.

2. Between Step 2 and Step 3, when triage is manual. The manager knows about the issue but takes 6 hours to forward it to the right fixer. The fixer’s response time stretches because the clock started long before they were notified. Solution: automated routing on category.

3. Between Step 3 and Step 4, when status is not visible. Tenants ask for updates because they cannot see them. Managers re-explain three times. Solution: shared status field.

4. Between Step 4 and Step 5, when confirmation is skipped. Handler closes; tenant never confirms. Issue appears resolved but is not. Solution: tenant-driven confirmation step.

Plug these four leaks and your workflow runs about 3× faster on the same staff.

A reality check on time

If you map this workflow against real time on a real complaint, here is what a healthy lifecycle looks like:

• Step 1 (Capture): tenant submits in 30 seconds.
• Step 2 (Triage): system auto-routes in <1 second.
• Step 3 (Acknowledge): handler responds within 4 hours during business days, typically.
• Step 4 (Resolve): varies wildly. Minutes for an unlocked door, days for a parts order.
• Step 5 (Confirm): tenant confirms within 24 hours of being asked.

End-to-end, a typical issue closes in 1–3 business days. Complaints that take 3 weeks are slow because steps 2, 3, or 5 are missing entirely, not because the work is hard.

If your average resolution time is more than a week and your fixers are not the bottleneck, the workflow is. Fix the workflow first.