Fin or human agent: which conversations to route to AI
Most teams switch Fin on for everything, then pull back after the first incident. The right call isn't about what Fin can do, it's about what its mistakes cost.
Most teams ask "what can Fin handle?". Wrong question. Fin can handle almost any request whose answer already lives in your knowledge base. The real question is what it costs you on the day it gets one wrong.
The only trade-off that matters
Routing a conversation to AI is a bet that the saving of one human minute outweighs the expected cost of a mistake. That expected cost isn't a gut feeling, it's arithmetic: probability of a wrong answer multiplied by what a wrong answer sets off.
Across the accounts we observe, the probability of a wrong answer sits around 18% of handled volume. So what varies between queues isn't Fin's reliability, it's the second term. A mistake on "how do I export my data" costs one follow-up message. A mistake on "am I still being billed after cancelling" costs a dispute, sometimes a customer.
The rule in one line
If you can't say what a wrong answer costs on a given queue, you can't decide to route it. Start by pricing the mistake, not by flipping the switch.Four families, four decisions
Route without hesitation
Requests whose answer is factual, public and stable: opening hours, accepted file formats, export procedure, password reset, the difference between two plans. The answer lives in an article, it doesn't depend on the account, and a mistake is fixed in one message.
Route with a safety net
Factual but account-dependent requests: "why has my integration stopped syncing", "where is my order". Fin can answer, but the conversation must escalate automatically the moment the customer follows up a second time. The net isn't about trusting Fin, it's about the customer's patience running out.
Never route
- Disputed billing and cancellations. A wrong answer about an amount is a dispute, not a ticket.
- Live incidents. During an outage the knowledge base is stale by definition. Fin will confidently answer that everything works.
- Anything touching security or personal data.Access, account deletion, a suspected breach. The cost of a mistake is regulatory.
- High-value contract customers. Not because their questions are harder, but because their tolerance for a generic answer is zero.
The ambiguous case, and how to settle it
One grey zone remains: product questions, the ones starting with "can your tool do". They're factual, the answer exists, and yet a mistake is expensive, because these are often prospects. Our position: route them, but score those conversations systematically and review them weekly. It's the one family where the decision should be revisited on data rather than settled once and for all.
Decide on your data, not ours
The four families above are a starting point, not a verdict. Adapting them needs a per-queue measurement: what share of Fin-handled conversations gets reopened, and on which topics. Seven-day reopen rate is the best available proxy, because it captures exactly what dashboards miss, a closed conversation the customer had to chase.
That's what ResponZ quality scoring does: every Fin answer is scored, and the queues where the score collapses surface without anyone reading conversations one by one.
What changes after three months
The initial scope is almost always too wide. Teams that succeed shrink Fin's scope within the first six weeks, then widen it again slowly, queue by queue, as the knowledge base fills in. Teams that fail do the opposite: they keep the scope wide and compensate with manual escalation, which cancels out the saving they were after.
Fin isn't a switch. It's a scope you adjust, with a measurement next to it.