Copiloto de suporte: de 14% para 33% em quatro meses — e os 56% que ainda tiram nota zero

Toda conversa sobre IA no atendimento começa com uma promessa: “o assistente resolve sozinho”. Quatro meses medindo um copiloto de suporte em produção mostram uma história diferente — menos glamourosa, mais útil. O assistente não resolve sozinho. Ele entrega ao analista um rascunho muito melhor do que o rascunho que ele faria do zero. E é aí que está o valor.

Uma nota antes dos números: este é um projeto em andamento. O copiloto está em validação com os analistas seniores e só chega ao resto do time depois que eles aprovam as respostas. É a etapa que faz a equipe confiar nele, e é por isso que os números abaixo são de uma fase, não de um resultado final.

O que foi medido

Uma operação de suporte técnico com equipe própria de analistas e helpdesk. O copiloto responde no formato do primeiro nível: recebe o texto do chamado e devolve a resposta que o analista usaria.

O que mede não é satisfação de cliente nem “curtidas”. É isto, para cada resposta:

• Nota de 0 a 5 dada pelo analista que atendeu o chamado.
• Aproveitamento: ele usaria essa resposta como base para responder?
• Resposta correta, escrita por ele, para comparar.

Em quatro meses foram 728 avaliações, cada uma ligada a um chamado real. Quem avalia são as pessoas que têm menos paciência com resposta errada — hoje, seis analistas seniores.

O resultado

Indicador	Início	Depois de 4 meses
Nota média (0–5)	0,70	1,53
Respostas com nota 3 ou mais	14%	33%
Respostas aproveitadas pelo analista	20%	35%
Respostas com nota zero	73%	56%

Um detalhe importante: no meio do caminho a régua ficou mais dura, não mais mole. Os analistas mais novos saíram da avaliação e ficaram os seniores — justamente porque o feedback dos iniciantes era inconsistente (davam nota alta para resposta errada, e nota baixa para resposta certa, por não conhecerem o sistema). Ou seja: o número subiu com juiz mais rigoroso.

E as falhas? Seis em cada dez respostas ainda tiram nota zero

Antes dos detalhes, uma definição, porque a palavra falha é usada para tudo: aqui, ela quer dizer nota zero — a resposta que o analista não aproveitou de jeito nenhum. Em outubro, 56% das respostas ficaram aí. Um décimo ficou no meio, com nota 1 ou 2. Três décimos foram considerados usáveis. É essa a distribuição, e ela é pior do que “um em cada três falha” sugere.

Ler os 40 casos com nota 2 ou menos, um por um, mostra que as falhas se repetem em três grupos. Nenhuma delas se resolve escrevendo um prompt melhor.

1. Pedir de novo o que o cliente já enviou. O assistente só vê o texto colado no chamado. Quando o cliente anexou o print, o XML ou a documentação, o assistente não sabe — e pede outra vez. É a queixa número um dos analistas, e ela é de dados, não de inteligência: resolve-se ligando o assistente ao helpdesk para ele ver o que já foi anexado.

2. Caminho errado ou desatualizado. Quando o trecho de conhecimento recuperado não contém o caminho (aquele “Menu > Cadastro > …”), o modelo completa com o que parece plausível. É o pior tipo de erro: parece certo e manda o cliente para o lugar errado. A causa está na base, não no modelo — artigos sem o passo a passo dentro produzem respostas inventadas. Resolve-se com base curada: um verbete por assunto, com o caminho dentro.

3. Rota errada. Uma dúvida de processo tratada como pedido de melhoria, ou um encaminhamento para o time de Produtos quando a resposta já existia na base. O analista recebe a resposta certa para a pergunta errada. Resolve-se triando o tipo de pedido antes de responder.

Há ainda um quarto grupo que não é falha do assistente: chamados em que o cliente desistiu, ou em que a urgência fez o time responder sem esperar as evidências. Isso aparece como nota zero e não deveria.

O que isso ensina sobre projetos de IA no atendimento

Três conclusões que valem para qualquer empresa pensando nisso.

A primeira: o modelo não é o gargalo. Nas respostas com nota 4 e 5, o modelo já entrega o rascunho inteiro. O que separa o 4 do 5 é contexto (o assistente viu o chamado?) e forma (a resposta é objetiva?). Nas notas baixas, a falha também não é do modelo: é de informação que ele não tem.

A segunda: quem compra a ferramenta para montar sozinho desiste. Esse é o motivo pelo qual projetos assim morrem com credibilidade queimada: a responsabilidade de organizar a base e integrar os sistemas fica com a equipe que já está sem tempo. Nasce o “a IA não funciona aqui”.

A terceira: prometer resolução automática é o caminho mais curto para perder o cliente. O produto real é o rascunho medido. Quem promete substituição entrega expectativa; quem entrega rascunho a 80% entrega valor todos os dias — e tem o que mostrar três meses depois.

Como medir isso na sua operação (antes de contratar qualquer coisa)

Você não precisa de integração nem de projeto para começar a medir. Precisa de chamados já encerrados.

1. Escolha três números e escreva-os antes de mexer em qualquer coisa: tempo médio por chamado, % de chamados resolvidos com uma única resposta, e % de respostas que o analista aproveitaria como base.
2. Use o histórico. Selecionar 100 a 300 chamados encerrados dá uma linha de base honesta, com o antes já registrado.
3. Julgue por caso, não por média. Uma média esconde justamente o que interessa: o caso que parece certo e está errado.
4. Mostre as falhas. Um relatório que só tem acertos não serve para decidir; serve para vender. E, no mês seguinte, não se sustenta.

---

Se você tem uma equipe de suporte com volume repetitivo, o primeiro passo não é contratar IA: é saber o que a sua equipe responde hoje e onde essas respostas estão escritas. É o que a gente faz no diagnóstico — e é de graça na primeira conversa.

Para a equipe de suporte que pergunta por dentro, o caminho é o Copiloto N1.