Um cliente perdeu todos os dados. Ninguém respondeu.

É um dos tickets que nunca tiveram resposta, de no dataset (sintético). Cada ficha na tela é um deles. As três respostas ao diretor:

  • da fila está parada
  • 0 de 8variáveis testadas explicam a nota
  • ~ hpor mês de volta para a equipe
  • nunca respondido
  • esperando o cliente
  • fechado

Ver a filaTriagem de tickets

Dois terços da fila estão parados

tickets nunca receberam a primeira resposta. Outros esperam o cliente mandar algo que faltou. Só foram fechados.

Canal, prioridade e tipo não mudam essa proporção. O problema é a fila inteira, e não um segmento dela.

A prioridade não muda nada

Separadas por prioridade, as pilhas têm a mesma forma. dos tickets Critical estão parados, como os Low.

A fila não é atendida por risco. Corrigir isso não exige IA.

Nenhuma variável testada explica a satisfação

Só os tickets fechados têm nota, e as cinco notas aparecem quase na mesma quantidade.

Canal, prioridade, tipo, assunto, produto, gênero, idade e tempo de resolução foram testados, e nenhum tem relação estatística com a nota (menor p = ). Antes de prometer CSAT, falta registrar a abertura do ticket, cada mudança de status e o motivo das notas baixas.

A IA lê, a regra decide, uma pessoa responde

  1. O LLM lê o ticket, sugere tipo e prioridade, marca riscos, lista o que falta e escreve um rascunho.
  2. Uma regra fixa procura sinais de risco no texto, mesmo que o LLM deixe passar.
  3. Reembolso, cancelamento, perda de dados, acesso e casos jurídicos vão para um agente sênior. O resto vai para um agente com o rascunho pronto.

Ao lado, os tickets sorteados para o teste. Todos precisavam pedir algo ao cliente, então a bandeja automática ficou vazia.

Antes de perguntar de novo, procurar

Um terço da fila espera o cliente mandar algo que faltou. Parte dessa informação já está em algum lugar.

  • contato ou log citado no texto ()
  • mensagem de erro em branco ()
  • depende de integração

O cadastro já traz produto e data de compra. Todas as compras têm mais de 12 meses: se a garantia for de 12 meses (premissa a confirmar), a resposta sobre cobertura já está pronta antes de perguntar.

E-mail do suporte, CRM e telemetria do produto completariam o resto. No protótipo essas fontes aparecem como simuladas, sem resultado inventado. Para ligar fontes reais: só leitura, só o que é do ticket, cada consulta registrada e nada vai ao cliente sem uma pessoa.

Testado em tickets que o modelo nunca viu

Nos tickets de TI, o classificador acerta dos casos que nunca viu. Quando está confiante, encaminha sozinho de cada 100, com de acerto. Os outros vão para uma pessoa.

  • sozinho e certo
  • sozinho e errado
  • para uma pessoa

Nos tickets de clientes, o LLM fez a triagem dos sorteados. Não prometeu reembolso nenhuma vez, marcou todos os riscos que a regra de palavras-chave também achou e pediu a mensagem de erro que faltava em casos.

Para onde cada ticket vai

Depois da triagem, uma regra fixa escolhe o destino. A IA sugere, mas não decide. Cada destino tem dono e motivo:

No protótipo, este mapa fica ao lado de cada ticket analisado e acende o caminho que ele percorreu.

Cerca de horas por mês de volta

Cada ficha aqui é uma hora. Triagem, rascunho da primeira resposta e idas e voltas evitadas somam horas por mês no cenário central: mais que uma pessoa em tempo integral.

A faixa vai de a horas, porque o dataset não registra o tempo do agente. Essas premissas são o que o piloto vai medir.

Na segunda-feira

A mesma fila de tickets parados, agora em ordem de risco.

  • risco no texto: vai primeiro ()
  • sem primeira resposta
  • esperando o cliente
  1. Esta semana, reordenar a fila por risco. Não precisa de IA.
  2. Por quatro semanas, IA em sombra: ela sugere, a pessoa decide, nada é enviado sozinho.
  3. Registrar abertura, mudanças de status e motivo das notas baixas.
  4. Reembolso, cancelamento, perda de dados, acesso e jurídico sempre com uma pessoa.
  5. Só depois do piloto, resposta automática para perguntas simples.

Como trabalhei com a IA

Dois agentes com papéis diferentes. As decisões ficaram comigo.

  1. Codex construiu a primeira versão: auditou os dados, achou os 8.469 tickets sintéticos e gerou várias versões de apresentação, que rejeitei até entender o que faltava.
  2. Pedi uma contraprova: uma sessão da IA sozinha, sem as minhas decisões, para comparar com o trabalho que eu conduzia.
  3. Claude Code revisou como avaliador cético: a entrega respondia com ressalvas, não tinha IA rodando e não cruzava os datasets.
  4. Exigi prova antes de aceitar a crítica e reconstruí com escopo enxuto, decidindo base, modelos, custo e direção visual.

Erros corrigidos no caminho: o classificador subiu de 79,0% para 86,5%, o protótipo ganhou IA ao vivo e uma afirmação sobre clientes repetidos caiu ao ser conferida.

Triagem de ticketsLer a submissãoVer as evidências

Dados: Customer Support Ticket Dataset e IT Service Ticket Classification Dataset (Kaggle, CC0). O primeiro é sintético; as conclusões valem para o desenho do processo, não como desempenho real.