What does Intent mean in Router?

An intent describes what the user is trying to do, ask, or achieve.

In the Router node, each intent represents one possible path the conversation can take.

For example, you might create intents for:

• Pricing questions
• Product support
• Booking requests
• Order status
• Sales inquiries
• Human support

The Router reads the user's message and chooses the route whose intent description best matches what the user needs.

Why intents matter

Intents tell the Router:

“Which path should this conversation follow?”

Each intent becomes a connection point on the Router node.

You connect that intent to the node or workflow that should handle that type of request.

For example:

1Pricing → AI Answer
2Book appointment → AI Answer with Book appointments enabled
3Support → Human Handoff

What you configure for each intent

Each Router intent has two important fields:

Intent name

The Intent name is for you and your team.

It helps you identify the route on the canvas.

Examples:

1Pricing
2Technical Support
3Book Appointment
4Existing Customer

The AI does not use the intent name to decide which route to choose.

When should AI choose this route?

This description tells the AI when that route should be selected.

This is the part the Router actually uses when interpreting the user's message.

Example:

1Intent name:
2Pricing
3
4When should AI choose this route?
5Choose this route when the user asks about pricing, plan costs, fees, subscriptions, or how much a product or service costs.

A clear route description usually produces better routing than relying on a short label alone.

How Router chooses an intent

When a message is evaluated by Router:

1. The Router reads the user's message.
2. It compares the message with the configured route descriptions.
3. It selects the best matching intent.
4. The conversation continues through the node connected to that intent.

If no configured intent is a good match, Router uses Fallback.

Fallback

The last intent in Router is always Fallback.

Fallback catches messages that do not clearly match any of the routes above it.

Use Fallback for:

• General questions
• Unclear requests
• Unexpected topics
• Anything that does not belong to a defined route

You do not need to create a separate broad “General” intent just to catch everything else if Fallback already serves that purpose.

New intents are added above Fallback.

Router modes

Router can work in two different modes.

Every message

Every message is the default mode for new Router nodes.

In this mode, Router evaluates each new user message.

This means the conversation can switch paths if the user's intent changes.

Example:

1User: What does your service cost?
2→ Pricing route
3
4Later:
5User: I actually need help with my account.
6→ Support route

Use Every message when users may move between different topics during the same conversation.

First message only

In First message only mode, Router chooses a path from the user's first message.

After that, the conversation stays on that route.

Example:

1User: I need help booking an appointment.
2→ Booking route
3
4Later messages remain in the booking path.

Use this mode when the first message should determine the workflow for the rest of the conversation.

How specific should intents be?

An intent should be specific enough that the Router can clearly distinguish it from the other routes.

Good example:

1Intent name:
2Order Status
3
4Description:
5Choose this route when the user wants to check the status, delivery progress, or current location of an existing order.

Another route might be:

1Intent name:
2Returns
3
4Description:
5Choose this route when the user wants to return, exchange, or request a refund for an existing order.

These are easier to distinguish than two vague routes such as:

1Order Questions
2Customer Help

Avoid overlapping route descriptions

If several intents describe almost the same request, routing becomes less predictable.

For example, avoid having:

1Pricing
2Plan Questions
3Subscription Questions

if all three descriptions cover the same pricing-related messages.

Instead, combine them into one clear route unless they genuinely need different workflows.

Write descriptions around user behavior

Describe what the user is likely to say or mean.

Better:

1Choose this route when the user asks about plan prices, monthly fees, annual pricing, or the cost of upgrading.

Less useful:

1Pricing route.

The description should give the AI enough context to distinguish this route from the others.

Intent name vs. route description

A simple way to remember the difference:

Intent name = label for your team

Route description = instructions the AI uses

The intent name helps keep the workflow organized.

The description determines when the route should be chosen.

Example Router setup

A service business might configure:

Pricing

1Choose this route when the user asks about prices, fees, packages, or how much a service costs.

Book Appointment

1Choose this route when the user wants to book, reschedule, or ask about appointment availability.

Existing Customer Support

1Choose this route when an existing customer needs help with a current service, account, or issue.

Fallback

Used when none of the configured routes clearly apply.

Each route can then connect to the node best suited to handle that request.

Best practices

• Give each intent a clear internal name.
• Put the real routing logic in When should AI choose this route?
• Describe what the user means, not just a category label.
• Keep routes distinct from one another.
• Avoid unnecessary overlap.
• Use Fallback for unmatched or unclear messages.
• Use Every message when users may change topics.
• Use First message only when the first request should determine the entire path.
• Test the Router with different ways a user might phrase the same request.

Simple rule

Intent = what the user wants

Router = chooses the path that best matches that intent

Fallback = catches what does not clearly match