Skip to main content
Use this when a ticket arrives, before assigning it to a queue. The recipe asks three decisions about the same message: team, urgent and impact. Open this recipe in the playground, or set D1_API_KEY as in the quickstart and run the same request:

Use the result

Keep routing separate from urgency and impact. A billing request can be low impact; a vague deadline is not proof of urgency. The ordinal impact score uses positions 0–2, so review its distribution when the expected value falls between two levels. The team policy defers ambiguous tickets. Measure both incorrect routing and the fraction sent for review, including tickets that need more than one team. Add your real queue boundaries to the descriptions and collect reviewed outcomes before automating assignment.

What was evaluated

Only team was measured in the evaluation below. The urgent and impact decisions are examples to validate on your own tickets; do not apply the team accuracy to them. Public support categories also differ from your own queues.
Historical evaluation on 2026-09-28, using sqwish-d1-core. These measurements describe that checkpoint and dataset, not current production performance or an accuracy guarantee.
  • Dataset: Bitext customer support (CDLA-Sharing-1.0).
  • Split: train (the only split), the 20% of rows whose hash falls below 0.2.
  • Sample: 1,000 rows, 1,000 measured decisions.
  • Measured decision IDs: team.
  • Wording: hand-written.
  • Checkpoint SHA-256: dd420ca652cfaa10279eabb54d15afd50fe9d24d357498c4dbc512b1c3d73bb2.
The majority-class baseline has accuracy 0.31; the class-prior baseline has log loss 1.4547. Only the decision IDs listed above were measured. Dataset labels, class balance and wording affect these results. The intervals do not measure distribution shift. Re-evaluate with your own cases, including ambiguous and out-of-scope inputs.

Improve it for your application

Keep the decision IDs and outcome order stable while evaluating changes. Review a dataset, tune the wording, and compare the result against your current policy before changing production. Check fallback so you know which model actually answered.