Porque o histórico de tickets é a matéria-prima certa
Se queres que a IA responda bem aos teus clientes, ela precisa de contexto real, não de opinião. Na aula das Sextas Ímpares #128, falei sobre como a inteligência artificial só se torna útil quando tem dados a sério. Sem esse contexto o modelo passa a adivinhar, exatamente o que queremos evitar no suporte.
Como disse na aula, a inteligência artificial só se torna realmente inteligente se tiver dados. No exemplo que dei sobre suporte ao cliente, a lógica é simples: em vez de o agente decidir sozinho como responder a cada ticket, ele consulta primeiro o que a empresa já respondeu antes. O agente analisa a base de conhecimento, a knowledge base da empresa, e traz a resposta com base nisso, não com base no que acha que é a melhor solução. É esse o ponto de partida de qualquer base de conhecimento de suporte: ela reflete o que já foi feito e validado por alguém da equipa.
Vale reforçar isto porque é o erro mais comum quando alguém começa a experimentar automação de suporte. A tentação é ligar a ferramenta ao email todo, ao histórico completo, e deixar a IA aprender por conta própria. Mas o histórico bruto contém tanto boas respostas como más decisões, contém promessas feitas sob pressão e respostas dadas por colaboradores que já não trabalham na empresa. A curadoria existe precisamente para filtrar isto antes de a máquina aprender.
Seleciona apenas respostas que resolveram o problema
Vale a pena perceber quais tickets fecharam bem e quais ficaram por resolver antes de carregar todo o histórico sem filtro. Se o cliente não sabe dizer de onde vêm as vendas, começamos por aí; o mesmo raciocínio serve aqui, com dados concretos antes de qualquer automação.
Eu começaria por separar os tickets em duas pilhas: os que resolveram o problema à primeira, com uma resposta clara e reproduzível, e os que envolveram trocas longas, reclamações ou negociações fora do comum. Só a primeira pilha deve alimentar o contexto que a IA vai usar para sugerir respostas. Na aula dei o exemplo de usar os últimos 2000 tickets do suporte como fonte para a máquina criar rascunhos de resposta, não como um arquivo bruto sem tratamento.
Isto é uma recomendação prática, não uma regra fixa: cada negócio tem o seu volume e a sua forma de categorizar tickets. Uma loja pequena pode ter cem tickets fechados por mês e escolher rever manualmente os melhores exemplos de cada categoria de pergunta. Um negócio maior pode precisar de um critério automático, por exemplo, filtrar apenas tickets fechados sem reabertura e com resposta dada rapidamente. O princípio de escolher apenas o que já funcionou vale para qualquer dimensão de operação.
O que um assistente de IA precisa de saber sobre o teu negócio
Como usar a IA no negócio para além das perguntas ao chatbot
Como transformar mais leads em clientes num negócio de serviços
Separa a política atual das exceções pontuais
Um erro fácil de cometer é deixar que uma exceção antiga passe a ser lida pela IA como regra geral, misturada sem marcação com a política atual. Se há tempo se fez um gesto pontual por causa de um erro específico, isso não pode aparecer no mesmo nível que a política em vigor.
Eu quero perceber o que mudou e o que tenho de decidir: esse é o filtro que aplico quando reviso conteúdo antigo antes de o entregar a um agente automático. Vale a pena manter dois grupos separados, um com as regras que valem sempre, outro com casos especiais que só servem de referência para decisões humanas. A IA pode usar o segundo grupo para sugerir um caminho a um colega, mas não deve ter autoridade para repetir uma exceção como se fosse padrão de atendimento.
Pensa num caso concreto: um cliente recebeu um produto danificado fora do prazo de garantia e a empresa decidiu, na altura, trocar o produto por boa vontade. Se essa troca aparecer misturada com o resto do histórico, sem qualquer marcação, o próximo cliente que reclamar de um produto fora de garantia pode receber a mesma promessa, mesmo que a empresa não tenha intenção de repetir esse gesto todas as vezes. Separar os dois grupos evita esse tipo de generalização indevida.
Dá contexto atualizado, não apenas volume
Dá-me os dados, explica-me a regra e mostra-me onde falhou: essa postura dá bons resultados quando se treina qualquer sistema. O histórico de suporte só é útil se estiver ligado às condições atuais do negócio, preços, prazos, políticas de garantia.
Se a empresa mudou de fornecedor de envio há meses, um ticket antigo sobre esse tema já não serve como referência direta, mesmo que a pergunta do cliente pareça idêntica. Na aula falei também sobre o efeito seguinte deste tipo de curadoria: quando a base está bem tratada, a IA já não fica a adivinhar, cria um rascunho de resposta e eventualmente até automatiza a resposta, referindo-me ao momento em que o agente passa a propor o texto sozinho, com base no que já foi validado. Esse passo só faz sentido depois de o histórico estar limpo e atualizado.
Na prática, a base de conhecimento pede revisão contínua, não é algo que se escreve uma vez e se esquece. Sempre que a empresa altera um preço, um prazo de entrega ou uma condição de garantia, alguém precisa de rever quais tickets antigos deixaram de ser válidos como referência, marcando mesmo numa nota simples quais categorias de resposta ficaram desatualizadas. Essa revisão periódica é o que evita que a IA continue a repetir uma condição comercial que já não existe, algo que o cliente só descobre quando tenta usar essa informação errada.
Protege dados pessoais antes de qualquer curadoria
Antes de mandar seja o que for para uma ferramenta de IA, vale a pena rever se há informação sensível: nomes completos, números de encomenda, dados de contacto. Isto não foi detalhado na aula, mas é bom senso para qualquer negócio que trate dados de clientes.
Não é preciso um sistema complexo para isso. Podes reservar tempo para rever manualmente os tickets escolhidos, ou usar uma ferramenta simples de substituição de texto, antes de os considerares parte da base final. Se a equipa é pequena, isto pode ser feito enquanto se faz a própria seleção dos melhores tickets, no mesmo passo de trabalho, sem exigir uma etapa extra separada.
Vale também pensar no lado interno: se um colaborador que já saiu da empresa assinou respostas antigas, remove o nome dessa pessoa do conteúdo que passa a servir de referência. O que importa preservar é a solução dada, não quem a deu. Isto simplifica também a manutenção, porque a base passa a falar com uma voz única da empresa, e não com a voz de pessoas específicas que podem já não fazer parte da equipa.
Testa com perguntas que não têm resposta
Um sistema de suporte apoiado em IA só é seguro se souber dizer "não sei" quando não tem informação suficiente. Eu experimentaria perguntas fora do que a base cobre, produtos que nunca vendeste, pedidos fora da política, antes de deixar o agente responder sozinho.
Na aula sublinhei que o papel do humano na automação passa a ser de curador e observador das decisões da máquina, não de executor de tarefas repetitivas. Isso aplica-se diretamente aqui: alguém da equipa precisa de rever periodicamente o que a IA está a sugerir e corrigir a base sempre que aparecer um desvio.
Este teste vale mais no início da implementação. Enquanto o volume de respostas geradas é pequeno, é fácil rever cada uma e perceber onde a IA improvisou em vez de admitir que não tinha resposta certa. À medida que a confiança na base cresce, esse acompanhamento pode passar para amostragem semanal, revendo apenas uma parte das respostas geradas. Isso permite reduzir gradualmente a supervisão manual conforme a base fica mais madura e testada.
Nota da fonte
Escrevi este artigo a partir da minha aula A Era da Inteligência da Automação nos Negócios, Sextas Ímpares #128, gravada no Ad Summit. O exemplo sobre suporte ao cliente e knowledge base surge por volta dos 57 minutos da sessão. Podes ver a aula completa aqui: https://www.youtube.com/watch?v=XTWg_GjK35Q