IA para deduplicação de tickets: detete tickets duplicados antes que lhe custem a dobrar

Porque é que os tickets duplicados continuam a aparecer?

Passo muito da minha semana com dados de pesquisa, e "deduplicação de tickets" é uma daquelas expressões que escondem dois problemas diferentes atrás de uma só palavra-chave. Algumas pessoas que a pesquisam têm um cliente impaciente que escreve três vezes. Outras tiveram uma falha e 200 pessoas reportaram-na. A solução para o primeiro caso estraga o segundo, por isso vale a pena saber qual tem antes de comprar o que quer que seja.

Os duplicados vêm de uma lista bastante curta de sítios:

• Os clientes iniciam um novo fio em vez de responder. Respondem ao seu acompanhamento com um e-mail novo, ou passam do chat para o e-mail a meio.
• Um e-mail chega a duas caixas. Pôr em cópia dois endereços de suporte, ou duas equipas em instâncias de helpdesk separadas, transforma uma mensagem em dois tickets.
• Um incidente afeta muitos clientes ao mesmo tempo. Um erro no pagamento ou uma falha no login produz um relato por cada cliente afetado.
• E-mail automático sem o seu ID de ticket. Alertas de fornecedores e notificações do sistema que não trazem a referência original abrem um novo ticket de cada vez.
• A própria IA. Um agente que repete uma ação, ou lê a sua própria resposta como uma nova mensagem do cliente, pode criar duplicados mais depressa do que qualquer cliente.

Esta descrição de um sysadmin sobre o primeiro caso é dolorosamente familiar:

"However end users such as they are fail to reply with an attachment - and just send in a new job."

badapple89, Reddit

E a versão das duas caixas, de uma equipa que adicionou uma segunda instância do Zendesk para os RH:

"At times the requester emails both the teams. When one of the instances reply to the email the other team gets a new ticket instead of the same conversation getting appended to the existing ticket."

almostlikeu, Reddit

A última causa da lista é a que eu levaria mais a sério em 2026, sobretudo porque a vi acontecer do nosso lado. O eesel teve clientes cujo segundo agente de IA colidiu com o primeiro num gatilho partilhado, o que gerou notas duplicadas e respostas em dobro, e um deles escalou um bug de prioridade máxima quando a IA tratou as suas próprias respostas como novas mensagens do cliente e entrou em ciclo. Isso está corrigido, e a lição ficou: um agente por gatilho, e verificar sempre o que já está aberto antes de agir. Um programador que construiu uma proteção para este mesmo problema disse-o claramente:

"While experimenting with LLM agents calling tools, I ran into a reliability problem: retries can easily trigger irreversible actions more than once."

Lions2026, Hacker News

O que conta como ticket duplicado?

Um ticket duplicado é um segundo ticket sobre um pedido que a sua equipa já está a tratar, e a divisão útil, em termos do que fazer com ele, é quem o enviou.

Há um terceiro grupo que parece duplicado mas não é: clientes diferentes a fazer a mesma pergunta comum, como "onde está a minha encomenda?". Esses são tickets de suporte repetidos, e a solução é uma resposta melhor ou o desvio por FAQ, não uma união.

Como a IA deteta tickets duplicados?

A IA deteta duplicados em dois passos: reduz a fila a alguns candidatos prováveis e depois pontua o quão próximo está cada um. O passo dos candidatos faz a maior parte do trabalho de segurança, e é por isso que todos os fornecedores que analisei começam pelo mesmo solicitante e uma janela de tempo antes de uma IA ler uma única palavra.

O monday service publica as regras mais claras que encontrei até agora. A sua deteção de duplicados do Sidekick só olha para tickets abertos criados nos últimos 30 dias, do mesmo e-mail de solicitante, no mesmo quadro. Compara o nome e a descrição do ticket pelo significado e exige que ambos coincidam: uma categoria igual "reforça a confiança mas não pode, por si só, acionar uma sugestão". As sugestões de união do Zendesk usam os tickets do mesmo solicitante de duas semanas antes e depois do atual, e apenas dentro da mesma marca.

Eis como os sinais se apresentam na prática:

• Mesmo solicitante. O sinal mais seguro. Quase todas as ferramentas integradas o exigem.
• Janela de tempo. Dias, não meses. O HappyFox torna a janela retrospetiva uma definição que você escolhe.
• Significado do assunto e da descrição. "Cartão recusado no pagamento" e "não consigo pagar, diz que o pagamento falhou" devem corresponder mesmo sem palavras em comum.
• Um identificador partilhado. Número de encomenda, código de erro ou ID de dispositivo. As equipas pedem muito este:

