Support ticket routing

Send each support message to the team that can resolve it.

Problem

Messages land in one queue and someone spends the first minutes of every ticket working out who should own it. Misrouted tickets bounce between teams and wait longer.

Goal

Pick one owning team from a fixed list, and hand anything that doesn't clearly belong to one team to a person.

Input / state

The subject and body of the incoming message.

subject: Email subject or form title, if there is one.
message: The customer's message, unedited.

Decision question

ChoiceQuestion key team

Which team should handle this support message?

Options

billingCharges, invoices, payment methods, refunds or subscription changes.
technicalErrors, bugs, outages or integration problems with the product.
accountLogin, access, profile, security settings or team membership.
shippingDelivery status, lost or damaged packages, or address changes for physical orders.

Allowed outcomes

Decided in your code from the answer and its confidence. Thresholds are yours to set and test.

Billing teamChoice is billing and confidence meets your threshold.
Technical teamChoice is technical and confidence meets your threshold.
Account teamChoice is account and confidence meets your threshold.
Shipping teamChoice is shipping and confidence meets your threshold.
Needs a personConfidence is below your threshold: probability is spread across teams.

Example scenarios

Predefined demonstrations. No model is called; the outcome shown is an illustrative judgment.

Example state

Adapted from Quick start

{
  "subject": "URGENT: API down",
  "message": "Our API integration started returning 500 errors on every request about 20 minutes ago, and we can't process any customer orders until this is fixed."
}

Outcome

Illustrative

Technical team

Choice is technical and confidence meets your threshold.

Why

An integration failing with server errors is a technical problem, whatever its business impact.

Better together with

Complementary classifiers, and what each one adds here.

In-scope request checkNoul
Answers "does any team fit?" so the team choice isn't trusted on off-topic mail.
Combined inSupport inbox triage
Ticket urgencyScore
Routing decides who; urgency decides how fast. Ask both about the same message in one request.
Combined inSupport inbox triage
Refund request detectionNoul
Billing tickets often contain a refund request that should move to the refund flow.
Combined inSupport inbox triage

Used in chains

Support inbox triageStep 2 of 4

Sources

Primary documentation this classifier builds on. Scenarios on this page are illustrative, not taken from production use.

SourcedTypeSafe docs · Documentation
Quick start
Routes a support ticket to a department with a Choice, rates frustration with a Score and checks urgency with a Noul in one request.
SourcedHugging Face · Model card
Kev-4B model card
Supports choice, score and noul questions in English, shows a billing/shipping/returns routing call, and lists fully automated consequential decisions without human review as out of scope.
SourcedTypeSafe docs · Documentation
Model jaggedness
Lists known failure modes, including literal reading, arithmetic, date comparison, option order and adversarial content.

Using it well

Describe every option so the boundary between teams is written down, not implied by the option name.
Pair it with the in-scope check, because a Choice always picks an option even when none fits.
Messages that span several teams often come back with low confidence. Treat that as a signal to split the ticket or ask a person.
Option order can change an answer. Reorder options in testing and check that answers stay the same.

Request definition

POST https://api.typesafe.ai/v1/systemone

{
  "model": "jev-latest",
  "state": {
    "subject": "<subject>",
    "message": "<message>"
  },
  "questions": {
    "team": {
      "type": "choice",
      "instructions": "Which team should handle this support message?",
      "criteria": {
        "billing": "Charges, invoices, payment methods, refunds or subscription changes.",
        "technical": "Errors, bugs, outages or integration problems with the product.",
        "account": "Login, access, profile, security settings or team membership.",
        "shipping": "Delivery status, lost or damaged packages, or address changes for physical orders."
      }
    }
  }
}

Request shape from the System One API reference; a Kev server accepts the same body. Replace the placeholder state with your data. Requests need your own API key or server.