Ticket source-based routing (chat vs email vs form)

Outcome. Tickets route to a pool sized and skilled for their originating channel, so a chat conversation expecting a fast reply does not sit behind a backlog of async email tickets.

Workflow map Enrollment, branches and actions at a glance tickets-sla-011

flowchart TD
    A[Ticket created, source known] --> B{Ticket source value?}
    B -->|Chat| C[Rotate to Chat pool, priority Medium]
    B -->|Email| D[Rotate to Email pool]
    B -->|Form| E[Rotate to Forms pool]
    B -->|Phone/API/other| F[Rotate to General pool]
    C --> G[Set routed date]
    D --> G
    E --> G
    F --> G

When to use it, when not to

• UseUse it when different channels need different response speed or skill, for example live chat expects a near-immediate reply while email tickets can queue.
• UseUse it as one input among several if product or category also matters; see Variants for combining signals.
• SkipDo not use it as your only routing signal if it leaves a channel's pool without the skill to handle what actually came in; pair it with product or category routing where needed.
• SkipDo not use it if every channel already feeds the same pool with the same expectations; there is nothing to differentiate.