A $100M–$1B consumer fintech, customer support
Moved case resolution by 76%.
Support case volume was outrunning a manual triage process, and resolution time and CSAT were paying for it. AI now reads every incoming case, understands what the customer needs, and routes it straight to the right team - no rewrite of the support process required.
Average case resolution time dropped from 8.8 days to 2.1 days.
Compared across resolution times before automated triage and after go-live, same support queue.
Thousands of support emails a month, triaged entirely by hand.
Every incoming case had to be read, understood, and routed by a person before anyone could act on it. At the fintech's volume, that queue never stopped growing - and no one owned fixing the intake, only the teams downstream of it.
Manual triage meant delays before work even started, and those delays showed up directly in resolution time and case quality. For the team accountable for both, that backlog was the whole problem: every hour lost to triage was an hour the customer felt, and margin the support org couldn't win back by adding headcount.
Taught AI to read each case and route it to the right team - safely.
Instead of a person scanning every case, the AI reads the incoming email, understands what the customer is actually asking for, and sends it straight to the team that can act on it. The first workflow tackled: moving service cases that really belonged with sales. Getting this right required understanding the business first, not the model - we analyzed the fintech's historical case data end to end before writing a single classification rule.
- Strategy. Route by what the customer needs, not by which queue the email landed in.
- Engineering. A classifier that reads case context and assigns it to the team built to resolve it.
- Verification. A deep read of the business process and historical case data, so routing reflected how the team actually worked - not a guess at it.
An AI triage layer built on the fintech's own Salesforce instance.
We analyzed the historical case data to build a catalog of every request type coming in, then put that catalog into the prompt the classifier uses to read and categorize new cases. Incoming cases are now understood and handed to the right team automatically, on the Salesforce platform the support team already runs on.
Live in 4.5 weeks from kickoff.
Takeaways for anyone weighing the same build.
- Agentforce isn't the cost premium it's assumed to be. Architected well, the workload priced out to roughly the same cost as running it on Claude Sonnet directly - the platform choice didn't have to be a cost trade-off.
- Confidence came from testing at scale, not from the model. Automated testing across a wide set of real case scenarios, before go-live, is what let the team trust the classifier on day one rather than watch it cautiously for weeks. This is what sets our approach apart: every prompt we build is anchored in extensive regression testing against real data, so it holds up against the messiness of live cases, not just the ones we anticipated.
- Case routing is the first layer, not the ceiling. The same catalog-driven classification is now being extended to more complex requests - drafting email responses directly and automating the processes behind them.
What the fintech owned.
The fintech owned the business rules and the segmentation logic for which team a case type should land with - decisions only they could make. They also ran user acceptance testing themselves, pushing the classifier through real-life scenarios before trusting it with live volume. We supported that with a sample scenario set mined from their own historical data, but the sign-off was theirs.
Talk to us about your queue.
Tell us where triage is slowing you down. We'll show you what this looks like on your own stack.
Take this case study with you
Save a clean, print-ready PDF to share internally or send to your team.