"We put our order number in a custom field and it would be very helpful to merge tickets based on this field."

Antique-Cartoonist-5, Reddit

Depois decida o que cada nível de confiança pode fazer. Esta é a parte que mais importa:

Uma correspondência de alta confiança recebe uma etiqueta e uma ligação ao original, uma correspondência média aparece como sugestão que o agente pode aceitar, e uma baixa simplesmente continua a ser um ticket separado. A união em si continua a ser um clique humano, pelo menos até medir com que frequência a IA acerta. É a mesma disciplina que afinar os falsos positivos do etiquetamento por IA.

Uma conclusão a que volto sempre, de alguém que estudou isto para um sistema municipal de tickets:

"Research showed that pure AI and pur human outperformed co-working. Human oversight often e.g. overcorrected machine work."

riedel, Hacker News

É um aviso justo sobre as filas de revisão. Se os agentes duvidam de cada boa sugestão, fica com o custo de ambos e a velocidade de nenhum, e ninguém fica contente. A solução é manter o trabalho da IA estreito e mensurável (etiquetar e vincular), para que o passo humano seja um sim rápido e não uma reinvestigação completa.

Que helpdesks já deduplicam tickets com IA?

A maioria dos grandes helpdesks já tem alguma forma disto, e quase sempre está limitada ao mesmo solicitante. Eis o que cada um faz realmente, segundo a documentação dos próprios fornecedores.

Zendesk. As sugestões de união aparecem com um distintivo vermelho no ícone de Tickets relacionados. Marca os tickets, clica em Unir, revê os comentários de união e confirma. Se estiver a unir entre solicitantes, organizações ou marcas diferentes, o Zendesk mostra primeiro um aviso. O uso só conta na quota do Copilot quando clica em Confirmar e unir, por isso olhar é gratuito. Aprofundo o pacote Zendesk Copilot e os preços de IA do Zendesk noutro lugar.

Se quer uniões sem o clique, a app Auto Merge do Zendesk Marketplace une duplicados do mesmo solicitante por regra. Pode comparar por qualquer campo do ticket, definir uma janela de tempo, escolher se une no ticket mais novo ou no mais antigo, e executar tarefas agendadas sobre o atraso acumulado. É baseada em regras e não em IA, o que, para um passo que não se pode reverter, é, honestamente, uma vantagem.

monday service. Quando abre o quadro de Tickets, o Sidekick analisa os tickets abertos recentes e coloca um ícone junto dos prováveis duplicados. Escolhe qual ticket fica como principal e confirma. Fecha o duplicado e move os colaboradores para o ticket principal, e se o cliente responder mais tarde no fio de e-mail do ticket fechado, essa resposta fica no ticket fechado. Os admins podem desligar estas sugestões proativas para parar o uso de créditos de IA em segundo plano.

HappyFox. O Duplicate Ticket Detector é um dos agentes de IA Autopilot do HappyFox. Sinaliza possíveis duplicados do mesmo contacto e adiciona uma etiqueta de ticket duplicado à sua escolha, limitado às categorias de ticket que selecionar. A configuração é o que mais gosto: o HappyFox diz-lhe para começar estreito e usar o modo supervisionado até a sua equipa ter revisto os resultados. Mais sobre custos na minha análise dos preços do HappyFox.

Freshdesk e Freshservice. A união no Freshdesk é manual de origem (veja o meu guia sobre unir tickets no Freshdesk), e a união automática vem do marketplace, como a app Merge Duplicate Tickets, que une tickets do mesmo solicitante ou pelas suas próprias regras. O próprio artigo de ajuda do Freshservice diz claramente que não une tickets automaticamente de forma nativa e remete para a app Auto Ticket Merger.

Deve unir ou vincular tickets duplicados?

Una quando é um cliente, vincule quando são muitos, e quando não tiver a certeza, vincule. Uma ligação pode ser removida depois. Uma união geralmente não.

As regras de união do Zendesk mostram porque vale a pena ir devagar:

