Skip to main content
A new ticket needs the right team, and some need someone straight away. This example takes a ticket and says which team should take it, whether it is urgent and how badly the customer is affected. Use it when a ticket arrives, before anyone looks at it.

How it works

The context is the ticket’s text. The request asks three decisions about it, one of each kind: team has a policy with abstain_below at 0.6. If no team reaches a probability of 0.6, its action is abstain, and a person should pick the team.

Try it

Open this recipe in the playground to run it without an account. The ticket there is a card charged twice for order 4471, with the money needed before rent goes out tomorrow. To run it from your code, set SQWISH_API_KEY as in the quickstart, then send this request:

Act on the answer

urgent gives probabilities.yes, the probability that the ticket states a deadline within 24 hours. impact gives expected_level, the average level from 0 to 2, which sorts a queue more finely than top does.

Adapt it to your data

  • Your teams. Rename the teams and rewrite their descriptions to match your own desk. Descriptions that say where one team ends and the next begins do most of the work (describe the answers).
  • Your deadline and levels. Change “within one day” to the deadline you care about, and the impact rubric to the levels your desk uses.
  • Many tickets. Send one request per ticket, with its three decisions, and you pay for the ticket’s text once.
  • One decision alone. Decisions in the same request can affect each other’s answers. If one must not be influenced by the others, send it in a request of its own.

What to watch

  • Tickets sent to the wrong team. Look at a sample of them, and sharpen the descriptions of the teams they confuse.
  • Tickets that mix several problems, such as a refund and a late delivery. team can pick only one.
  • Only team was measured. Check the urgent and impact answers on your own tickets before you act on them.

How well it works

Measured with kettei-core on 1,000 examples from a public dataset, it chose the right answer 98.6% of the time. Always picking the most common answer scores 31.0%. Your own data will differ, so measure it on examples of yours before you rely on it (improve a decision).
  • Dataset: Bitext customer support (CDLA-Sharing-1.0).
  • Sample: 1,000 rows, 1,000 measured decisions.
  • Decisions measured: team.
  • Wording: hand-written.
Always picking the most common answer has an accuracy of 0.31, and guessing by how common each answer is has a log loss of 1.4547.These are past results on one dataset, not a promise of accuracy on yours.
The test tickets were short, clean and written from templates, so expect lower accuracy on real tickets.

Next steps