Part of Automating Manual Request Routing
A procedure that fires cleanly every time — and the near-three-day downstream wait it exposed
Custom HTML blocks aren't turned on by default for a school on the company's platform, activating them requires a support team member to do it manually, and only paid plans qualify. Before this procedure, every customer asking about the feature needed an analyst to explain those same eligibility rules by hand before the actual request could even get to the right team. The question worth answering wasn't just "does the procedure correctly explain the policy," it was "once it hands off, how long does the customer actually wait."
The procedure itself is intentionally simple: state the three facts the customer needs, then hand off immediately.
No branching, no data collection, nothing more to build here, the redirect logic is about as clean as this pattern gets.
Over 90 days, the procedure fired on 42 conversations, roughly 14 a month. That's meaningfully lower than the busiest triage-style procedures in the workspace but far from a one-off, on the same order of magnitude as other named handoff patterns already being tracked. The procedure itself does its job: it fires correctly and hands off without incident.
The more useful number is what happens after: a median of roughly 68.5 hours, nearly three calendar days, between the handoff firing and the receiving team actually closing the case. That's a real, measured delay sitting entirely downstream of anything Fin controls. One caveat on precision: "time from handoff to close" isn't a single discrete metric the reporting system tracks directly, what's shown here is time-to-close with bot inbox wait time subtracted out, the closest available proxy. It's directionally accurate, but may still include some pre-handoff conversation time that couldn't be cleanly excluded.
A procedure audit that only checks whether the AI fired correctly will miss where the customer actually experiences delay. This one fires cleanly and explains the policy correctly every time, and the customer still waits nearly three days for resolution, because the bottleneck was never in the redirect logic, it's in how quickly the receiving team works through the queue once a case lands there. That's a genuinely different, and arguably more useful, finding than "the AI is broken": it tells you the next fix isn't a guidance change or a procedure rebuild, it's a capacity or process question for the team on the other end of the handoff.