O que conta como ticket de suporte repetido?
Escrevo sobre suporte para a eesel e, antes disso, passei dois anos em SEO, então leio consultas de busca para viver. A expressão "tickets de suporte repetidos" é interessante porque quem a digita geralmente não está pedindo uma definição. É um líder de suporte olhando para uma fila cheia de nomes conhecidos e se perguntando por que os mesmos clientes continuam escrevendo. É essa pergunta que este artigo tenta responder.
Na eesel passamos os últimos anos rodando IA em filas de helpdesk reais, e pelo que vejo nas chamadas de vendas, o padrão é bem consistente: as equipes sabem que repetidos custam caro, mas os medem com uma métrica que perde metade deles.
Quando as pessoas dizem "ticket repetido", geralmente querem dizer uma destas quatro coisas:
| Termo | O que é | Onde aparece |
|---|---|---|
| Reabertura | O cliente responde a um ticket resolvido e o mesmo ticket volta a aberto | Na métrica de reabertura do seu helpdesk |
| Ticket de acompanhamento | O cliente responde depois que o ticket foi fechado ou arquivado, então o helpdesk cria um novo ticket vinculado | Um ticket separado, muitas vezes ignorado |
| Ticket duplicado | O cliente escreve duas vezes sobre o mesmo problema, muitas vezes por dois canais | Dois tickets abertos, dois agentes |
| Contato repetido | Qualquer um dos acima: mesmo cliente, mesmo problema, dentro de uma janela de tempo | Só se você construir |
A última linha é a que realmente importa aqui. Uma taxa de contato repetido conta os três caminhos, enquanto uma taxa de reabertura conta só o primeiro.
Por que a sua taxa de reabertura subconta contatos repetidos
Todo helpdesk tem um ponto de corte. Antes dele, a resposta do cliente reabre o ticket antigo; depois, a resposta vira um ticket novo e a sua métrica de reabertura simplesmente deixa de vê-la. O corte é diferente em cada ferramenta, e a maioria das equipes nunca vai conferir.
Veja o que cada helpdesk faz, segundo a própria documentação:
- Zendesk. Uma automação padrão fecha tickets 4 dias depois de resolvidos. Dá para esticar isso para 28 dias, mas não dá para eliminar. Após o fechamento, "any response to a closed ticket from any channel automatically creates a follow-up ticket", segundo a documentação de acompanhamentos do Zendesk.
- Gorgias. Uma resposta a um ticket fechado o reabre, mas no e-mail uma resposta "more than 10 days after the last message" se divide em um ticket novo. Em chat, SMS, voz e DMs de redes sociais a divisão acontece após 3 dias, segundo a documentação de cobrança da Gorgias.
- HubSpot. Aqui a escolha é sua. A configuração de reabertura de tickets oferece Always reopen, Set a time frame ou Never reopen, no Service Hub Professional e Enterprise.
- Freshdesk. A métrica "Tickets reopened" conta tickets resolvidos ou fechados que voltam a Open. Quando um ticket fechado fica parado por 120 dias, ele é arquivado, e uma resposta então "creates a new ticket instead of reopening the archived one".
- Help Scout e Front. O Help Scout reabre conversas fechadas a menos que você defina um Conversation Lock. O Front fecha conversas de e-mail após 30 dias por padrão e divide respostas posteriores em uma nova conversa.
A versão do HubSpot dá o retrato mais claro do dilema, já que entrega a decisão inteira a você:
Então a conclusão é: se a sua instância do Zendesk ainda roda com o padrão de 4 dias, um cliente que volta no dia 5 é invisível para a sua taxa de reabertura. Um líder de suporte no Reddit explicou bem o lado do comportamento:
"Reopen rate helps too but people learn to just open a new ticket instead of reopening, so you really need the repeat contact window to catch it"
Se quiser mais detalhes do lado do Zendesk, escrevi sobre as condições de reabertura de tickets que você pode definir nas automações.
Por que a resolução no primeiro contato pode subir enquanto os repetidos também sobem
A outra armadilha que vale mencionar é a resolução no primeiro contato. A maioria dos helpdesks a calcula por ticket e não por problema, então um cliente que abre um ticket novo basicamente zera o relógio, o que passa a contar como uma vitória nova.
Se você olhar as definições nativas, vê como são estreitas:
- A métrica mais próxima do Zendesk são os one-touch tickets: resolvidos com uma resposta do agente ou nenhuma. Uma reabertura com uma pergunta nova tira, sim, um ticket de one-touch, mas um ticket de acompanhamento não mexe no original.
- O "Tickets resolved within FCR (%)" do Freshdesk exige zero respostas do cliente após o primeiro contato, segundo o glossário de métricas. E um ticket novo não é uma resposta.
- O Help Scout informa "Resolved on First Reply" no seu relatório de e-mail, de novo por conversa.
É assim que você acaba com uma história como esta:
"We hit 78% FCR last quarter. Leadership celebrated. Bought donuts and everything. Then I pulled the data on customers who contacted us 3+ times in 30 days. The number went up. Turns out we were "resolving" tickets by closing them, not by actually fixing the underlying issue."
Não estou dizendo para abandonar o FCR (escrevi um guia inteiro sobre IA para resolução no primeiro contato) nem a resolução one-touch, ambos são úteis. Só nunca os reporte sem o número de repetidos ao lado, do mesmo jeito que você não reportaria a taxa de resolução sem o CSAT.
Como medir a taxa de contato repetido
A fórmula que eu usaria é esta:
Taxa de contato repetido = tickets resolvidos em que o mesmo cliente entrou em contato de novo sobre o mesmo problema em até 7 dias ÷ todos os tickets resolvidos no período
Há algumas escolhas a fazer logo de início:
- Escolha uma janela e mantenha. 7 dias é um padrão sensato para e-mail e chat, enquanto call centers costumam usar 14 ou 30. Um comentarista do Reddit sugeriu checar reaberturas em 72 horas, para pegar agentes que fecham tickets pelas estatísticas. Seja qual for a sua escolha, não a mude no meio do trimestre.
- Cruze por cliente e problema, não só por cliente. Um cliente que escreve sobre um reembolso e, duas semanas depois, sobre um problema de login não é um repetido. Os agentes odeiam ser culpados por isso, e com razão.
- Conte entre canais. O mesmo cliente que manda um e-mail e depois abre um chat continua sendo um problema só, que o seu helpdesk pode não vincular.
Depois você puxa os números do que o helpdesk já oferece:
| Helpdesk | Reaberturas | Repetidos que viram tickets novos | Métrica estilo primeiro contato |
|---|---|---|---|
| Zendesk | "Reopened tickets" e "Reopens" no Explore | Acompanhamentos, filtrados pelo canal de atualização "Closed Ticket" | One-touch tickets |
| Freshdesk | "Tickets reopened" | Tickets novos após o arquivamento, encontrados pelos tickets arquivados do contato | Tickets resolved within FCR (%) |
| Gorgias | Grupo Reopened no novo relatório Helpdesk performance | Tickets divididos após 10 dias (e-mail) ou 3 dias (chat, SMS, voz) | Nenhuma métrica FCR nativa encontrada |
| HubSpot | Propriedade "Ticket reopen date" | Tickets novos vinculados ao original | Sem relatório FCR nativo |
| Help Scout | Conversas devolvidas a Active | Conversas novas, se o Conversation Lock estiver ativado | Resolved on First Reply |
| Front | "Reopened conversations" no relatório Workload | Novas conversas vinculadas após o fechamento | Sem métrica FCR nativa |
Nenhum deles entrega "mesmo problema" de fábrica, e a forma mais barata de chegar lá é uma tag. Quando um agente pega um ticket que claramente é um segundo contato, ele adiciona uma tag repeat e também uma tag de motivo. Uma resposta no Reddit colocou isso melhor do que eu poderia:
"You're right that three cheap contacts on one issue is not three wins. It is one unresolved problem with a growing cost and a customer who now expects the next reply to fail. Tag the second contact as a repeat of the first before anyone closes it again."
Se etiquetar à mão parece algo que não vai pegar, geralmente não pega, não depois da terceira semana. A etiquetagem de tickets com IA pode aplicar as tags de repetido e de motivo por você, e aí os números chegam aos relatórios do próprio helpdesk como qualquer outro campo.
Daí em diante é um relatório normal. No Zendesk eu adicionaria um widget de taxa de repetidos ao mesmo painel de analytics que a sua equipe já consulta, e na Gorgias as tags aparecem nas visões padrão do Gorgias analytics.
Quanto os tickets repetidos custam
Um ticket repetido custa mais do que o primeiro contato. O cliente está mais irritado, o agente precisa ler o histórico antes de responder e, além disso, você pagou duas vezes por um problema. O seu custo por ticket não mostra isso, porque, sozinho, cada ticket parece normal.
Coloque os seus próprios números abaixo, os valores padrão são só um exemplo.
Digite os seus tickets resolvidos por mês, a taxa de repetidos, o tempo de atendimento e o custo do agente para ver quanto os tickets de suporte repetidos custam e quanto vale reduzi-los pela metade.
O valor em dólares é só metade da história. Um cliente que precisa correr atrás de você três vezes é o que deixa a avaliação de uma estrela, e esse custo nunca aparece na conta do custo por resolução.
Por que os clientes escrevem de novo: as quatro causas raiz
Quando você puxa de 50 a 100 tickets repetidos e realmente os lê, os motivos caem em quatro grupos quase sempre, o que também bate com o que ouço das equipes de suporte nas chamadas da eesel.
1. O ticket foi fechado, mas o problema não foi resolvido
Esta é a grande, e geralmente é um problema de métricas antes de ser um problema de pessoas. Se os agentes são avaliados por tickets fechados, fechar vira o próprio objetivo.
"Resolution looks good because the ticket gets closed, but customers sometimes come back a few days later with basically the same problem."
Menos repetidos também significam menos tickets no total, e essa é a forma mais barata de reduzir o volume de tickets.
A solução aqui é fazer de "todos os problemas da mensagem resolvidos" parte da sua planilha de avaliação de QA, em vez de apenas se o ticket foi fechado. Calibre isso entre os avaliadores para que todos pontuem do mesmo jeito, expliquei isso em calibração de QA.
2. Nenhuma atualização enquanto o cliente esperava
Reembolsos e atrasos de entrega geram repetidos, escalonamentos de bugs também, porque do lado do cliente nada acontece por dias. Eles escrevem "any update?" porque ninguém disse quando viria a próxima atualização.
Essa é a razão de "onde está meu pedido" dominar as filas de e-commerce. Em uma chamada de vendas da eesel, um operador de e-commerce multimarcas com mais de 500 tickets por dia nos disse que pedidos de reembolso, cancelamentos de assinatura e rastreamento de pedidos dominam o volume dele, e essas são exatamente as categorias clássicas de repetidos.
A solução é o suporte proativo: termine cada resposta dizendo quando chegará a próxima atualização e configure uma automação que realmente a envie. A Gorgias pode fazer acompanhamento quando não há resposta, o Zendesk pode fazer o mesmo com automações baseadas em tempo.
Para o status do pedido em especial, um bot que lê o rastreamento ao vivo vence uma macro; comparei os dois neste guia sobre chatbots de status de pedido. Meu artigo sobre atendimento proativo vs reativo tem mais sobre os prós e contras.
3. Meia resposta, ou a errada
Uma resposta que responde a pergunta literal, mas não a próxima óbvia, é praticamente uma garantia de um segundo ticket. "Seu reembolso está sendo processado" convida a "quando vou receber?" As macros pioram isso quando são escritas para o caso comum e depois coladas no caso incomum.
"The responses are a push of a button by Customerservice representative and so patronizing because most the time they get it wrong."
Há duas soluções. Audite as suas macros com tickets reais (eu começaria pelo meu guia de macros com IA) e faça uma análise de lacunas de conhecimento para achar as perguntas que a sua central de ajuda não cobre, enquanto uma auditoria da base de conhecimento mais ampla encontra artigos que estão simplesmente desatualizados. Às vezes os documentos são escritos para o leitor errado: um gerente de suporte com quem conversamos tinha uma base de conhecimento escrita para administradores enquanto os tickets vinham de usuários finais, o que produzia respostas confusas.
4. O cliente teve que explicar tudo de novo
Repasses entre turnos, níveis e equipes perdem contexto, e a passagem do bot para um humano é a pior infratora. O cliente se repete e recebe uma resposta um pouco diferente, e então escreve uma terceira vez. Duplicatas entre canais são o mesmo problema visto do outro lado:
"Same customer would email twice about one issue, once from their phone, once from a laptop an hour later when they got worried nobody saw the first one, and we'd end up with two agents responding separately without realizing it was the same problem."
Comece ativando o que o seu helpdesk já tem. As sugestões de mesclagem do Zendesk mostram tickets do mesmo solicitante com duas semanas de margem para cada lado, e o auto-merge da Gorgias combina tickets abertos de um mesmo cliente. Os dois tipos de mesclagem são permanentes, então configure-os com cuidado.
Para os repasses, meus artigos sobre passagem de turno e escalonamento entre equipes cobrem as notas que evitam o recomeço total.
Como reduzir tickets de suporte repetidos: um plano de duas semanas
Você não precisa de uma ferramenta nova para começar, este é o plano que eu seguiria.
Semana um: encontre as suas duas principais causas
- Puxe de 50 a 100 tickets do último mês em que o mesmo cliente voltou em até 7 dias. Inclua também tickets de acompanhamento e divididos, não só reaberturas.
- Leia cada um e etiquete com uma das quatro causas acima. Adicione um quinto grupo "outros" e mantenha-o pequeno.
- Anote quem ou o que atendeu o primeiro contato, ou seja, qual grupo de agentes ou qual macro, ou se foi o bot.
- Depois conte. Na maioria das equipes, duas causas respondem pela maior parte dos repetidos.
Semana dois: corrija essas duas e meça de novo
- Para "nenhuma atualização durante a espera", adicione a linha da próxima atualização às suas principais macros e uma automação que a envie.
- Para "não foi realmente resolvido", adicione uma checagem de resolução no QA e pare de premiar a contagem bruta de fechamentos.
- Para "meia resposta", reescreva as três macros com mais repetidos e preencha as lacunas da central de ajuda; depois confira o texto com o seu guia de tom.
- Para "teve que explicar de novo", ative as sugestões de mesclagem ou o auto-merge e exija uma nota de repasse ao escalar.
- Confira as suas janelas de fechamento automático e de reabertura. Se o Zendesk ainda está no padrão de 4 dias, decida de propósito se é isso mesmo que você quer.
- Compare a taxa de contato repetido com a sua linha de base, junto com o CSAT e o customer effort score, para saber que os repetidos caíram porque os problemas foram resolvidos e não porque os clientes desistiram.
Uma análise de tickets de suporte completa aprofunda o passo um, caso você tenha mais volume do que consegue ler à mão.
Onde a IA ajuda e onde piora os repetidos
A IA pode reduzir tickets repetidos, mas também pode fabricá-los em escala. A diferença toda está em ela poder ou não chutar.
O modo de falha é mais ou menos assim: um chatbot responde cada pergunta com algo plausível e o chat se encerra, o painel conta uma deflexão, e então o cliente volta.
"How many customers finished a chat and come back 20 minutes later because the bot gave them a generic answer that didn't solve their issue? We're optimizing to close the ticket instead of solving the damn problem."
Às vezes também aparece uma semana depois em vez de na mesma sessão. Um desenvolvedor no Hacker News só descobriu cruzando a escolha do modelo com as reaberturas:
"our dashboard only tracked immediate task completion, and had no idea a cheaper model had quietly produced a worse answer that the customer reopened a week later."
Então, antes de confiar em qualquer IA na sua fila, eu pediria três coisas:
- Ela só responde quando tem confiança. Uma resposta errada dita com segurança é pior do que nenhuma, porque cria um repetido e também um cliente com raiva, então procure uma pontuação de confiança de verdade ou uma regra equivalente. Um líder de CX com 7.000 tickets por mês nos disse em uma chamada: "I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone." Esse é o padrão certo, e é por isso que a alucinação de IA importa mais para repetidos do que para qualquer outra coisa.
- Ela é testada nos seus tickets passados antes de entrar no ar. Não em um roteiro de demo, mas em tickets reais que você já resolveu, pontuados em relação ao que a sua equipe realmente enviou.
- Você consegue dividir a taxa de repetidos por quem atendeu. Se os tickets da IA voltam mais do que os dos seus agentes, você precisa conseguir ver isso, então etiquete todo ticket atendido pela IA.
Esta é a parte da eesel que eu apontaria. A skill Simulation reproduz o seu agente contra tickets passados reais e pontua cada resposta em relação à resposta da sua equipe; depois sugere mudanças nas instruções. Aqui está uma execução com 20 tickets resolvidos do Zendesk, em que ela coincidiu com a equipe em 17 e sinalizou os dois que precisavam de uma pessoa:
A mesma lista de skills inclui "Analyze ticket trends" para temas recorrentes e "Update knowledge base", que encontra perguntas que a sua central de ajuda não responde e redige os artigos que faltam. Isso cobre as causas raiz dois e três mais ou menos no piloto automático. Quando ela erra uma, você corrige no chat e a correção vira uma instrução permanente, para que o mesmo erro não crie o mesmo repetido na semana que vem. Meu artigo sobre análise de erros percorre esse ciclo.
Há também um detalhe de preço que importa aqui. Na página de preços da eesel, um ticket é 1 crédito "however many replies go back and forth". Um cliente que reabre um ticket não custa um segundo crédito, um ticket repetido totalmente novo custa, então reduzir repetidos diminui a sua fatura da eesel além da carga dos seus agentes.
O que ela não é: uma solução para um processo de reembolso quebrado ou para um parceiro de entrega que perde pacotes. Se a causa raiz está fora do suporte, a IA só responde o repetido mais rápido.
Reduza tickets repetidos com a eesel
Se a sua fila está cheia de clientes escrevendo de novo sobre o mesmo problema, o colega de helpdesk com IA da eesel entra na configuração de Zendesk, Freshdesk, Gorgias ou HubSpot que você já usa e aprende com os seus tickets passados, macros e central de ajuda. Ele responde só o que consegue resolver e passa o resto para a sua equipe, e você pode reproduzi-lo nos tickets do mês passado para ver onde ele teria causado um repetido antes que qualquer cliente veja uma resposta. A líder de suporte da Gridwise descreveu o resultado assim após um mês:
"In the first month, eesel is resolving 73% of our tier 1 requests ... Responses are simple to fix and adjust."
Kim Simpson, Gridwise
Começar é grátis com 100 créditos, e os planos pagos começam então em $299 por mês por 500 créditos.