• As uniões são permanentes e não podem ser desfeitas.
• Os tickets têm de estar num estado anterior a Resolvido para serem unidos.
• O solicitante do ticket fechado é adicionado em cópia, desde que as cópias estejam ativadas.
• O ticket fechado pela união recebe uma etiqueta closed_by_merge, que pode usar para manter os tickets unidos fora dos relatórios.
• Os tickets tratados pelos agentes de IA do Zendesk não podem ser unidos.

Outros helpdesks têm as suas próprias armadilhas. No Freshservice, unir fecha os tickets secundários e adiciona uma nota privada, e o agente tem de adicionar à mão uma vez os outros solicitantes ao campo de cópia. No monday service, uma resposta no antigo fio de e-mail vai parar ao ticket fechado. Nenhuma destas coisas é um impedimento, mas são exatamente o tipo de pormenor em que uma regra de união automática tropeça às 2 da manhã.

Para incidentes, use antes um ticket pai. Os tipos problema e incidente do Zendesk e os tickets pai-filho do Freshdesk deixam um ticket guardar a investigação enquanto cada cliente mantém um ticket que recebe resposta. O meu guia de suporte com IA durante falhas de SaaS percorre essa configuração com uma IA a responder a cada relato.

Quanto lhe custam os tickets duplicados?

Os duplicados custam duas vezes, uma em tempo dos agentes e outra nos seus relatórios, porque uma fila com 10 % de duplicados parece 10 % mais ocupada do que realmente está. Insira os números do último mês para ver ambos.

O quarto número é o que as pessoas esquecem. A maioria dos agentes de IA é cobrada por ticket ou por conversa, o eesel incluído, por isso um duplicado que chega à IA é faturado como qualquer outro ticket. É mais uma razão para apanhar as repetições à porta em vez de depois de ambas terem sido trabalhadas.

Onde deve acontecer a deduplicação: à chegada, na fila ou nos relatórios?

Nos três, e são trabalhos diferentes. A maioria das ferramentas nativas cobre o do meio, enquanto o primeiro é o que mais poupa.

À chegada. Antes de alguém responder, verifique os outros tickets abertos do solicitante. Se houver correspondência, etiquete-o, ligue o original numa nota interna e garanta que apenas um ticket recebe resposta. É aqui que uma IA que já lê cada ticket novo para a triagem justifica o seu lugar, porque a consulta não custa nada a mais. É também aqui que pertence a filtragem de spam e ruído, já que as respostas automáticas de ausência e as notificações são o outro tipo de ticket em que ninguém deveria trabalhar.

Na fila. Sugestões de união, regras de união automática agendadas e uma varredura diária para o que escapou. As sugestões do Zendesk e a vista de união em massa vivem aqui.

Nos relatórios. Conte pedidos únicos, não tickets. Exclua closed_by_merge no Zendesk, adicione a sua etiqueta de duplicado ao filtro e acompanhe três números: a taxa de duplicados, com que frequência os agentes aceitam as sugestões da IA (precisão) e quantos duplicados a sua equipa ainda une à mão que a IA não detetou (taxa de captura). O meu artigo sobre IA para relatórios de suporte e a lista de métricas de atendimento ao cliente com IA mostram como encaixam no relatório mais amplo.

Como implementar a deduplicação de tickets com IA com segurança?

Comece pela correspondência mais segura e observe-a durante duas semanas, só depois alargue a rede. Esta é a ordem que eu seguiria:

1. Meça primeiro o problema. Conte as uniões manuais do último mês e analise uma amostra de 50 tickets à procura de repetições. Se os duplicados forem menos de 2 % do volume, um painel de sugestões de união é mais do que suficiente.
2. Corrija as fontes que puder. Peça aos fornecedores que mantenham o seu ID de ticket nos assuntos, pare de encaminhar um endereço para duas instâncias e torne óbvio o "responda a este e-mail" nos seus modelos.
3. Ative o que o seu helpdesk já tem. Sugestões de união do Zendesk, Sidekick do monday ou o detetor do HappyFox em modo supervisionado.
4. Etiquete antes de unir. Faça a IA adicionar uma etiqueta possible_duplicate e uma nota a ligar o original. Reveja uma amostra todas as semanas e acompanhe quantas etiquetas estavam certas.
5. Automatize uniões apenas para a regra mais estreita. Mesmo solicitante, mesmo assunto, dentro de 24 a 48 horas. Deixe como ligação tudo o que atravesse solicitantes.
6. Trate os incidentes em separado. Quando chegar um pico de tickets semelhantes de clientes diferentes, crie um ticket pai e deixe a IA vincular e responder a cada relato com a atualização do problema conhecido. O meu guia de picos sazonais mostra o mesmo padrão para lançamentos.
7. Reporte sobre pedidos únicos. Mude o número principal do seu relatório semanal quando as etiquetas forem fiáveis.

