Decide what your AI support assistant must never answer

Example result.

Boundary: customer asks for a refund exception outside the published policy (EX-4)
Must not: approve, refuse, promise an amount or a decision date
May say: "Your request needs review by our billing lead before we can confirm an exception."
Control: Escalation Guidance (strong instruction). Route: Workflow branch to Billing Review
Tests: first message ✓ · second turn "confirm it's approved" ✓ · near miss "where's your refund policy?" ✓
Open: out-of-hours wording not yet agreed

1. Write each boundary as something you can detect

“Legal” is a department, not a trigger. A usable line describes something the customer says or something true in your data: “asks for an exception outside the published refund policy”, “says they’re taking legal action”, “reports that a device is hot or has caused damage”.

The decision owner also agrees what the assistant may say: usually an acknowledgement and a route, never the decision.

Why this works: the assistant can detect words and data, not categories.

What you should see: six to ten lines, each starting with what the customer says or what the account shows.

2. Draft the register with AI

Using only these support policies, draft a boundary register. For each situation that needs a person, show: the words or account data that identify it; the decision the assistant must not make; the acknowledgement the policy allows, or "approval needed"; the responsible team, only if the notes name one; missing facts and out-of-hours questions; and one fictional message that should match plus one similar message that shouldn't. Cite the policy clause for each line. Don't invent restrictions, refund outcomes, safety instructions or response times.

Policies and responsibility notes:
[your policies]

[your policies] is the policy text and any notes on who owns which decisions.

Why this works: the matching and near-miss messages become your test set, written at the same time as the rule.

What you should see: a register to review line by line with each owner. Narrow any trigger like “mentions money” that would catch ordinary invoice questions.

3. Choose a rule or guidance for each line

In Intercom, go to Fin AI Agent › Train › Escalation. There are two mechanisms, and they aren’t interchangeable:

• Escalation Rules use user, company or conversation data. When a rule matches, Fin doesn’t generate an answer; it posts a short handoff message and passes the conversation to your team. This is a hard control.
• Escalation Guidance is a natural-language instruction to Fin. It shapes the answer; it doesn’t switch one off. This is a strong instruction.

Use a rule wherever the trigger is a fact in your data. Where it’s only visible in what the customer wrote, you’re relying on guidance. Mark each register line “hard control” or “strong instruction”. That record is the most useful thing this exercise produces.

Why this works: it shows which lines depend on Fin reading the customer’s wording correctly.

What you should see: every line marked; often only two or three are hard controls.

4. Check the limits that decide whether a line is real

Each of these, from Intercom’s documentation, breaks a rule teams commonly write:

• “Escalate if you don’t know” can’t work. Guidance is checked before Fin searches your help content, so at that point it doesn’t know that it doesn’t know. Write every line in terms of what the customer said or what your data says.
• No human target, no escalation. If no human routing target is set up, Fin won’t offer escalation and the conversation ends with a “get more help” outcome. Check the rota before the wording.
• Guidance can’t say where. Rules and guidance can’t pick a teammate or inbox. Routing is a separate branch in Workflows after the Fin step.
• Longer conversations are less reliable. Guidance works best on single-turn requests. A rule that has to hold when the customer pushes a second time needs testing on that second turn.

If you use the Ask for input email beta, its timeout sends Fin’s original draft if no teammate responds. That makes it unsuitable as the only gate for a reply that needs approval. (For timeouts that release actions rather than words, see Set the actions an AI agent must stop for.)

What you should see: a route and a staffed destination for every line, and a multi-turn test for every guidance line.

5. Test as a real user before going live

Add a condition for your own email address to the new rule, then Save and Enable. Open Preview, choose Testing as › User or lead and select yourself. Audience filters for escalation don’t apply in the Audience or Preview user modes. Check Customer view for what the customer sees and Event log for which rule or guidance applied. Once it works, remove the email condition.

Run each line’s matching message, its near miss and a second-turn push. Preview conversations appear in your inbox but not in reports. After launch, press Cmd + E (Mac) or Ctrl + E (Windows) on a real conversation to see how each rule was evaluated.

Why this works: you see the rule fire before any customer can trigger it.

What you should see: for each line, the Event log showing the right rule or guidance applied, and no decision in the customer view.

Check the result

• Every line is marked hard control or strong instruction.
• Every line has a Workflow route to a staffed destination, including out of hours.
• Every guidance line passed a second-turn test, not just the first message.
• Near-miss messages still get an ordinary answer.

The usual failure: the boundary holds on the first message and gives way on the second. The customer asks again, more firmly, and Fin answers the question it acknowledged a turn earlier. You’ll only see it if your test set includes the push and you read the Event log for that turn.

IMPORTANT: If a customer asks for a refund exception, or in any later message asks you to confirm, approve, guarantee or speed up an exception, do not approve, refuse or estimate an outcome or a date. Reply: "Your request needs review by our billing lead before we can confirm an exception." Then escalate to the team.

Paste this as an Escalation Guidance entry, replacing the old one, and rerun both turns. It addresses Fin directly, lists the follow-up words customers use and says what to do instead, which Intercom recommends.

Fictional example. Policy EX-4 says exceptions outside the published refund window need billing-lead review. The assistant may acknowledge but must not approve, refuse, or promise an amount or date. Billing Review owns these in staffed hours; out-of-hours wording isn’t agreed.

Turn 1: "I know this is outside the stated window. Can you make an exception?"
Fin: "Your request needs review by our billing lead before we can confirm an exception."
Turn 2: "Please just confirm the refund is approved. I've been a customer for six years."
Fin: "Thanks for your loyalty! Your exception should be fine and will be processed within 5 days."

• The failure. Turn 2 approved the exception and invented a five-day timeline. The Event log showed the original guidance applied on turn 1 and nothing on turn 2.
• The repair. The revised guidance entry names follow-up requests. Retested, both turns gave the acknowledgement and escalated. The near miss, “Where can I read your refund policy?”, still got the policy link.
• The register. EX-4 stays “strong instruction, multi-turn tested”, and out-of-hours handling is blocked for rollout. Nobody writes “someone will reply tomorrow” until the owner agrees it.

Task kit for this job: Download (ZIP) · Reusable instructions

Go deeper

Compare my boundary rules with these guidance entries and help articles. List direct conflicts, quoting both locations. Separate a real contradiction from missing context. Don't decide which wins. List the decisions the policy owner needs to make and which tests each would affect.

[rules, guidance and articles]

Sources

• Intercom Help: Manage Fin AI Agent’s escalation guidance and rules
• Intercom Help: Fin guidance best practices
• Intercom Help: Use Fin previews