> ## Documentation Index
> Fetch the complete documentation index at: https://docs.custral.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Chat Routing

> Decide which team or user picks up an inbound chat.

## Overview

When a visitor sends their first message, Custral assigns the Conversation to a
user using the chat channel's **routing rules**, and adds them to the
conversation as its agent. The default channel for chat is the workspace-wide
chat Channel; create per-page or per-segment Channels for finer routing.

Chat uses the same routing engine as email, SMS and voice, see
[Routing Rules](/comms/inbox/routing) for the full behaviour, including
availability gates and the 30-day analytics on each rule.

## Rule evaluation

Rules are evaluated top-down on the first inbound message, and the first rule
that matches **and can name an available agent** wins. Rules match on:

* Day of week, time of day, and an optional date range (in the workspace
  timezone).
* Whether the candidate is online, under their open-conversation cap, and holds
  the skills the rule requires.

If no rule produces an agent, Custral falls back to the channel's own people,
whoever the channel says works it, and leaves the conversation unassigned only
when it names nobody. Where that is a team, the team's own sharing setting picks
which member, exactly as a rule naming it would.

<Note>
  Matching on visitor attributes or the page URL the visitor is on is not supported today. Use separate chat Channels
  per page or segment, each with its own rules, to get the same effect.
</Note>

## Hand-off and load

Point a rule at a **team** and the team decides how its work is shared, evenly,
by load, or on shifts. Set once on the team rather than on each rule. Agents who
are offline or at their cap are skipped when the rule gates on those.

## Assigned, or offered

A chat that names one person is **assigned** to them. A chat that names several
is **offered** to all of them, belongs to nobody until someone replies, and the
first reply claims it. A claim never takes a chat from a colleague who got there
first. See [Routing Rules](/comms/inbox/routing) for the full table.

Answer-bot chats are deliberately not counted against anyone's open-conversation
cap while the bot is holding them, so a busy bot cannot make a human look busy.

## Bot first, human second

A common pattern is to have an AI Agent handle the first message and only
escalate to a human when needed. Set up a workflow that triggers when a
conversation is created and hands it to a chat agent; when the agent decides to
escalate, it routes the Conversation to a rule pointing at a team that is on
shifts. See [on-call](/team/on-call). Until the bot escalates, the chat is not
assigned to a person at all.

## Next steps

* [Routing Rules](/comms/inbox/routing): actions, gates, and troubleshooting.
* [Widget Install](/comms/chat/widget-install): getting the widget on your site.
* [Visitors](/comms/chat/visitors): what Custral knows about who is chatting.


## Related topics

- [Routing Rules](/comms/inbox/routing.md)
- [Chat & Widget](/comms/chat/overview.md)
- [widget.conversation.started](/dev/webhooks/events/widget-conversation-started.md)
- [Record Routing](/surfaces/records/overview.md)
- [conversation.assigned](/dev/webhooks/events/conversation-assigned.md)