Complaints turn into fixes when, once a week, someone at head office sorts the week's messages into cases (one customer, one fix, already owned) and issues (the same problem at more than one branch, or repeating at one), writes each issue as a single line with a named owner and a date, and opens the following week by checking what happened to last week's lines. Most complaint data never becomes a fix because that step is skipped: messages are read, cases are handled one by one, and the pattern behind them is noticed by everyone and assigned to nobody. The weekly list is short, specific and owned, and it is the only part of a feedback programme that changes what a branch does.
This article gives the weekly structure in five steps, what a line on the list has to contain, how to pick an owner when the fix sits between branch and head office, what to leave off the list, and how to keep it from growing into a backlog nobody reads.
Why complaint data rarely becomes a fix
A group collecting customer messages at every branch has, within a month, more information about its branches than it has ever had. The failure is almost never in collecting it. It is in the step after.
Messages are read as they arrive, by whoever reads them. Cases are handled, because a customer is waiting. The rest is noted. "There seem to be a lot of comments about the queue at the Northgate branch" is said in a meeting, agreed with, and not written down. Three weeks later it is said again.
The pattern was visible. It had no owner, no line and no date, so it stayed a pattern.
Cases and issues are different lists
The first thing the weekly review does is separate two kinds of thing that arrive mixed together.
A case is one customer who asked to be contacted. It has an owner already (usually the branch), a state, and a clock. Cases are handled during the week as they come in, and the weekly review does not re-handle them. It looks at the oldest open ones and asks why.
An issue is a problem, not a customer. "Morning queue at Northgate." "Wrong orders at three branches." "Changing room lock at Eastfield." An issue may have come from six messages or one. It has no customer waiting, which is why it has no owner by default, and why the weekly review exists.
Groups that keep one list have cases crowding out issues, because cases have clocks and issues do not. Keeping two lists is the fix.
The weekly review in five steps
Thirty minutes, the same day each week, with the person at head office who reads the messages and the person who can assign work to branches. In a small group that is one person. In a larger one it is two or three.
1. Check last week's lines
Before anything new. Each line from last week: done, in progress with a date, or not started. Not started gets a reason and a new date or comes off the list with a note saying why. This step is what makes the list real. A list that is never checked is a suggestion box.
2. Sort the week's messages
Every message from the week, already read, sorted into: a case (handled, check the clock), praise (passed down, check it was), nothing to act on (one-off, already resolved, not actionable), or a candidate issue.
The last pile is usually small. Most messages are cases or nothing. The candidates are the ones that describe a condition rather than a moment.
3. Cluster the candidates
Group the candidates by what they describe, across branches. "Slow at 8am" from four customers at one branch is one issue. "Wrong order" from one customer each at three branches is one issue. "Card machine down" from one customer at one branch is one issue if it is the second week it has appeared, and nothing to act on if it is the first and the branch has already reported it.
This is where reading every message the same way at every branch pays off. If branch 6's messages were sorted differently from branch 19's, the cluster across them is invisible.
4. Write each issue as one line
The line has four parts and nothing else. The problem, in plain words. Where, by branch. The owner, by name. The date by which the owner will have done something, or will report back if it is not done.
"Morning queue, Northgate. Rota review. [Name], area manager. Friday." That is a complete line. "Look into staffing issues" is not a line.
If a line cannot be written in that shape, it is not yet an issue head office can assign. It goes back to candidates with a note on what would make it one.
5. Send the list
To every owner, the same day, and to the branches whose issues are on it. The branch manager at Northgate should know that head office has seen the morning queue and that the area manager owns the rota review by Friday. That is also how the team at Northgate finds out the code on the counter leads somewhere.
Picking the owner
Most issues sit between the branch and head office, and the owner question is where lists stall.
The branch owns what the branch can fix with what it has. A briefing, a pairing change for new starters, a layout change on the floor, a repair the branch can order.
Head office owns what needs money or a decision above the branch. The rota budget, a system change, a policy, a contractor, anything that affects more than one branch.
The area manager owns the ones in between: a rota change within the existing budget, a repair above the branch's authority, a problem at two of their sites.
Where it is unclear, the owner is the most senior person who has to act, and the line says what the branch's part is. The owner is never "the branch" or "ops". It is a name.
What stays off the list
One-offs. A single message about a single moment is a case if the customer asked to hear back and nothing otherwise. It becomes an issue only when it repeats.
Things already in hand. A branch that reported its broken card machine on Monday does not need a line on Thursday's list. The list is for what has not been picked up.
Anything about a named staff member. Patterns about individuals go to the manager as coaching, through a separate route, and never on a list circulated to branches.
Anything without an owner who can act. If nobody in the room can assign it, it is a note for a different meeting, not a line.
Praise. It has its own route, to the manager the same day. The weekly review checks that it went, and does not list it.
Keeping the list short
A weekly list that runs past ten lines is being used as a backlog, and a backlog is where issues go to stop being fixed.
Lines that have been on the list three weeks are either not issues or not owned properly. Either way they come off, with a note, and the review asks why.
The list is for this week's assignments. Long-running work (a system change over two months) gets one line with a check-in date, not a line every week.
If the candidates pile is consistently larger than the list can take, the group has more problems than it can fix at its current capacity, which is information for whoever sets the capacity. The answer is not a longer list.
Outhentik does the sorting and clustering before the review: every message at every branch is read by the same reader, a problem raised at more than one branch shows as an issue on the daily brief, and the original messages stay behind each one so the review can check the reading. What it does not do is pick the owner or make the call. That is the thirty minutes.
What not to do
Hold the review without checking last week. The first ten minutes are the whole point.
Write lines without names. "Ops to review" is nobody.
Let cases and issues share a list. Cases have clocks and will always come first, and the issues will sit at the bottom until the list is abandoned.
Run the review monthly. A month of messages is too many to sort and the issues on them are a month old. Weekly is the rhythm that keeps the list short.
Circulate the list to branches with staff names on it. Issues go to branches. Coaching goes to managers. Not the same document.
Add a line for every candidate. The candidates pile is where judgement happens. The list is what survived it.
Keep a branch off the list because it sends no messages. A quiet branch is unknown, and "check coverage at Westside" is a legitimate line with an owner and a date.
What to expect
The first few reviews produce long candidate piles and short lists, because the group is seeing conditions it has lived with for years. That is normal. The list should still be short.
Within a few weeks the same owners appear repeatedly, which shows where the group's fixing capacity actually sits. Often it is one area manager. That is worth knowing.
Lines that come off as done should thin the messages that produced them. If the morning queue at Northgate is still producing messages a month after the rota review, the review did not fix it, and it goes back on the list with a different owner or a different fix.
Volume per branch will vary, and so will how much the list reflects each branch. A branch that sends many messages will appear more often. That is a coverage effect before it is a quality effect, and the review should say so when it reads the list.
Frequently asked questions
How do you turn customer complaints into actions?
Once a week, separate cases (one customer, already owned) from issues (a problem at more than one branch, or repeating at one). Write each issue as one line: the problem, the branch, a named owner, a date. Send the list to the owners and the branches. Open next week by checking every line.
What should a weekly complaint review cover?
Last week's lines first. Then the week's messages sorted into cases, praise, nothing to act on, and candidate issues. Then the candidates clustered across branches and written as lines with owners and dates. Thirty minutes, same day each week.
Who should own fixes that come from customer complaints?
Whoever can act. The branch for what it can fix with what it has. Head office for money, policy, systems and anything affecting more than one branch. The area manager for the rest. Always a name, never a team.
How many items should be on a weekly fix list?
Fewer than ten. Longer than that and it is a backlog. Lines that have sat for three weeks come off with a note. Long-running work gets one line with a check-in date, not a line every week.
Should individual staff complaints go on the weekly list?
No. Patterns about a named person go to their manager as coaching through a separate route. The weekly list goes to branches and should never carry a staff name.
How do you know whether a fix worked?
The messages that produced the issue should thin out in the weeks after the line is marked done. If they do not, the fix did not hold or was not the right one, and the issue goes back on the list.
Try Outhentik free for 7 days, no credit card required
Outhentik gives head office a direct line from customers at every branch: every message read the same way, a case with an owner for each customer who asks to hear back, and a daily view of which problems repeat and where. The daily brief is the candidates pile already sorted; the weekly review is where each issue gets a name and a date.