Those support paths vary widely. An expert might help someone reset a password, or they might be a CPA with 20 years of real-estate tax experience. This project focused on scaling a proven optimization: use contact attributes to route customers to more suitable experts across many more expert collections.
The right expert depends on the customer's issue, the product context, and the expertise available at that moment.
Apply the proven routing approach to more expert collections to improve resolution rate, reduce transfers, and lower average handle time.
A clean-sheet matching system was not the project. The goal was to scale an existing solution that worked for a small subset of traffic.
Scaling it meant asking humans to author thousands of routing plans.
Every expert collection needed a plan. Each plan had to account for the customers coming in, the experts available in that collection, and the attributes that could predict a better match.
Best match if supply exists.
Broaden to adjacent tax expertise.
Prefer product fluency when domain supply is constrained.
Stop filtering by specialist attributes and use the collection's default routing behavior.
The first version was built in a 2024 AI environment: useful LLM classification, limited trust, smaller context windows, and much less appetite for fully dynamic production decisions. The right first product shape was a copilot, not an autonomous router.
Use lower-cost LLM passes over completed interactions to extract demonstrated skills and problem themes.
Generate routing plans offline, send them to operators for review, then publish approved versions.
The same evidence pipeline could later feed runtime matching once the business trusted AI-generated decisions.
That made the first release easier to ship: the system could process transcripts asynchronously, generate candidate plans, and let humans decide whether the plan looked credible. The tradeoff was speed: the copilot still depended on operators engaging with the workflow.
The old inputs were incomplete. Expert attributes could be missing, stale, or too coarse. Transcripts gave us observed evidence: the customer's real intent, the skills demonstrated during the interaction, and whether the conversation resolved cleanly.
What the customer actually asked for inside the conversation.
Which kinds of issues the expert had already handled in real interactions.
Whether similar pairings ended well or needed another expert.
For each expert collection, generate a routing plan from historical transcript evidence. Operators review the plan, then publish it to production.
When a customer arrives, use customer context, semantic retrieval, and expert collection constraints to construct a plan suited to that request.
Product, profile, and the question or issue the customer is asking about.
Prior interactions that look like this problem and ended well.
Prefer the best expert attributes first, then degrade without starving service levels.
The detailed production architecture is private to Intuit. At a public level, the design separated historical analysis from the time-sensitive routing experience and turned learned evidence into controlled routing behavior.
We stored intent embeddings in an OpenSearch table and searched it as a semantic cache. This reduced duplicate labels while still surfacing genuinely different customer needs.
The vector-search library behind the index.
The index method used to retrieve the nearest intent efficiently.
OpenSearch converts distance into a higher-is-better score: 1 / (1 + distance).
The project succeeded by turning a high-touch operational workflow into a repeatable system. It did not need every expert collection owner to understand every attribute. It needed evidence, plan generation, review controls, and a path to runtime decisions.
Translated a messy operational model into concrete plan-generation inputs and constraints.
Used completed interactions and outcome signals to infer skills and expert collection semantics.
Started with reviewable plans, then evolved toward customer-specific runtime routing.
Create a clearer readout of each collection: customer intent, transfer patterns, resolution quality, and how that mix changed over time.
The copilot was the right trust bridge, but the business did not want to keep approving plans forever.
Ironically, we ran rigorous evals for a specific rollout cohort, but the evaluation system itself should have scaled with every new collection.
Expert collection membership does not mean an expert can take a call now. They may be offline, already helping someone, or temporarily unavailable. Folding real-time availability into plan generation was the step that made routing less theoretical and more operationally correct.
Thousands of expert collections and opaque expertise made hand-authored plans a bottleneck.
Use transcripts, outcomes, embeddings, and filters to infer what expertise actually solved problems.
Plan generation dropped from 3-6 months to under 4 hours.
The implementation details are private to Intuit, but the public AWS materials explain the platform context: Intuit's contact-center scale, Amazon Connect, and contact attributes as routing inputs in contact flows.
AWS case study on Intuit's contact-center migration and scale.
AWS docs for the contact-attribute concept behind routing inputs in Amazon Connect flows.