Operations
Turning complaints into action: a 5-step process from feedback to ticket
A practical roadmap for turning a visitor complaint into a traceable ticket: capture, triage, routing, resolution and closing the loop with the reporter.
Turning a complaint into action takes a five-step process: capture the complaint with its location and priority, triage it quickly, route it to the right resolution team with a note, make sure the team resolves and concludes the work, and close the ticket with an outcome while letting the reporter know. Skip any one of these and the complaint either disappears or sits in "someone's probably on it" limbo. This article explains how to set up each step, who owns it and what should be on record.
Why complaints don't turn into work
When complaints go unresolved, the cause is rarely indifference. It's usually a gap in the process:
- No owner: The complaint lands in a shared inbox or a logbook, but nobody knows whose job it is.
- Missing details: "The elevator is broken" doesn't say which elevator in which building, so the team has to go looking first.
- Untracked handoffs: The complaint is passed to a department by phone and never followed up.
- No closed loop: Even when the work gets done, the person who reported it never hears back, so from their side the problem is still open.
The five steps below close these gaps one by one.
Step 1: Capture the complaint with the right details
A good process starts with a good record. Every complaint should carry:
- Location: For reports that come in through a QR code or NFC tag, the location is attached automatically.
- Category: EnaFeedback has four fixed categories: Request, Suggestion, Complaint and Thanks.
- Priority: The category sets the priority automatically. Complaints open as "High priority", requests as "Priority", and suggestions and thanks as "Normal".
- Evidence: Visitors can attach photos or a video.
- Tracking code: Each record gets a request code starting with "FB" that visitors can use to check the status.
Every feedback record creates exactly one ticket. Reports come in through four channels: visitor QR, staff feedback, escalated hygiene reports, and manual entries by admins. Entering a complaint that arrived by phone or in person through "Manual feedback" puts it into the same process.
Step 2: Triage quickly and consistently
Someone has to read every incoming ticket, usually the feedback manager. Triage involves three decisions:
- Is this actually work? Some reports are requests for information or fall outside your control. These can later be closed as "Not an actionable issue".
- Is the priority right? The automatic priority is a starting point. If a suggestion actually points to a safety risk, raise the priority; the change is recorded in the ticket history.
- Which team? That's the question for the next step.
The Home dashboard shows counts of unread feedback and tickets. You can also turn on an alert rule for the complaint category so new complaints reach the right person right away by email, SMS or in-app notice.
Set a rhythm for triage
The system has no automatic timers or SLAs, so the rhythm is up to you. A written internal rule such as "high-priority tickets are read the same working day" can be checked regularly against time-to-first-read in the reports.
Step 3: Route to the right resolution team, with a note
Routing is the moment a complaint gets an owner. In EnaFeedback, routing is manual by design: an admin sends the ticket to one or more resolution teams and adds a required note to each routing. The ticket moves to "In progress" automatically the first time it's routed.
A good routing note answers:
- What exactly is the team expected to do?
- Where's the supporting information? (Photos, similar past tickets)
- If more than one team is involved, who does what?
A sample team structure:
| Resolution team | Typical issues |
|---|---|
| Housekeeping | Dirty areas, missing supplies |
| Facilities | Faults, lighting, plumbing, elevators |
| Security | Order, parking, noise |
| Patient / Visitor Relations | Communication, information, staff conduct |
| IT | Kiosks, screens, internet |
Each routing stores the team's name as it was at the time, so renaming a team later doesn't rewrite history. If your organization runs its own work-order system, an HMAC-signed webhook can be sent when a ticket is routed and when its status changes.
Step 4: Get the team to resolve and conclude the work
Team members see the tickets routed to them in the "Team inbox". There they add notes and, when they're done, conclude the routing with an outcome:
| Team outcome | When to use it |
|---|---|
| Action taken | The work is done |
| Could not complete | The work couldn't be done; the note explains why |
| Forwarded | The issue was passed to another department or an outside vendor |
| Returned | Not this team's job; it goes back to the admin |
"Returned" matters: a misrouted ticket comes back visibly instead of sitting quietly in the wrong queue. Admins can also withdraw or cancel a routing, or handle the work themselves when needed.
For each team, the Team inbox shows unread, open and concluded counts, a success rate and the average time to conclude. Team leads can use these to keep an eye on workload.
Step 5: Close the ticket and complete the loop
A ticket can't be closed until every open routing is concluded. Closing requires one of three outcomes: Resolved, Unresolved or Not an actionable issue. Closed tickets can't be reopened; if the same issue comes back, it's tracked as a new ticket. That way every ticket goes on record with one clear outcome.
To complete the loop:
- Tell the person who reported it. If the visitor left contact details, they get an email and/or SMS when the ticket's status changes. Anonymous visitors can enter their request code to see whether the status is "New", "In progress" or "Closed".
- Take closing notes seriously. The next time a similar complaint comes in, the team will look at them.
- Close out the thanks, too. Sharing thank-you feedback with the team reminds everyone the process isn't only about problems.
Measuring the process: what to watch
Once the five steps are running, the process analysis in "Feedback analytics" lets you review performance after the fact:
- Time to first read (mean and median)
- Time to close (mean and median)
- Age of unread tickets
- Flow from category to close outcome (for example, how many complaints were resolved)
- Resolution team performance: success rate and average time to conclude
Export these reports to Excel, and individual tickets to PDF, for your monthly quality meetings.
FAQ
Can tickets be assigned to teams automatically by category?
No. Routing is manual; every routing is made by a named user with a note. This cuts down on misassignments, especially for complaints that involve more than one team, and makes ownership clear.
Can a closed ticket be reopened?
No. A closed ticket is recorded with a final outcome. If the same problem happens again, it's tracked as a new ticket, which makes recurring issues visible in reports.
Can team members see every ticket?
Users with the team member role only have access to the Team inbox and see the tickets routed to the teams they belong to.
Can I log complaints that come in by phone?
Yes. Records entered on the "Manual feedback" screen go through the same ticket process as QR reports and appear in the same reports.
Wrapping up
Turning complaints into action doesn't require a big transformation program. It requires that capture, triage, routing, resolution and closing each have an owner and a record. These five steps show the people who report problems that you heard them, and show management which problems were solved and how. See the product side on the ticket management, QR feedback and analytics and reports pages, or request a demo to try it with your own teams.