A complaint is upheld. The response explains that the organisation has reviewed what happened, updated its procedure and made sure staff are aware of the change, so that it doesn’t happen again. An action is logged, assigned to someone and, a few weeks later, marked as complete.
On paper, the organisation has learnt something.
It may well have. But what the record usually shows is that something was done. Whether it changed what happens to the next person is a separate question, and it isn’t always one anybody goes back to ask.
Implemented as what?
“Implemented” can mean quite a few different things.
It can mean a decision was made. It can mean a document was updated, a message went out to staff or a training module was changed. It can mean people now behave differently. And it can mean the next customer in the same situation gets a different outcome.
Each of those is a real step, and each can honestly be recorded as implemented. But only the last one tells you whether the original problem has actually changed.
The gap between them is where changes tend to go missing.
Where a change can get lost
A training module is updated, but existing staff aren’t required to take it again, so the change reaches new starters and possibly not the people involved in the original failure. A procedure is rewritten, but the system still presents the old template, so the path of least resistance leads straight back to the old way of doing things. A reminder goes out by email, alongside everything else that went out by email that week.
“Staff have been reminded” is doing a great deal of work in a great many complaint responses.
Sometimes the change reaches one team but not another that handles the same kind of case: a different shift, a different site, an outsourced partner. Sometimes a chatbot, or the knowledge base behind it, is still giving out the old information, because nobody thought of it as part of the process that changed. And sometimes the person who owned the action moves on, and six months later nobody is quite sure whether it was ever finished or what finished was supposed to look like.
None of these requires anyone to be careless. They are ordinary ways a decision can fail to travel from the place it was made to the place it was meant to have an effect.
Told is not the same as able
A change can also reach the right people and still not become what was intended.
People interpret what they’re told through what they already know and what they’ve seen rewarded. An instruction to “use your judgement where the standard response doesn’t fit” might be read by one adviser as permission and by another as a trap. Neither is being difficult. They’re making sense of an instruction in the context they actually work in.
Sometimes that context contradicts the change. Staff may be told they have discretion to escalate a case, waive a charge or step outside the script when it makes sense. But if those decisions are monitored, and anyone who uses that discretion more than their colleagues ends up in a conversation with their manager about it, the message received can be quite different from the one that was sent. The discretion exists. Using it has a cost.
In that situation the change has been made, communicated and understood, and it may still rarely happen. Not because staff didn’t get the message, but because they got two, and followed the one with consequences attached.
From the record, that can look like implementation. From the front line, it can look like a rule that exists mainly on paper.
Written to be closed
It’s worth looking at how actions are written in the first place.
“Retrain staff on the procedure” can be completed. Somebody can deliver the training, record attendance and close the action, and they will have done exactly what was asked.
“Customers in this situation are no longer given incorrect information” is much harder to tick off, because no single person can complete it. It describes an outcome rather than a task.
There are understandable reasons actions tend to be written the first way. They can be assigned, tracked and closed, and action logs are generally built around things that can be closed. But what the organisation actually wanted was the second. If the action only describes the first, the record can be accurate and complete and still say very little about whether the problem has gone.
The problem isn’t that the first action is wrong. Retraining staff may be exactly what needs to happen. The problem is treating completion of that action as evidence that the second statement is now true.
What the customer was told
There’s another consequence that’s easy to miss.
If a customer was told a change had been made, they now have a reason to expect it. If the same thing then happens to them again, the second failure is likely to carry more weight than the first. It’s no longer just a repeat of the original failure. It also gives them reason to question whether the change they were told had been made actually happened.
From their perspective, what they were told can start to feel worthless, or even untrue.
That’s where apology and repair start to come apart. An organisation can acknowledge a failure sincerely and record a change in good faith, and still leave whatever caused it untouched. From the outside, that can look a lot like saying the right thing and carrying on as before, even when that isn’t what anyone intended.
How would anyone know?
In some organisations, the evidence that a change has been implemented is the record saying it has been implemented. That’s circular, although it rarely looks it from the inside.
Evidence that something has changed needs to come from the place where the change was supposed to happen: what staff actually do, what the system actually presents, what the next customer actually experiences.
It’s also tempting to treat an absence of further complaints as confirmation. It might be. It might also mean the people affected have stopped expecting anything different. Somebody who was told a problem had been sorted, and then found it hadn’t, may not see much point in saying so again.
No further complaint tells you that no further complaint was made. It doesn’t, on its own, tell you what happened next.
Decided is not done
Recording a change is part of implementing it. It isn’t the same thing.
The action log can tell you what the organisation decided to do.
Only the service can tell you whether it did.
About the Author
Karen Ferguson investigates why problems in human-facing services keep happening. Her background is in human behaviour and communication, and she has designed, built and adversarially tested conversational AI systems. Problems she has identified and pursued have led to documented process changes in an NHS trust, a police force and a national charity.