Reading thousands of conversations to understand why each customer called wasn’t realistic.
So we counted broad inquiry types and often chose automation priorities from the largest groups.
That works for reporting, but it doesn’t explain why customers needed help.
With LLMs, we can look across conversations for recurring situations that don’t fit neatly into the reporting categories.
This gives us a basis for deciding: which causes to remove through product or policy changes, which tasks belong in self-service or automation, and which still need an agent’s judgment. That gives us evidence for where to spend money and people’s time, not just how to classify calls.
We can’t establish the cause from transcripts alone. We need to know what the customer did before contacting support, what the system showed, which policy applied, and what the agent actually did.
STT transcripts are a starting point. They reveal the customer’s situation, request, and part of the agent’s response. The trigger or the agent’s actual actions may be elsewhere: in earlier notifications, the entry channel, a failed step in the app, service state, or system logs.
I saw this with people asking what ‘FDS’ meant. On its own, it looked like a terminology question. Once I traced the inquiries to fraud-alert text messages, the real issue became clearer: customers didn’t know what to do after receiving the alert. We changed the chatbot path to reach the responsible team and asked for clearer messages.
Once those signals are connected, we can decide what to change and check whether customers keep contacting us for the same reason.
LLMs can help find the pattern. Choosing whether to fix the product, automate the task, or change a policy is still a human decision.
The harder question is how to turn that evidence into something teams actually change.
#ConversationIntelligence #LLM #AIProductManagement