Reviewing all 11 conversations a self-serve integration procedure handled in 90 days — and tracing every handoff to a nameable cause
Setting up the company's MCP integration bundle used to mean a customer asking support, an analyst checking whether their plan actually qualified (the bundle requires API access, which is Growth plan and above), and then walking them through downloading the bundle and configuring it correctly. Every step of that, the eligibility check and the setup walkthrough, was something a person had to do by hand, even though both are mechanical enough to automate: the eligibility answer comes straight from the subscription record, and the setup steps are the same every time.
The procedure checks the customer's current subscription status first. If their plan is inactive or below the required tier, it says so directly and stops there, no download, no false promise. If they qualify, it delivers the bundle download link along with the specific setup requirements (the device, software, and API key steps needed) and a verification step to confirm the connection actually works before considering the case closed. Anything that doesn't fit cleanly, a plan type the eligibility check can't classify, or a technical error during setup, hands off to a person instead of guessing.
Over 90 days, 11 conversations triggered the procedure, and all 11 were reviewed individually rather than sampled, so this is a complete picture of every time it ran, not an estimate.
Counting the correctly-declined ineligible cases as handled (Fin resolved them fully, it just resolved them with a "no"), 6 of 11 conversations, 55%, needed zero human involvement.
The four handoffs split into two distinct, identifiable causes rather than one vague "sometimes it fails." One was a genuine edge case: a customer on a high-spend custom annual contract got an initial ineligible response because their plan didn't match the standard tier logic, and only escalated correctly once they cited their contract terms directly. The other three all hit the same wall after getting the download link: a missing setup element on the bundle product itself was blocking them partway through configuration, a product-side gap the procedure has no way to resolve on its own, so it correctly recognized the dead end and handed off rather than leaving the customer stuck.
Eleven conversations over 90 days is a small sample, and the 55% self-serve and 36% handoff rates are directionally useful more than statistically solid. A few more edge cases either way would shift the percentages meaningfully. If MCP bundle requests are expected to run at higher volume elsewhere, it's worth confirming the procedure is actually triggering on every relevant conversation before trusting these numbers as a baseline.
Reviewing every single conversation instead of sampling is what turned four generic "handoff" events into two specific, fixable causes: one narrow eligibility-logic gap for non-standard contracts, and one product-side setup gap unrelated to Fin's own logic at all. At this volume, a full population review is not just possible, it's the only way to get a real root cause instead of a percentage with no explanation behind it. That distinction, resolved-with-a-no counting as a real resolution, and every failure traced to a specific, nameable cause, is what separates a procedure that's actually understood from one that's just being monitored.