Fin AI's Escalation Rules vs. Guidance: What Actually Controls the Handoff

Most businesses running Intercom's Fin AI Agent get the basics of setup right. They connect a help center, write some guidance, turn Fin on, and watch the resolution rate. What trips people up is the moment Fin decides a conversation isn't for it anymore. That decision is controlled by two separate mechanisms that look similar on the surface but behave very differently: Escalation Rules and Escalation Guidance. Mixing them up, or only using one, is one of the more common reasons a Fin setup either escalates too much or not enough.

Two Different Ways to Say "Hand This Off"

Escalation Rules are built for structured data. You set a condition, such as sentiment being negative, an issue type matching a specific category, or a custom field crossing some threshold, and when that condition is met, Fin stops trying to answer and routes the conversation to your team. Rules live under Train > Escalations, and each one is scoped to an audience and a set of channels, so you can apply a stricter rule to logged-in customers and a looser one to anonymous visitors if that fits your business.

Escalation Guidance works differently. Instead of a condition tied to a data field, you write a plain-language instruction describing a scenario, and Fin interprets it in context. "If a customer says they are considering canceling, offer to connect them with a human right away" is a Guidance instruction, not a Rule, because there's no structured field called "considering canceling." Guidance can tell Fin to escalate immediately, offer an escalation instead of forcing one, ask a clarifying question first, or in some cases avoid escalating at all when a topic seems urgent but isn't.

Both sit on top of Fin's own default escalation behavior, and both are capable of overriding it. That's the part worth sitting with: if you write a Rule and a Guidance instruction that contradict each other, you don't get an average of the two, you get unpredictable behavior depending on which one Fin weighs more heavily in that conversation.

Why This Distinction Actually Matters

The practical difference comes down to what you're trying to control. If the trigger is something your system already tracks (order value, account tier, a tag applied by a workflow), a Rule is the right tool because it's deterministic. It either fires or it doesn't, and you can audit it later by checking the data.

If the trigger is something only visible in the language of the conversation (frustration, confusion, a customer describing a problem that doesn't map cleanly to your categories), that's Guidance territory. Trying to force that into a Rule usually means inventing an intermediate classification step that doesn't really exist, which adds fragility instead of removing it.

A setup that only uses Rules tends to under-escalate: Fin keeps trying to resolve a frustrated customer because nothing in the structured data told it to stop. A setup that only uses Guidance tends to be inconsistent, because natural-language instructions can be interpreted differently depending on how a conversation unfolds. The setups that hold up well use both, with Rules handling the objective triggers and Guidance handling the judgment calls.

Writing Guidance Fin Won't Misread

Since Guidance is natural language, how you write it matters more than people expect. A few patterns make a real difference in how reliably Fin follows an instruction:

Write one instruction per piece of Guidance instead of bundling several conditions together. "Escalate if a customer mentions a refund AND has contacted us twice before AND seems frustrated" is harder for Fin to apply consistently than three separate, focused instructions.

Use conditional language directly: "if," "when," "then." Vague phrasing like "be careful with upset customers" leaves too much room for interpretation. A concrete example inside the instruction, showing exactly the kind of message that should trigger it, closes most of that gap.

Address Fin directly rather than describing it in the third person, and if a rule is genuinely non-negotiable, say so plainly rather than softening it. Fin is more consistent with direct, unambiguous instructions than with hedged ones.

Avoid chaining instructions, where one piece of Guidance is written to trigger another. That kind of dependency is difficult to predict and even harder to debug when something goes wrong six weeks later.

Testing Before It Goes Live

Every Escalation Rule and every piece of Guidance should be run through Preview Mode before it goes live, using real examples pulled from actual past conversations rather than made-up test cases. Past conversations expose the messy phrasing real customers actually use, which is exactly where Guidance tends to fail if it was written too narrowly.

It's also worth periodically checking for contradictions between active Rules and Guidance, especially as a workspace accumulates more of both over time. A Rule written six months ago for one team's workflow can quietly conflict with Guidance someone added last week for an unrelated reason. Since both types can override Fin's default behavior, an old and unnoticed conflict is often the real explanation behind a resolution rate that dropped for no obvious cause.

Getting the Balance Right

There's no universal ratio of Rules to Guidance that works for every business. A service business handling high-value accounts usually leans more on Rules, because the trigger conditions are already sitting in their CRM data. A company handling a wide variety of unpredictable requests usually leans more on Guidance, because too much of what matters can't be reduced to a data field. Most businesses end up somewhere in between, and the setup gets better over time as you look at which conversations escalated, which ones should have but didn't, and adjust both layers accordingly.

Getting this right the first time is harder than the documentation makes it look, mostly because the failure mode isn't an error message, it's a slowly declining resolution rate or a customer who churns after a frustrating loop with the bot. If you're setting this up for your own business, or you're a consultant setting it up for clients, it's worth treating escalation design as its own project rather than an afterthought tacked onto the initial Fin configuration.

This is the kind of tuning work I do for businesses running Intercom and Fin AI, and it's also exactly what I cover in The Intercom & Fin AI Setup Playbook, a 44-page guide with business-type-specific escalation checklists and ready-to-adapt Guidance templates. You can grab it directly on nevilpaul.com or through my Whop storefront. If you'd rather have someone set this up for you, feel free to get in touch.

Cover photo by Charanjeet Dhiman on Unsplash.