How to resolve 70% of support tickets without a human agent Como resolver 70% dos tickets de suporte sem um agente humano
If you run support for a growing ecommerce or SaaS company, you already know the pattern: the same twenty types of requests make up 70 to 80 percent of your ticket volume. Order status. Return eligibility. Refund status. Account password. Subscription changes. These are not hard problems. They are repetitive ones.
Se você gerencia suporte para uma empresa de e-commerce ou SaaS em crescimento, já conhece o padrão: os mesmos vinte tipos de solicitações compõem 70 a 80% do volume de tickets. Status de pedido. Elegibilidade de devolução. Status de reembolso. Senha de conta. Alterações de assinatura. Esses não são problemas difíceis. São repetitivos.
Why most automation fails
Por que a maioria das automações falha
Traditional chatbots fail because they operate from decision trees. They cannot read context, interpret natural language, or look up live data. A customer who says "my package was supposed to arrive yesterday" gets routed to a FAQ article. The result is not automation, it is deflection that makes the customer angrier.
Chatbots tradicionais falham porque operam a partir de árvores de decisão. Eles não conseguem ler contexto, interpretar linguagem natural ou consultar dados ao vivo. Um cliente que diz "meu pacote deveria ter chegado ontem" é direcionado para um artigo de FAQ. O resultado não é automação, é deflexão que deixa o cliente mais irritado.
The second failure mode is automation that cannot take action. A bot that can look up an order but cannot issue a refund or generate a return label is not resolving anything. It is making the customer repeat themselves to a human agent who does the actual work.
O segundo modo de falha é a automação que não pode executar ações. Um bot que consegue consultar um pedido mas não pode emitir um reembolso ou gerar uma etiqueta de devolução não está resolvendo nada. Ele está fazendo o cliente se repetir para um agente humano que faz o trabalho real.
The playbook: what actually works
O playbook: o que realmente funciona
Step 1: Audit your ticket categories
Passo 1: Audite suas categorias de tickets
Pull your last 90 days of tickets. Tag each one by root cause. In most ecommerce operations you will find that five to eight categories account for 65 to 75 percent of volume: order status, return request, refund status, product question, address change, redelivery, discount code, and account access.
Puxe seus últimos 90 dias de tickets. Marque cada um por causa raiz. Na maioria das operações de e-commerce você vai descobrir que cinco a oito categorias representam 65 a 75% do volume: status de pedido, solicitação de devolução, status de reembolso, pergunta de produto, troca de endereço, reentrega, código de desconto e acesso à conta.
Step 2: Map which categories require only data lookup
Passo 2: Mapeie quais categorias exigem apenas consulta de dados
Of those categories, some require only a lookup: order status, refund status, tracking update. Others require an action against a system: issue a refund, generate a label, update an address. Others require judgment: a customer claiming a product was defective who is on their fifth return this year.
Dessas categorias, algumas exigem apenas uma consulta: status de pedido, status de reembolso, atualização de rastreamento. Outras requerem uma ação em um sistema: emitir um reembolso, gerar uma etiqueta, atualizar um endereço. Outras exigem julgamento: um cliente alegando que um produto era defeituoso que está na quinta devolução do ano.
The goal is not to automate everything. It is to automate the categories that require only lookup or a deterministic action against your existing policies. These are the 70 percent.
O objetivo não é automatizar tudo. É automatizar as categorias que exigem apenas consulta ou uma ação determinística contra suas políticas existentes. Esses são os 70%.
Step 3: Give your operator read and write access
Passo 3: Dê ao seu operador acesso de leitura e escrita
The operator needs to read your order management system, your CRM, and your helpdesk macros and policies. It also needs to write: issue refunds within your defined thresholds, generate return labels, update shipping addresses, close tickets. Without write access, you have a search engine, not an operator.
O operador precisa ler seu sistema de gerenciamento de pedidos, seu CRM e as macros e políticas do seu helpdesk. Ele também precisa escrever: emitir reembolsos dentro dos seus limiares definidos, gerar etiquetas de devolução, atualizar endereços de envio, fechar tickets. Sem acesso de escrita, você tem um mecanismo de busca, não um operador.
Step 4: Set thresholds, not rules
Passo 4: Defina limiares, não regras
Define what the operator can approve autonomously: refunds under 50 EUR, returns within 30 days of purchase, address changes before dispatch. Above the threshold, the operator collects context and routes to a human with all relevant data already in the ticket. The human makes the decision in 30 seconds instead of five minutes.
Defina o que o operador pode aprovar de forma autônoma: reembolsos abaixo de 50 EUR, devoluções dentro de 30 dias da compra, troca de endereço antes do envio. Acima do limiar, o operador coleta contexto e encaminha para um humano com todos os dados relevantes já no ticket. O humano toma a decisão em 30 segundos em vez de cinco minutos.
Step 5: Measure first-message resolution, not deflection
Passo 5: Meça resolução na primeira mensagem, não deflexão
The right metric is not containment rate or deflection rate. It is first-message resolution: did the customer get their answer or their action completed in the first response, without further back and forth? A well-configured operator on WhatsApp hits 65 to 75 percent first-message resolution within 60 days of going live.
A métrica certa não é taxa de contenção ou deflexão. É resolução na primeira mensagem: o cliente recebeu sua resposta ou ação concluída na primeira resposta, sem idas e vindas adicionais? Um operador bem configurado no WhatsApp atinge 65 a 75% de resolução na primeira mensagem dentro de 60 dias após entrar em produção.
What to expect in the first 30 days
O que esperar nos primeiros 30 dias
Week 1: the operator handles the lookup-only categories reliably. Order status, refund status, shipping updates. Human agents see a 25 to 35 percent drop in incoming volume.
Semana 1: o operador lida de forma confiável com as categorias de apenas consulta. Status de pedido, status de reembolso, atualizações de envio. Agentes humanos veem uma queda de 25 a 35% no volume recebido.
Weeks 2 to 4: return and refund actions are turned on within policy thresholds. Human review is added to edge cases. Resolution rate climbs to 55 to 65 percent.
Semanas 2 a 4: as ações de devolução e reembolso são ativadas dentro dos limiares da política. A revisão humana é adicionada aos casos extremos. A taxa de resolução sobe para 55 a 65%.
Days 30 to 60: thresholds are refined based on real escalation patterns. The operator learns which edge cases are actually routine. Resolution rate reaches 70 to 75 percent.
Dias 30 a 60: os limiares são refinados com base nos padrões reais de escalada. O operador aprende quais casos extremos são realmente rotineiros. A taxa de resolução atinge 70 a 75%.
The remaining 25 to 30 percent are the tickets that actually require a human: complex disputes, policy exceptions, high-value customer retention decisions. Those are the conversations your team should be having.
Os 25 a 30% restantes são os tickets que realmente precisam de um humano: disputas complexas, exceções de política, decisões de retenção de clientes de alto valor. Essas são as conversas que sua equipe deveria estar tendo.