01 · Start with the customer
A routing problem is a customer problem.
When someone asks for help, they should not have to understand the company’s internal language to reach the right person. They just need to be understood.
In this system, customer conversations were being assigned to intents that had grown over time without a shared structure. Across the 50K conversations I studied for this redesign, that made it harder for the system to route a chat, harder for a human agent to pick it up, and harder for the business to learn from what customers were saying.
The old shape
Too many ways to describe the same need.
- verb “I need to change my plan”
- noun “Plan change”
- product name “The new family thing”
- overlap “Upgrade or add a line?”
The customer’s goal was clear. The architecture was not.
The new shape
One customer need. One clear home.
The system can route with more confidence, and the team can report on the need with more clarity.
02 · Find the real bottleneck
The model was downstream of the language problem.
The first instinct was to improve the classifier. I partnered with the technical team and looked one layer earlier. The labels mixed verbs, nouns, changing product names, and overlapping ideas. Teams were using the same words differently, and different words for the same customer need.
The system could not route consistently because the structure it was routing against was inconsistent. The bottleneck was the language and content layer.
The taxonomy was organizing those goals around internal labels, product names, and team habits.
03 · Partner with the technical team
I made the customer’s goal the organizing principle.
I brought the customer language, computational linguistics, and NLU content perspective. I also understood the foundational technical concepts well enough to work closely with the people responsible for the classifier and routing systems.
Together, we reassessed the needs of IT, routing, reporting, and the human teams receiving the chats. I then helped reorganize the taxonomy around clearer boundaries between customer goals.
- 01Listen to real conversations.
I studied the language customers were actually using, including messy, incomplete, and ambiguous requests.
- 02Separate needs that had been blended together.
I clarified which requests were meaningfully different and where labels were competing for the same message.
- 03Review the structure with the teams who depend on it.
IT, routing, reporting, and human-agent workflows each exposed a different part of the problem.
- 04Give each need a clear place.
The NLU content became easier for the technical system to use and easier for teams to explain.
04 · Make the experience easier
The customer found the right team more often.
Better routing
Chats moved more reliably to the human teams equipped to solve the customer’s need.
Better reporting
Reports reflected customer needs more clearly because the categories had clearer boundaries.
Better handoffs
Teams could understand why a conversation arrived and what kind of help the customer needed.
A clearer boundary
Good NLU content gives customer language somewhere useful to go.
A taxonomy is not just a list of labels. It is a set of decisions about what belongs together, what must stay separate, and what a team should do when the system is unsure.
- Customer goal
- Find out when an already-requested refund will arrive.
- Keep separate
- Starting a return, disputing a charge, and checking refund status.
- Human outcome
- Send the conversation to the team that can answer the actual question.
05 · What I learned
The best system is the one people can understand.
Every company has different customers, products, teams, and constraints. There is no universal taxonomy to copy. The work is understanding the situation as a whole, finding where the customer experience gets stuck, and making that part easier for the people and systems involved.
I would build the evaluation and reporting feedback loop earlier next time. A clear structure is the beginning. Teams also need a simple way to see when the structure is starting to drift.
What I contributed
- Conversation analysis and taxonomy structure
- Intent definitions with examples, boundaries, and customer language
- Routing and reporting guidance for downstream teams
- Review materials for IT, product, support, and operations
- Evaluation and feedback practices for ongoing maintenance
About these numbers
The figures on this page are drawn from internal program reporting I authored or co-authored as the practitioner on the engagement. They are reproduced here in rounded form. They were not produced by an independent third party, and proprietary detail has been omitted where required by the engagement.
Lift figures (CSAT, accuracy, handle time, hallucination rate) reflect pre/post comparisons against a matched baseline using the cohort, time window, and measurement instrument noted in the case study. Volume and adoption figures come from production analytics dashboards. Cost figures reflect either avoided spend or unlocked budget in the named fiscal period.
- This version intentionally describes the result qualitatively. The focus is the customer experience, routing, reporting, and human-agent handoff rather than a performance claim.
- The taxonomy and examples are generalized to protect company and customer details.
Who I worked with
I worked across IT, routing, reporting, product, support, operations, and the human-agent teams receiving customer conversations. Each group helped define what “easy to use” meant in its part of the system.
Skills demonstrated
- Conversation design
- Computational linguistics
- NLU content development
- AI content development
- Customer journey analysis
- Routing and handoff design
- Content and language systems
- Cross-functional facilitation
- Evaluation planning