Part of Custom HTML Blocks Access
Built with Fin AI
Rebuilt to hand off to the team that enables the feature: 21 of 24 requests reached that team, up from 1 of 24
Custom HTML blocks aren't self-serve. A school has to be on a paid plan, and someone on support has to switch the feature on by hand. An earlier diagnostic on the Fin procedure handling these requests found that it explained the eligibility rules correctly and handed off cleanly. Customers still waited a median of about 68.5 hours for a close, and the wait sat after the handoff. Every request went to a general triage queue first and only later reached the team that turns the feature on. That pointed at the destination as the thing to change.
I rebuilt the procedure around three changes.
The first was where it hands off. The old version sent everything to general triage, and the new one hands off toward the team that enables the feature, which removes the extra hop.
The second was making sure the conversation actually got there. Fin hands off to a shared routing step that classifies each conversation with AI and picks a team from that classification. Someone asking to turn on custom HTML could easily get read as a setup question or a troubleshooting problem and land back in general triage. So the procedure writes the specific request type onto the conversation before the routing step runs, giving the router a label that points at the right team.
The third was the message itself. The procedure now tells customers up front that the feature needs a paid plan and a manual switch, checks their plan, and sets a 24-hour expectation before handing off. Nobody should find out about the plan requirement three days in.
I compared the five weeks after launch (September 1 to October 8, 2026) with the same-length window before it (July 25 to August 31), when the old procedure was still live. Request volume was identical.
| Old procedure | Rebuilt procedure | |
|---|---|---|
| Requests | 24 | 24 |
| Reached the team that enables the feature | 1 of 24 | 21 of 24 |
| Median time to first human close | about 62.2 hours | about 40.4 hours |
| CX Score (AI-rated, 4-5 counted positive) | 100% (16 rated) | 94.44% (18 rated) |
| Handed off without getting stuck | not measured | 24 of 24 |
Both time figures run from the customer's first message, because no metric isolates the handoff itself. That's a different measure and window than the 68.5-hour number in the earlier diagnostic, so compare the two columns here with each other, not with that number. At these sample sizes the CX Score change is noise.
It wasn't perfect. Of 20 conversations I could identify as real activation requests, the procedure caught 18. Two of its 24 fires were people whose HTML wasn't rendering, which its exclusions were supposed to filter out. And 3 of the 24 never reached the right team. When I traced those, the shared routing step had run its own classification regardless of the label the procedure set. In two cases it decided the customer had a troubleshooting problem, overwrote the label, and sent them to general triage. The third got read as a general product question and was moved by hand later.
The earlier diagnostic said the delay lived downstream of the AI, and changing the destination is consistent with that: at the same volume, the median close went from about 62.2 hours to about 40.4 hours. The misses taught me something too. When a procedure hands off to a shared AI classifier, pre-setting the label you want improves the odds of the right route, but the classifier still gets the last word. If a route has to be exact, I'd have the procedure assign the team itself.