Classificação de tickets de suporte com IA

Uma fila de suporte funciona, até o volume dobrar. Alguém abre o ticket, lê, decide se é dúvida técnica ou cobrança, avalia se é urgente, escolhe o time e passa adiante. É um minuto por ticket que ninguém contabiliza e que ninguém gosta de fazer. Nas horas de pico, a fila de triagem vira a própria fila de espera do cliente.

O Jev é um modelo da TypeSafe AI que não escreve respostas: ele recebe um texto e devolve decisões tipadas — uma opção escolhida, uma nota numa régua, um sim ou não — cada uma com a probabilidade associada. Para triagem, esse formato encaixa quase perfeitamente, porque triagem é exatamente uma sequência de perguntas fechadas.

O desenho das perguntas

Uma chamada por ticket. O texto vai no state junto com o mínimo de contexto que a decisão precisa; as perguntas vão todas juntas, porque são avaliadas em paralelo contra o mesmo state.

{
  "state": {
    "assunto": "Sistema não abre depois da atualização",
    "mensagem": "Boa tarde. Fiz a atualização ontem e agora o sistema não abre mais, dá erro de conexão. Preciso de uma solução hoje porque a equipe toda está parada.",
    "plano": "Empresarial",
    "tickets_abertos_no_mes": 3
  },
  "questions": {
    "categoria": {
      "type": "choice",
      "instructions": "Qual é o assunto principal deste ticket?",
      "criteria": {
        "duvida_tecnica": "Algo não funciona, dá erro ou o cliente não sabe usar um recurso.",
        "cobranca": "Fatura, valor, estorno, plano ou forma de pagamento.",
        "elogio": "O cliente agradece ou elogia, sem pedir nada.",
        "outro": "Não se encaixa em nenhuma das categorias acima."
      }
    },
    "urgencia": {
      "type": "score",
      "instructions": "Qual a urgência declarada ou implícita no pedido?",
      "criteria": [
        "Nenhuma pressa; o cliente não cita prazo.",
        "Pressa comum; quer resposta nos próximos dias.",
        "Pressa clara; cita prazo curto ou impacto no trabalho.",
        "Bloqueio total; a operação do cliente está parada."
      ]
    },
    "risco_de_cancelamento": {
      "type": "score",
      "instructions": "Quanto o texto indica risco de o cliente cancelar o serviço?",
      "criteria": [
        "Nenhum sinal.",
        "Insatisfação sem menção a sair.",
        "Compara com concorrente ou ameaça reclamar formalmente.",
        "Diz que vai cancelar ou já iniciou o cancelamento."
      ]
    },
    "pede_reembolso": {
      "type": "noul",
      "instructions": "O cliente pede explicitamente estorno, reembolso ou crédito?"
    },
    "cita_prazo_legal": {
      "type": "noul",
      "instructions": "O texto menciona órgão de defesa do consumidor, Procon, advogado ou processo?"
    }
  }
}

A opção outro não é enfeite. Sem ela, o modelo é forçado a encaixar qualquer mensagem em uma das categorias escritas, e você perde o sinal mais útil de todos: “isto não é nada disso”. Como escrever as descrições que realmente separam uma opção da outra está em critérios que separam.

O que o código faz com a resposta

A ordem importa, e ela é sempre a mesma.

Primeiro, o piso de confiança. Se a confiança da categoria ficar abaixo do seu piso, o ticket vai para a fila humana e o resto da lógica nem roda. Essa faixa existe porque o modelo tem um jeito de dizer “não sei”, e ignorá-la é desperdiçar a única proteção de graça que o desenho oferece.

Depois, as regras determinísticas. cita_prazo_legal acima do seu corte manda o ticket para o time responsável, independentemente de categoria e de nota. Isso é política da empresa, não julgamento: não deve depender de um peso.

Por último, a combinação das notas. Urgência e risco de cancelamento entram em uma fórmula com pesos que você controla, no seu código, e o resultado define a posição na fila. É o padrão descrito em pontuação composta.

c = r.answers["categoria"]

if c.confidence < PISO:
    return fila_humana(ticket)

if r.answers["cita_prazo_legal"].noul > 0.6:
    return fila_juridico(ticket)

prioridade = 0.6 * (r.answers["urgencia"].score / 3) \
           + 0.4 * (r.answers["risco_de_cancelamento"].score / 3)
encaminhar(ticket, time=TIMES[c.choice], prioridade=prioridade)

Onde entra a pessoa

Em três lugares, com limiares diferentes, porque limiar acompanha o risco da ação.

O primeiro é a faixa de confiança baixa do Choice: destino errado gera retrabalho, e o custo de revisar é menor que o de devolver o ticket depois. O segundo é o topo da fila de prioridade — um caso de bloqueio total merece olho humano mesmo com confiança alta. O terceiro é a amostragem: revisar uma fatia aleatória dos casos automáticos é o que mede a taxa de erro real. O desenho completo da fila está em revisão humana no lugar certo.

O que aconteceu nos nossos testes em português

Fizemos cinco chamadas à API oficial em 18 de setembro de 2026, com seis perguntas cada, contra textos de suporte escritos em português do Brasil. O modelo que respondeu foi o jev-1.13.0, a média foi de 955 tokens de entrada e as latências de ida e volta, medidas por quem chamou e incluindo a rede, ficaram entre 270 e 802 milissegundos.

Dois resultados interessam a quem faz triagem. Um texto irônico — “Nota dez para o atendimento, viu? Nunca vi tanta eficiência na minha vida” — recebeu sentimento negativo com 98%, ou seja, a ironia passou; em compensação, a categoria caiu em “Outro” com 79% e confiança 0,72, que é o modelo avisando que o texto não encaixa bem na lista. E um texto com “oxe” e “num abre” foi classificado como dúvida técnica com 100% de probabilidade e 100% de confiança. Cinco chamadas não são benchmark, e não tratamos como tal. Os cinco casos completos estão em o Jev funciona em português, e dá para rodar o seu próprio texto no playground.

Custo

Assumindo 30 mil tickets por mês — suposição deste artigo, não dado de mercado — com o mesmo perfil das nossas medições, 955 tokens de entrada por chamada: o preço oficial é de US$ 0,042 por milhão de tokens de entrada, com saída gratuita. Isso dá cerca de R$ 0,00022 por ticket com o dólar estimado em R$ 5,40, e cerca de R$ 6,50 por mês para a fila inteira. A fórmula e as ressalvas estão em quanto custa uma decisão.

O efeito prático não é a economia: é que avaliar 100% da fila deixa de ser uma decisão orçamentária.

Onde isso quebra

A documentação oficial mantém uma lista dos nove modos de falha declarados do jev-1.13, e a triagem de tickets esbarra em três deles.

Contagem. “Quantas vezes este cliente reclamou?” não é pergunta para o modelo: ele reconhece a forma de uma resposta em vez de contar, e o erro cresce com o tamanho da lista. Conte no banco e mande o número pronto no state.

Datas. “Este ticket está aberto há mais de 48 horas?” também não. O modelo lê data como texto, não como quantidade ordenada. Calcule em código.

State grande. Colar o histórico inteiro do cliente no state piora a resposta, porque detalhe irrelevante age como distrator. Mande os campos que a pergunta usa. O efeito tem nome e página própria em context rot, e a lista completa de limites está em limites do Jev.

Para os outros fluxos com a mesma mecânica, veja casos de uso.