Caso de uso
Roteamento de tickets de suporte
Classifique urgência, equipe e tom em cada ticket que entra, antes de ele chegar a uma fila.
O problema
Regras de roteamento perdem sarcasmo, tickets de múltipla intenção e contas VIP silentes.
O que seu código faz com a resposta
Se a urgência é alta e a confiança é baixa, acione uma pessoa. Caso contrário, enfileire para a equipe escolhida.
Como a decisão volta
Três perguntas entram em uma requisição sobre o texto do ticket: is_urgent (sim/não), department (choice entre billing, technical ou sales) e frustration (um score de três níveis). Cada resposta traz a própria probabilidade, então um ticket que lê como duas intenções ao mesmo tempo — uma reclamação de reembolso escondendo um relato de bug — ainda aterrissa em algum lugar, com uma distribuição que mostra o quanto a chamada foi disputada. O exemplo de curl abaixo é a requisição completa; o seu servidor envia o mesmo JSON com uma chave Bearer.
O que o código de produção faz com ela
Roteie pelo department. Se is_urgent está acima de 0.8 e frustration está no nível de topo, acione uma pessoa em vez de enfileirar. Se is_urgent é alto mas a probabilidade de department está dividida abaixo de 0.6, a distribuição está dizendo que a intenção é mista — mande para a fila sênior com ambas as equipes candidatas anexadas. Os números de threshold são seus; o que torna a coisa estável é a forma: aja sobre o nível, revise quando estiver disputado.
Pitfalls específicos de triagem
A falha clássica é criteria escritos para humanos, não para um modelo: "coisas de billing" roteia faturas e reembolsos de forma inconsistente — nomeie exemplos concretos na descrição de cada opção. Segundo: não enterre a urgência na mesma pergunta do roteamento; tickets de intenção mista leem-se como baixa urgência quando uma única pergunta carrega as duas. Terceiro: mantenha o contexto comercial (contas com campos de receita) no state, para que a urgência os pondere sem hard-code de um tier VIP.
O formato da requisição
Esta é a requisição completa que o playground envia para este preset — o mesmo JSON que o seu servidor envia para /v1/systemone com uma chave Bearer.
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 sobre este caso de uso
- Preciso de uma requisição Jev por ticket?
- Não — todo sinal de roteamento é uma pergunta em uma única requisição. Até oito perguntas por chamada: urgência, departamento, sentimento, status VIP e idioma, de uma vez. Uma chamada de triagem típica tem 400–600 tokens e custa 1 crédito.
- E tickets em outros idiomas?
- Escreva as instructions e os criteria no idioma em que está escrito o seu caminho de ação; o state pode ficar no idioma do cliente. O espaço de respostas do Jev é tipado de qualquer forma — teste cinco tickets recentes por idioma antes de ligar.
- O que acontece quando a fila está errada mas a confiança é alta?
- Errado com confiança é um conserto de wording de criteria, não de threshold. Pegue três tickets mal direcionados, reescreva os criteria de department com exemplos concretos (pagamentos, faturamento — não "coisas de dinheiro") e rode-os de novo de graça no playground antes de tocar na produção.