ユースケース
サポートチケットのルーティング
すべての受信チケットがキューに入る前に、緊急度・担当チーム・トーンを分類します。
問題
ルーティングルールは、皮肉や複数の意図を持つチケット、黙っている VIP アカウントを見逃します。
回答に対してコードが行うこと
緊急度が高く信頼度が低い場合は、人を呼び出します。それ以外は選ばれたチームのキューに入れます。
判断はどう返ってくるか
チケットのテキストに対して 3 つの質問が 1 つのリクエストに乗ります：is_urgent（はい／いいえ）、department（billing、technical、sales の選択）、frustration（3 段階のスコア）。各回答にはそれぞれの確率が付くため、返金の苦情の中にバグ報告が隠れているような、2 つの意図を同時に読めるチケットでも、判断がどれほど揺れていたかを示す分布とともにどこかへ着地します。下の curl サンプルがリクエストの全体です。自分のサーバーは同じ JSON を Bearer キー付きで送ります。
本番コードがそれで何をするか
department で振り分けます。is_urgent が 0.8 を超え、frustration が最上位にあれば、キューに入れる代わりに人を呼び出します。is_urgent は高いのに department の確率が 0.6 未満で割れているなら、分布は意図が混在していると告げています — 両方の候補チームを添えてシニアのキューに送ります。しきい値の数字は自分で決めるものです。安定をもたらすのは形状です：レベルで動き、揺れているときはレビューする。
トリアージ特有の落とし穴
古典的な失敗は、モデルではなく人間向けに書かれた criteria です："billing stuff" では請求書と返金の振り分けが不安定になります — 各選択肢の説明に具体的な例を挙げてください。第二に：緊急度をルーティングと同じ質問に埋め込まないこと。1 つの質問が両方を担うと、複数の意図を持つチケットは低緊急度に読まれます。第三に：商業的な文脈（売上フィールドのあるアカウント）を state に残すこと。そうすれば緊急度が VIP ティアをハードコードせずに重み付けできます。
リクエストの形状
これは、このプリセットについて Playground が送る完全なリクエストです — 自分のサーバーが Bearer キー付きで /v1/systemone に送るのと同じ JSON です。
curl https://jevai.website/api/v1/systemone \
-H "Authorization: Bearer $JEV_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "Help! My payouts have been failing for 3 days and my customers are asking where their money is.",
"questions": {
"is_urgent": {
"type": "noul",
"instructions": "Does this convey urgency?",
"criteria": {
"true": "Explicitly time-sensitive or business-critical",
"false": "No urgency expressed"
}
},
"department": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payments, payouts, invoicing, refunds",
"technical": "Bugs, outages, integrations",
"sales": "Pricing, upgrades, new accounts"
}
},
"frustration": {
"type": "score",
"instructions": "How frustrated is the customer?",
"criteria": [
"Calm",
"Frustrated",
"Very angry"
]
}
}
}'このユースケースに関する FAQ
- チケットごとに 1 つの Jev リクエストが必要ですか？
- いいえ — すべてのルーティングシグナルが 1 つのリクエストの中の質問です。1 呼び出し最大 8 質問：緊急度、担当部門、感情、VIP 状態、言語を一度に扱うのに十分です。典型的なトリアージの呼び出しは 400〜600 トークンで、1 クレジットかかります。
- 他の言語のチケットはどうですか？
- instructions と criteria は、動作する側のコードが書かれている言語で書きます。state は顧客の言語のままで構いません。いずれの場合も Jev の回答空間は型付きです — 有効にする前に、言語ごとに最近のチケット 5 件でテストしてください。
- キューが間違っているのに信頼度が高い場合はどうなりますか？
- 自信ありげに間違えるのは、しきい値の問題ではなく criteria の文言の修正対象です。誤ルーティングされたチケットを 3 件取り出し、具体的な例（payments、invoicing — "money things" ではない）で department の criteria を書き直し、本番に触れる前に Playground で無料で再実行してください。