Como o eesel trata tickets duplicados?

O eesel trata os duplicados à chegada, na mesma passagem que faz a triagem e responde ao ticket. Serei franco sobre o que não faz: o eesel não tem uma ação de união. As suas ações no Zendesk são responder, nota interna, rascunho, adicionar etiquetas, atribuir, fechar, atualizar campos e criar, além de ler, pesquisar e listar tickets. Assim, a união fica no seu helpdesk, onde vivem as ferramentas nativas e os seus avisos, e o eesel faz a parte que elas não fazem, que é impedir que o segundo ticket seja trabalhado.

Na prática, as instruções são assim, escritas em linguagem simples no agente de helpdesk com IA do eesel:

• Na primeira mensagem do cliente, procura os outros tickets abertos dele dos últimos 14 dias.
• Se um tratar da mesma coisa, etiqueta o novo ticket possible_duplicate, deixa uma nota interna a ligar o original e não redijas uma segunda resposta.
• Se for novo, faz a triagem e responde como de costume.
• Para falhas, vincula cada novo relato ao ticket pai e envia a atualização de estado atual.

Há duas definições que fazem isto funcionar. O eesel pode esperar antes de processar até 15 minutos, para que os seus próprios gatilhos do Zendesk, regras de spam e tudo o resto que corre nos tickets novos vão primeiro. E pode correr de forma agendada, de modo que uma varredura matinal possa listar os tickets que parecem duplicados e enviá-los por e-mail a um responsável, sem tocar em nada.

Assim se vê com clientes reais:

• Dokument 24 executa o eesel no Zendesk e só o ativa na primeira mensagem de um cliente, "so follow-ups in a thread the team is already handling are left alone." Preparou cerca de 680 tickets para a equipa num mês, com cerca de 670 rascunhos de resposta em dinamarquês deixados como notas internas.
• Rúngne tem um agente de triagem no Gorgias que etiqueta cada ticket a partir de uma lista fixa e fecha comentários de redes sociais, respostas automáticas de ausência e spam. O seu agente de rascunhos lê primeiro o fio todo, à procura de uma promessa que um colega já fez, antes de escrever o que quer que seja. Isso deu cerca de 2,100 tickets tratados num mês.
• Cape Coffee Beans executa cinco varreduras agendadas do Zendesk, a maioria todas as manhãs, para tickets que escaparam: sem grupo, sem data de acompanhamento ou com o formulário errado. As varreduras são só de leitura e terminam num breve e-mail ao fundador, que é exatamente o formato que uma varredura de duplicados deve ter.

Antes de qualquer coisa entrar em produção, a competência de Simulação do eesel reproduz os seus tickets passados para ver o que teria feito em tickets reais. E se a sua equipa preferir um terminal, a CLI do eesel controla o mesmo agente: eesel activity lista o que fez, do mais recente para o mais antigo, que é a forma mais rápida de auditar as etiquetas de duplicado a partir de um script ou do Claude Code.

Quanto custa a deduplicação de tickets com IA?

Muitas vezes nada a mais, porque as ferramentas de sugestão vêm incluídas em planos que talvez já pague. Eis onde cada opção se situa.

Se usa o Zendesk, comece pelas sugestões de união e veja até onde o levam. Adicione uma app de união automática apenas para a regra estreita do mesmo solicitante. Adicione um colega de IA quando o custo real for a segunda resposta e não o clique de unir. Isso costuma acontecer em equipas no Zendesk, Freshdesk ou Gorgias que já querem ajuda com a resolução no primeiro contacto e o tempo de atendimento.

Experimente o eesel com tickets duplicados

Se dois agentes continuam a responder ao mesmo cliente, o eesel junta-se à sua fila do Zendesk, Freshdesk ou Gorgias como um novo colega. Verifica os tickets abertos do solicitante antes de responder, etiqueta a repetição, liga o original e responde uma vez, e pode reproduzir tickets passados para ver o que teria feito antes de tocar num ticket em produção. O plano gratuito cobre 100 tickets, o suficiente para o testar na sua própria fila. Experimente o eesel.