Building Fin procedures that recognize and redirect the requests the company can't resolve itself, so analysts only see cases that genuinely need a person
A recurring category of support requests isn't actually something the company can resolve, it's something the company has to correctly redirect. A student asking for a subscription refund, a question about school settings, or a request tied to installment pricing all belong to the individual school owner, not the company. Before automation, figuring that out and routing it correctly was manual analyst work: reading the request, recognizing it was out of the company's control, and explaining that to the customer by hand, every single time. This project builds Fin procedures that do that recognition and redirect automatically, so an analyst only gets involved for the cases that genuinely need a person.
The value shows up as better-qualified work reaching analysts, not just less work overall. A well-built routing procedure doesn't necessarily reduce how often a human gets involved, sometimes it increases it, because cases that used to get silently dropped or mishandled now get correctly flagged. What it does change is the quality of what reaches an analyst: fewer messy, undocumented escalations, more cleanly triaged handoffs with the context already attached.
Covers support topics where the manual work an analyst used to do by hand, recognizing a structural redirect, collecting the right documentation before a handoff, or explaining an eligibility rule, can be done by Fin instead: student refunds outside the company's control, subscription billing questions, tax-related documentation intake, school settings, installment and pricing terms, and general "how do I reach my school" requests. Does not cover topics where the company has direct operational responsibility and Fin is expected to actually resolve the issue itself, like payouts or payment error investigation. Those are resolution work, not triage work, and stay out of scope here.
One procedure fully built and live, covering student refund requests, with real usage data confirming it changed the shape of escalations as intended: fewer unplanned, undocumented escalations, more cleanly qualified handoffs. A second, related procedure automates structured intake ahead of a handoff (collecting the right documentation before a request reaches a human) rather than a straight redirect, a close cousin of the same "move manual work onto Fin" thesis, currently live but underperforming: it's catching a small fraction of the cases it should, with the rest falling through to unplanned escalation, worth investigating on its own. A third procedure, a simple eligibility-explanation handoff, has real, moderate volume, and the data on it surfaced a different kind of finding: the procedure itself works correctly, but the downstream team taking the handoff is slow to close it out, a bottleneck outside Fin's control entirely. Four more topics show the same structural pattern in the data and are real candidates for the same treatment, though none of them have a documented procedure yet.