Learn From Resolutions, Not Just Conversations

Customer care has never had more data to learn from. Every call, chat and app session is transcribed, tagged, clustered and fed back into bots, flows and dashboards. On paper, the operation should get smarter with every contact.

In practice, many operators find that it doesn't. The same problems keep coming back, the same customers keep calling, and diagnostic quality still depends on which agent picks up the phone.

The reason is simple. Most care tools learn from what customers say. What actually moves customer care forward is learning from how problems get resolved, and whether they were resolved at all.

How traditional care tools learn

Most customer service technology is built around the intent: the reason for contact, as understood at the start of the interaction. That intent comes from one of two places.

In automated channels, it comes from the customer's own words. A natural-language model reads "my TV keeps freezing" or "the internet is down again" and maps it to a category. In the call centre, it comes from the agent, who listens, interprets and picks a reason code at the end of the call.

Everything downstream is then optimised around those intents. Bots are trained to recognise them better, flows are designed per intent, volumes are reported per intent, and conversation analytics looks for new intents emerging in the transcripts. The learning loop improves how well the operation understands and routes the conversation.

That is useful work. But it optimises the conversation, not the resolution. As Schaman's comparison with general-purpose agentic platforms puts it, generic tools learn by optimising conversations and tasks, while resolution intelligence learns by optimising resolutions, discovering NFF cases and detecting operational signals.

Why intents are a weak signal to learn from

An intent describes the symptom as someone perceived it. It says very little about what is actually wrong, and nothing about whether the problem was solved.

• Customers describe symptoms, not causes. "Slow internet" can mean Wi-Fi interference, outdated router firmware, a provisioning mismatch, a degraded network element or a device configuration issue. The same words hide very different problems.
• Agent tagging is subjective. Two agents can classify the same call differently, and one agent can classify similar calls differently on a busy day. When categorisation depends on each agent's judgement, the data becomes inconsistent and real automation becomes impossible.
• The label is fixed before the diagnosis. The intent is captured at the start of the contact, when nobody yet knows the cause. It rarely gets corrected once the real problem is found.
• It says nothing about the outcome. An intent record cannot tell you whether the fix worked, whether the customer called back, or whether a technician was sent for nothing.

A system that learns from this data gets very good at recognising how customers talk about their problems. It does not get better at solving them. The operation stays reactive, dependent on expert agents and inconsistent in quality.

The signals that actually measure resolution

The question that matters is not "what did the customer say?" but "did we diagnose the real cause, and did the fix hold?" Answering it requires a different kind of data: what happened during and after the resolution.

When every case is diagnosed from the root cause, through real-time access to customer, service, network and history data, each interaction is classified automatically by its verified cause rather than by its description. That makes a new set of learning signals possible:

• Repeat contacts. A customer who comes back with the same issue is the clearest evidence that a diagnosis or a fix was wrong. Tracked per root cause, repeat contacts show exactly where the resolution logic fails.
• Reopen rate by resolution path. Not every fix for the same cause performs equally. Measuring reopenings per path shows which resolutions hold and which only buy time.
• No Fault Found (NFF) rate per intent. An NFF is a contact where the diagnosis found nothing wrong, yet the customer had a real problem. A high NFF share is the map of what the operation doesn't yet know.
• Resolution quality and success rate per issue. How often each diagnosis leads to a verified fix, in which channel, and at what cost, including unnecessary field visits.
• Large-scale behaviour shifts. A sudden spike in one root-cause category often reveals an emerging service issue before anyone has reported it.

None of these signals exists in an intent-based model. They only appear when the operation records why a case happened, what was done, and what happened next.

Closing the loop: from signal to knowledge

Signals only create value when they change how the next case is resolved. A resolution-based learning loop works in four steps:

1. Capture. Every interaction is logged in depth, with its diagnosis, the tests run, the resolution applied and the outcome.
2. Analyse. Repeat contacts, reopenings and NFF cases are analysed automatically to find recurring gaps: a fix that doesn't hold, a cause the diagnosis keeps missing, a pattern no one has seen before.
3. Recommend. When a pattern points to an unknown cause, the system surfaces its origin and proposes concrete improvements to resolution content and processes.
4. Validate and declare. People review and approve each recommendation, and the new root cause becomes part of the resolution knowledge.

The human in the loop matters. Learning should never mean the AI quietly rewriting how a network or a customer is handled. Every change stays transparent, approved and traceable.

Speed matters too. Because resolution knowledge is declared in small, self-contained units rather than hardcoded flows, a new root cause and its resolution can go live in about a day. Once declared, the system applies it across every channel and every customer context where it is relevant. The next customer with that issue is diagnosed correctly from the first contact, and a missing answer today becomes discovered knowledge tomorrow.

What changes for the operation

When care learns from resolutions, the improvement shows up where it counts: in how often the operation gets the diagnosis right.

Diagnostic accuracy becomes a managed KPI. Instead of reporting volumes per intent, the operation tracks success rate, NFF and reopenings per root cause and per resolution path. Weak spots become visible and fixable, one cause at a time.

Expertise stops living in a few heads. In most operations, the best diagnosticians are a handful of senior agents. Resolution-based learning captures what works and makes it available to every agent and every channel. Root-cause orchestration takes that complexity off agents' shoulders: at one Tier-1 operator, it cut new-agent training time from five weeks to five days.

Quality becomes consistent across channels. The same diagnosis logic serves the app, the IVR, the call centre and the field technician. A customer gets the same right answer wherever they ask.

Improvement becomes continuous. For operators that adopt this approach, the biggest outcome is often not a single KPI but a culture: continuously detecting new root-cause situations and adding them to the automated resolution logic. Each new cause learned improves every future case with the same problem.

And because a correct diagnosis is the precondition for prevention, this is also what opens the door to acting before the customer calls.

The bottom line

Intents tell you how customers describe their problems. Resolutions tell you whether you understood and solved them. Only the second kind of learning makes customer care better over time.

An operation that wants to evolve needs to diagnose every case from its root cause, classify it by that cause and track what happens next. Repeat contacts, NFF, reopenings and resolution quality then become the raw material of a loop that keeps improving diagnostic accuracy, one validated root cause at a time.

The goal is not to understand customers' words better. It is to get their problem right the first time, every time.

Want to see how resolution intelligence learns from every case? Request a demo or explore Autonomous Operations and Operational Intelligence.