Every support operation produces two things at once. The first is the service: cases closed, calls answered, requests processed. The second is one almost nobody collects: a continuous record of what is failing in the business, described by the people living with it, without a research panel or a market study in between.
That second output is usually lost. Not because nobody looks at the data, but because it is examined with the wrong question. The monthly report says how many contacts there were, how long each took and how many were resolved on time. It does not say what would have to be fixed for half of those contacts not to exist. The operation is judged on its ability to absorb demand, never on its ability to explain it.
Voice of the customer is not the survey
In many companies "voice of the customer" means the satisfaction survey. A survey measures how someone felt about the service they received. It is useful, it has its own method, and we cover it in CSAT, NPS and CES, but it answers a different question from the one that matters here.
The operational question is why the contact existed at all. Someone calling to ask where their order is may be perfectly happy with the agent and score the interaction at the top of the scale. That call is still evidence of a defect: the order status was not visible where it should have been. The survey records it as a success. The contact reason records it for what it is.
The raw material is the disposition catalogue
None of this works without a catalogue of reasons that describes causes rather than internal departments. That is the subject of contact disposition codes, and it is worth settling before promising any analysis. A catalogue where "general enquiry" and "other" hold a meaningful share of the volume is not a source: it confirms that contacts happened, not what they were about.
The working rule is short. Every category has to be able to finish the sentence "the customer contacted us because…". If it cannot, it is not a reason, it is a bin. And bins grow on their own, because they are the fastest route when a case has to be closed and the next one is waiting.
That classification also has to be audited. If nobody checks a sample of cases against how they were tagged, the catalogue degrades within weeks and the analysis inherits the error. The method is the one in quality control by audited sampling, applied to classification instead of to resolution.
Three sources that say different things
- Contact reasons give size and trend. They tell you which problem is large and which is merely loud. It is the only source that allows prioritisation, because it is the only one you can count.
- Free text — agent notes, emails, transcripts, chats — gives the detail. Reasons tell you there is friction in the returns process; free text tells you at which exact step it breaks and what the system said back to the customer.
- What the team knows and never writes down. The people handling contacts repeat the same explanation dozens of times a day and know which instruction confuses everyone. That information is on no dashboard, and it is collected by asking on a fixed routine, not whenever someone remembers.
The three complement each other and none replaces the others. Counts without text produce priorities with no explanation; text without counts produces convincing anecdotes about small problems.
From data to a finding
A finding that is worth anything has four parts: what happens, how often, how much work it creates, and who can change it. Without the last one it is not a finding, it is an observation.
That is where most programmes collapse. A list of reasons sorted by volume gets presented, everyone nods, and the following month the same list arrives with the same names at the top. A sorted list is not a prioritisation: it is an inventory. Prioritisation starts when someone decides which of those reasons will be attacked this cycle and accepts that the others stay as they are for now.
A finding with no owner inside the client is a slide. With an owner and a date it is a change.
The loop closes outside the operation
This is the honest limit of any provider. Almost no valuable finding is resolved inside the outsourced operation. An ambiguous instruction at checkout, an automated email that arrives too early, a returns policy nobody understands: those are changed by the client's product, technology, logistics or marketing teams. The support team can only point at them accurately.
So the programme lives or dies in the design of the relationship, not in the analysis. It needs a fixed slot in the contract's governance forum — the subject of BPO contract governance — and it needs named counterparts on the client side who are not only the service owner. When the sole recipient of a finding is the person managing the contract, the finding stays in their inbox: they have no mandate over the product or the systems. The conditions for that channel to exist are the ones in integrating an outsourced team with your own.
Making it routine rather than a project
A monthly cycle is enough and it is sustainable. One topic per cycle, not five. The sequence that works: pick the reason carrying the most work, read real cases of that reason — cases, not summaries — write down what is causing the contact, propose a concrete change with an owner, and open the next cycle by checking whether the volume of that reason moved.
That last step is what gives everything else credibility. If the change was implemented and the reason fell, the programme stops being a courtesy from the provider and becomes part of the budget. The levers that make it fall are the ones in how to reduce contact volume: the analysis says where to apply them, it does not replace them.
What usually goes wrong
Three failures repeat. The first is turning the programme into a dashboard: more charts, fewer decisions. A dashboard compels nobody to do anything, and findings that make no department uncomfortable are rarely worth much.
The second is mistaking one day's variation for a trend. Reasons rise and fall for external causes — a campaign, a public holiday, a one-off outage — and chasing every movement spends the programme's credit on problems that resolve themselves.
The third is a design fault: catalogues with too many categories, which produce worse data than a small, well-defined one. When tagging takes longer than the case allows, the team picks the first option on the list and the analysis is built on that.
How smartBPO works it
We treat the contact reason as a deliverable of the service rather than an administrative field: it is defined with the client at the start, audited by sample, and adjusted when reasons appear that the catalogue never anticipated. Each month we bring one topic to the governance meeting, with real cases behind it and a proposed change that almost always belongs to a client team rather than to us. We ask for an owner and a date for that change, and in the following cycle we report whether the volume of that reason moved. When the change does not happen, we say so too, because the cost of that contact is still sitting somewhere in the operation.