A handoff that triggers too early makes your agent feel unreliable. A handoff that triggers too late leaves users stuck in a loop with no way out. The difference between the two is almost always in how the trigger was written.

Two things go wrong with badly written triggers. The first: a customer asks a general question about billing and gets transferred to a human immediately, because the trigger fires on any mention of billing. The human picks up a conversation that the agent could have handled. The second: a customer who is clearly frustrated and has asked the same question three times never gets escalated, because the trigger was written too narrowly and the agent keeps trying to resolve it alone.

The trigger is a plain-language description of exactly when your agent should bring in a real person. Write it right and handoffs happen at the right moment, every time. This article shows you how.

In this article, you'll learn:

• How handoff triggers work
• What makes a trigger too broad or too narrow
• How to write triggers that are specific and reliable
• Examples of good and poor trigger instructions

How Handoff Triggers Work

When your agent processes a user's message, it reads the trigger instructions for every configured handoff and decides whether the current moment matches. If it does, it initiates the handoff.

You write triggers in plain language - no code, no rules engine. You describe the situation, and your agent uses that description to make the call.

This gives you a lot of flexibility. It also means the quality of your trigger instructions directly determines how well your agent escalates.

What Makes a Good Trigger

A good trigger is specific about intent, covers natural variations, and sets clear boundaries.

Be Specific About Intent

Don't describe surface-level keywords - describe what the user is actually trying to do or how they're feeling.

✅ Good: "Hand off when the user explicitly asks to speak with a human, requests a real person, or says they want to talk to someone on the team."

❌ Poor: "Hand off when the user says 'human' or 'person'."

The poor version misses phrases like "I need to talk to someone" or "Can I get some real help?" The good version captures the intent regardless of exact wording.

Cover Natural Variations

Users phrase things differently. Think about the range of ways someone might express the same need.

✅ Good: "Hand off when the user is clearly frustrated, upset, or expresses dissatisfaction with the responses they've received - including phrases like 'this isn't helping', 'I give up', 'you're useless', or repeated expressions of the same issue without resolution."

❌ Poor: "Hand off when the user is angry."

"Angry" is one word. The good version covers the full range of frustration signals your agent might encounter.

Set Clear Boundaries

Tell the agent both when to escalate and when not to. Boundaries prevent unnecessary handoffs.

✅ Good: "Hand off when the user asks about billing disputes, refund requests over $100, or account cancellations. Do not hand off for general billing questions that can be answered from the knowledge base."

❌ Poor: "Hand off for billing questions."

The poor version would trigger a handoff every time someone asks "How does billing work?" - a question your agent can almost certainly answer itself.

Include a Fallback Condition

If your agent genuinely can't resolve an issue after trying, it should escalate rather than loop. Always include a fallback condition:

✅ "Also hand off if the agent has attempted to answer the same question more than twice without resolving it to the user's satisfaction."

This prevents users from getting stuck in an unhelpful loop with no way out.

Full Example: A Well-Written Trigger

Here's what a complete, well-written handoff trigger looks like:

"Hand off to the support team when:

• The user explicitly asks to speak with a human, a real person, or a member of the team
• The user is visibly frustrated, upset, or has expressed the same issue more than twice without resolution
• The conversation involves a billing dispute, refund request, or account cancellation
• The user asks a question that is clearly outside the scope of what Outlearn can answer

Do not hand off for:

• General product questions that can be answered from the knowledge base
• Simple FAQs or how-to questions
• Users who express mild confusion but haven't asked for human help"*

This trigger is specific, covers multiple scenarios, sets clear exclusions, and gives the agent enough context to make good decisions in ambiguous situations.

Testing Your Triggers

Always test your handoff trigger before going live:

1. Open the Preview panel.
2. Send messages that should trigger the handoff and confirm it activates.
3. Send messages that should not trigger the handoff and confirm it doesn't.

If the handoff fires when it shouldn't, tighten the trigger or add exclusions. If it doesn't fire when it should, broaden the language or add more trigger conditions.

Best Practices

• Read your trigger out loud. If it sounds ambiguous to you, it will be ambiguous to your agent.
• Include at least one explicit "user asks for a human" condition in every handoff trigger - this is the most reliable signal and should always be covered.
• Revisit triggers after the first week of live conversations. Check the Handoff Reasons section in Analytics to see what's actually triggering handoffs and refine accordingly.
• If you have multiple handoffs configured (e.g., Intercom for live support and Zendesk Ticketing for after-hours), make their triggers mutually exclusive so the agent knows which one to use in each situation.