Part of Automating Manual Request Routing
Before/after data on automating refund triage — where more escalations, not fewer, was the right outcome
When a student asks the company directly for a refund, the company often isn't the party who can actually grant it, that decision usually belongs to the school owner who set the refund policy in the first place. Before this procedure existed, sorting that out was manual work: an analyst had to read the request, figure out whether it was even eligible (was it inside the refund window, had the student already contacted the school), and then either action it or explain the redirect by hand. That meant every refund conversation reaching a human arrived undocumented and un-triaged, whether or not it actually needed a person at all.
The procedure does the triage step Fin used to skip entirely: check whether the request falls outside the refund window or lacks any prior contact with the school owner, and if so, close it out with an explanation instead of leaving it to land on an analyst with no context. Cases that are genuinely qualified, meaning the student has already tried the school and is still stuck, get handed off with that context attached rather than escalated cold.
Ninety days of usage data, split cleanly around the procedure's go-live week, shows the shift in what's actually happening.
Three weeks before go-live (459 refund conversations):
Eleven weeks after go-live (1,292 conversations):
The total share of conversations reaching an analyst went up, not down, from 38.3% to 57.4%. That's not the procedure failing, it's the procedure correctly surfacing cases that previously got closed out too early or never properly reviewed at all. What moved in the right direction is the composition of that analyst-facing work: fewer messy, undocumented escalations, more cleanly qualified handoffs that already have the eligibility check done. Median handling time across all analyst-touched refund conversations sits at 7.6 hours currently; a clean before/after split on handling time specifically hasn't been pulled yet, so the time-saved-per-case claim isn't confirmed, only the shift in escalation quality is.
An automation project that increases the raw number of cases reaching a human isn't automatically a failure, and a shrinking escalation count isn't automatically a win. What matters is whether the human is now doing better-qualified work: whether the triage that used to happen inconsistently, if at all, now happens every time before a person gets involved. Reading the before/after composition rather than just the headline volume is what separates "this procedure is working" from "this procedure just moved the numbers around."