Why Does Intercom's Fin AI Forward Complicated Requests to a Human Instead of Resolving Them?
Fin doesn't forward legal and refund questions because it senses they're above its authority. Intercom's own article on managing Fin's escalation guidance and rules describes two separate mechanisms working together, a small set of default behaviors that fire with zero configuration and a layer of rules and plain-language guidance that an admin writes on purpose. A complicated request gets handed to a person because one of those two things is doing exactly what it was set up to do.
Fin's defaults only cover three situations, a customer explicitly asks for a human, Fin detects strong frustration, or the customer keeps repeating the same point across several turns. None of the three mention refunds or legal exposure by name. A commenter on Hacker News described this from the outside, noting that Fin "can't handle legal/refund/complicated requests and just forwards to a human for those." Since neither refunds nor legal issues appear in Fin's defaults, that forwarding has to come from one of the two mechanisms a workspace configures on purpose, an Escalation Rule or Escalation Guidance written in plain language. Fin isn't hitting a wall on its own. It's following an instruction someone gave it.
Three ways a handoff gets triggered
Intercom's escalation documentation splits the mechanism into three layers:
- Default behavior, no setup required: a direct request for a human, detected frustration, or a customer stuck in a repetitive loop.
- Escalation Rules, which fire on structured data: a "Negative" sentiment score, an issue type of "Bug," conversation data with an order total over a set amount, or a custom field like a VIP flag.
- Escalation Guidance, written in ordinary sentences: telling Fin to escalate the moment a customer uses frustrated language like "ridiculous" or "waste of time," to offer a human agent when the same question comes up twice, or to hand off as soon as a competitor's name enters the conversation.
Legal and refund routing doesn't appear by name in Intercom's own examples for either configured layer. But it has to come from one of those two, since defaults don't cover it and there's no third option. A support lead writes a rule or a guidance sentence describing the scenario, Fin checks every incoming conversation against it, and a match triggers a handoff before Fin attempts an answer at all. That's a deliberate guardrail, not a limitation Fin discovered mid-conversation.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionA refund that Fin correctly won't touch
Picture an online retailer of work boots and outdoor gear. Fin handles the bulk of shipping and sizing questions on its own, pulling from the help center the support team keeps current. Refunds are a different story, on purpose: the team wrote Escalation Guidance months ago telling Fin to hand off any request involving a refund, a damaged item, or a return outside the standard 30-day window.
A conversation comes in on a Tuesday from a customer whose steel-toe boots arrived with a cracked sole two months after purchase, past the return window, but with an obvious manufacturing defect. The customer wants a refund, not store credit. Fin recognizes the refund language and the damage claim, matches the guidance, and hands the conversation off without attempting an answer. The customer sees a short note that a teammate is joining, and the conversation lands in a queue with the full history attached, including the exact wording of the complaint and the fact Fin never replied to it.
The teammate who picks it up doesn't need Fin's help to see what's going on. A defect that shows up after two months of wear is a warranty question, not a return-window question, and the refund gets approved the same day.
Fin made the right call here. A two-month-old defect claim needs judgment about warranty coverage that a help-center article can't fully anticipate, and a wrong autonomous refund decision is the kind of mistake a business wants a person to own. The system worked as designed. What happens to that conversation after it closes is a separate question.
Why Fin doesn't just decide these on its own
Fin answers by retrieving from connected content, your help center, prior conversations, synced product data, and composing a reply from what it finds there. It has no independent authority to issue a refund, waive a policy, or render a legal opinion unless someone has built a specific Action for that purpose and Fin calls it. Absent that, the honest move is escalation, not a guess. Intercom's own documentation on how resolutions are measured reinforces this from the resolution side: if "Fin was not able to answer using your content and teammate jumps in to reply," that isn't billed as a resolution at all. The product is built around Fin knowing what it doesn't know, not around it stretching to cover gaps.
That's also why legal and refund categories show up in Escalation Rules or Escalation Guidance so often, once a workspace configures one or the other. A support lead who's been burned once by an AI-issued refund the finance team had to claw back writes the rule or the guidance sentence exactly once, and every future refund conversation routes to a person before Fin drafts a reply.
The pattern hiding in five closed conversations
Handing the conversation off is the correct ending for Fin's part of the job. It's also where the paper trail usually stops being useful. The conversation gets a reply from a teammate and closes. Nothing connects it to the other four defect complaints about the same boot model that came in the same month, because each one escalated separately and each teammate who handled one had no reason to go looking for the others. A pattern that should reach the product or supplier relations team stays scattered across closed tickets instead.
That gap has nothing to do with resolution pricing or escalation logic, and everything to do with what happens after a human closes the conversation. That's the point where Modem fits. Its Intercom integration reads every conversation regardless of how it ended, whether Fin resolved it outright, escalated it under a rule or a guidance sentence, or a teammate handled the whole thing from the first message, and pulls out what the customer was actually asking for. Five defect complaints about the same boot model, filed across five separate Fin handoffs over a month, cluster into one topic with all five customers attached instead of five closed tickets nobody cross-references. That topic can file as a Linear, Jira, or GitHub issue for the product team, carrying the requester list so a fix or a recall notice can reach the people it actually affects.
Modem is also the company that wrote this guide and sells the tool just described, a fact worth keeping in view rather than skipping past. It isn't a Fin alternative and it doesn't change when or why a conversation escalates. The escalation logic covered above, and the honest tradeoffs of tuning it, are worth getting right on their own terms; that's a separate exercise from making sure what gets escalated doesn't disappear once it's marked closed. Fin's cost structure around escalated versus resolved conversations is covered in why Fin AI is so expensive per resolution, and the tagging habits that carry a support team a long way before a tool like Modem is worth it are in how to track feature requests in Intercom.
The short version
Fin forwards legal, refund, and otherwise complicated requests because a default behavior or a rule someone configured told it to, not because it hit an unexpected limit. The defaults cover explicit human requests, frustration, and repetition; everything else, including most refund and legal routing, comes from Escalation Rules or Escalation Guidance an admin wrote deliberately. That's the correct design for conversations that need judgment a help article can't supply. The part worth fixing separately is what happens to those escalated conversations afterward, since a real pattern hiding across several individually-closed handoffs is exactly the kind of signal that's easy to lose once each one lands in a different teammate's queue.
