A complaint hiding in a renewal email
A client replies to their renewal invitation: 'This is the third year in a row the price has gone up and nobody has explained why. Not happy.' The handler reads it as a price query, calls the client, and sorts out the renewal. It never goes in the complaints log. Months later, a file review or the client's next letter shows it probably should have.
Meanwhile the complaints that are logged sit in a spreadsheet kept by the compliance officer. Dates are typed in, deadlines are worked out by hand, and the reminder to send the holding response depends on someone opening the spreadsheet.
Two separate problems
The first is recognition. What counts as a complaint under your procedures is broad, and handlers dealing with a busy inbox tend to treat dissatisfaction as a service issue to fix rather than a complaint to log. The second is tracking. Once logged, a complaint has deadlines that start from when it was received, not when it reached the log, and a spreadsheet does not warn anyone.
- Complaints arrive through email, phone, letter, review sites and social media.
- Handlers decide in the moment whether something is a complaint.
- The receipt date is often the date it was logged, not received.
- Deadline reminders depend on the spreadsheet owner.
- Root causes are written as free text and never analysed.
The cost of a missed complaint
A complaint that is not recognised cannot be handled properly, and your own procedures and regulatory obligations set out what that means. A complaint that runs past its deadline can reach the ombudsman stage without a final response from you. And a log with free-text causes cannot tell you what to fix, so the same issue keeps producing complaints.
A log that tracks itself and a second pair of eyes on the inbox
- Incoming emails to shared and personal inboxes are checked by a language model for signs of dissatisfaction, and possible complaints are flagged to the handler and the complaints lead to decide.
- A short form lets any handler log a complaint from a call or letter quickly, with the date it was received.
- Each complaint gets its deadlines calculated from the received date, using the rules your compliance team sets.
- Holding response and final response reminders go to the owner before each deadline, and to the complaints lead if one is close.
- Letters are drafted from your approved templates with the case details filled in, for the owner to edit and send.
- Root cause and outcome are recorded from a list you define, alongside free-text notes.
- Reports show complaints by cause, product, handler and outcome, and every complaint links to the client record.
The model only flags. Whether a message is a complaint is decided by your people under your procedures. Messages it flags that turn out not to be complaints are recorded too, so you can see how it is doing.
From spreadsheet to tracked log
| Step | Spreadsheet | Tracked log |
|---|---|---|
| Recognition | Handler's judgement alone | Handler plus a flag on possible complaints |
| Received date | Often the logging date | Captured at source |
| Deadlines | Worked out by hand | Calculated from your rules |
| Reminders | None | Before each deadline |
| Root cause analysis | Free text | Categorised and reported |
What your complaints lead sees
A list of open complaints ordered by next deadline, the owner of each, and a flag on anything close. A monthly view of causes that shows which products or processes generate the most complaints. And a record of messages that were flagged and judged not to be complaints, which is useful evidence that the question was asked.
Is this your complaints process?
- Complaints are logged in a spreadsheet.
- Handlers decide alone whether an email is a complaint.
- Deadlines are worked out by hand.
- You could not quickly say what caused most complaints last year.