Resumo
Gestão de exceções no suporte são três tarefas: decidir quem pode flexibilizar qual política, registrar toda exceção do mesmo jeito e revisar o registro para que exceções repetidas virem regras. A maioria das equipes faz a primeira de forma frouxa e pula as outras duas, e é por isso que o mesmo cliente ouve um sim de um agente e um não do seguinte.
A mudança que eu defendo: uma exceção que você concede quase sempre já é a sua política, só que ela não está escrita. E o lugar para pegá-la não é uma nota interna. É um campo de lista suspensa obrigatório sobre o qual o seu helpdesk consiga gerar relatórios. Cuidado com as armadilhas, porém: o "obrigatório para resolver" do Zendesk pode ser contornado por gatilhos, automações e mesclagens, e o relatório de campos de ticket do Gorgias só conta campos de lista suspensa.
Eu trabalho na fila de suporte da eesel todos os dias, e nas exceções tanto agentes quanto IA precisam das regras mais claras. Em um teste com tráfego real numa caixa de entrada de ecommerce no Zendesk, 96,4% dos rascunhos da eesel em pedidos de garantia foram úteis para o agente. É para isso que o colega de IA da eesel foi feito: ele aplica as exceções que você deixou escritas, retém para a pessoa certa tudo o que custa dinheiro e passa o resto para a sua equipe com uma nota.
O que conta como exceção de suporte
Uma exceção é qualquer momento em que um agente dá ao cliente algo que a política escrita não prevê. Algumas são minúsculas e outras custam dinheiro de verdade, mas todas têm uma coisa em comum: dependem de um julgamento, então dois agentes podem decidir de forma diferente no mesmo ticket.
Estas são as que mais vejo na fila, com a política que cada uma flexibiliza:
| Tipo de exceção | Exemplo | A política que flexibiliza | Responsável típico |
|---|---|---|---|
| Reembolso ou devolução fora do prazo | Reembolso no dia 41 de um prazo de 30 dias | Prazo de devolução | Líder de equipe |
| Isenção de taxa | Dispensar uma vez a taxa de reposição ou de atraso | Tabela de taxas | Agente, dentro de um orçamento |
| Crédito de cortesia | Crédito de US$ 10 após uma entrega atrasada | Nenhuma, é discricionário | Agente, dentro de um orçamento |
| Exceção de garantia | Substituir um item recém-saído da garantia | Termos de garantia | Líder de equipe ou responsável de produto |
| Exceção de venda final | Aceitar a devolução de um item de liquidação | Regra de venda final | Gerente |
| Crédito de serviço ou SLA | Crédito por indisponibilidade em um plano B2B | Termos do contrato | Gerente de contas ou financeiro |
Essa última coluna importa mais do que parece. A maioria das equipes tem uma matriz de aprovação de reembolsos ou pelo menos um limite em dólares para reembolsos. Pouquíssimas têm a mesma clareza para o resto da tabela, então isenções de taxas e créditos de cortesia acabam decididos pelo humor.
Por que exceções sem gestão custam mais do que as próprias exceções
O custo de uma exceção não é só o crédito de US$ 10. É o que acontece quando as exceções são inconsistentes, invisíveis e impossíveis de revisar.
Os clientes aprendem a procurar outro agente. Se a resposta depende de quem atende, o movimento esperto é perguntar de novo. As pessoas dizem isso abertamente:
"I've learned to play customer service roulette.
Don't get the answer I'm looking for?
Hang up and call back."
As exceções se escondem dentro de outras categorias. Quando os agentes não têm um jeito autorizado de conceder algo, encontram um não autorizado. Um comentarista descreveu como funciona em bancos e emissores de cartão:
"If you're not yelling at them, you can often get what you want via some other method (which only they know) - like them reclassifying the problem to something else they have leeway for."
Esse ticket reclassificado agora aparece nos seus relatórios como algo que não era. Sua marcação de tickets está errada e a exceção é invisível.
Exceções prometidas somem. A pior versão é uma exceção combinada, mas nunca registrada. Um cliente no r/Comcast_Xfinity descreveu ter chegado a uma solução com o suporte por telefone: "they said they would note this on my account. I reached back out after a week to confirm the notes on the account an there is no record of the solution offered" (cali1302, Reddit). Agora o próximo agente precisa escolher entre honrar uma promessa que não consegue ver ou chamar o cliente de mentiroso.
Pequenas recusas viram grandes precedentes. O exemplo mais conhecido é o caso do chatbot da Air Canada, em que um reembolso por luto recusado foi parar diante de um tribunal. Um comentarista do Hacker News resumiu: isso "should've been well within some second-tier customer service manager's discretionary refund budget. Instead they've got a precedent-setting ruling that makes the chatbot a huge liability" (ceejayoz, Hacker News).
O ciclo de gestão de exceções no suporte
Toda exceção deve passar pelos mesmos cinco passos. O que a maioria das equipes pula é a última seta, da revisão mensal de volta à política escrita. Sem ela, você concede a mesma exceção 40 vezes por mês para sempre e nunca percebe que ela deveria ter virado regra.
O restante deste guia percorre o ciclo em ordem: quem decide, como registrar, quais ferramentas já tratam exceções pontuais, como revisar e como dar ao seu agente de IA as mesmas regras que suas pessoas seguem.
Passo 1: Decida quem pode conceder o quê
Comece classificando as exceções com duas perguntas: de quem é a culpa e quanto custa? Essas duas respostas dizem quem deve decidir muito melhor do que um único limite em dólares.
O quadrante inferior esquerdo é o que as pessoas erram. Se uma remessa atrasou por sua causa e a solução custa menos do que o tempo de aprová-la, nem deveria ser uma exceção. Um funcionário de varejo defendeu bem o argumento da folha de pagamento:
"Especially on clothes that have a ridiculously high margin, it's costs more money in payroll wasting that time than just giving them a BOGO."
Para todo o resto, dê a cada função um orçamento de discricionariedade por escrito. Os bancos já funcionam assim. Como disse um comentarista, "most banks/credit cards let the first-level hit the 'refund one fee' button, and the higher up you get, the more discretion they have" (bombcar, Hacker News). O orçamento deve dizer três coisas:
- O que a função pode conceder por conta própria. Por exemplo: uma isenção de taxa por cliente por ano, créditos de cortesia de até US$ 15, devoluções até 7 dias após o prazo.
- O que ela não pode conceder de jeito nenhum. Exceções de venda final, créditos contratuais, qualquer coisa que envolva um estorno em aberto.
- A quem pedir o resto. Uma pessoa nomeada e uma substituta, não "o canal dos líderes". Se precisar de uma revisão sobre roteamento, meu guia do processo de escalonamento de tickets cobre isso.
Mais uma coisa para escrever: para que serve a exceção. Sem isso, a discricionariedade tende a quem insiste mais. Um agente no r/talesfromcallcenters descreveu supervisores que "pick to be nice to rude people and give hard stops to really nice people" (Asha990, Reddit). Uma frase como "créditos de cortesia são para falhas de serviço do nosso lado, não para quem insiste" resolve muita discussão antes de ela começar.
Passo 2: Registre cada exceção em um campo, não em uma nota
Esta é a parte que quase todo guia de exceções pula. Uma nota no ticket ("concedido reembolso de cortesia único") é melhor do que nada, mas notas não dá para contar. Para revisar exceções, você precisa de dados estruturados, e num helpdesk isso significa campos de ticket personalizados.
O padrão que eu configuraria são quatro campos, três deles aparecendo só quando o primeiro é Sim:
- Exceção concedida: uma lista suspensa com Não e Sim. Torne-a obrigatória ao fechar o ticket.
- Tipo de exceção: uma lista suspensa com os tipos da tabela acima.
- Motivo da exceção: uma lista suspensa de motivos (atraso da transportadora, item danificado, nosso erro, circunstância do cliente), mais uma opção "outro".
- Valor e aprovador: um campo numérico para o custo e uma lista suspensa com os nomes dos aprovadores.
Listas suspensas vencem o texto livre por um motivo simples. A própria documentação do Zendesk diz que valores de campos de texto "podem ser inconsistentes ou conter erros de ortografia", o que os torna "menos úteis para relatórios" (Zendesk). O conselho do Freshdesk é o mesmo: "favor dropdowns over text fields where possible" (Freshdesk).
O que cada helpdesk suporta
Todo grande helpdesk consegue fazer alguma versão disso, mas as restrições de plano e os limites diferem bastante. Isto é o que a documentação diz hoje:
| Helpdesk | Campos de lista suspensa personalizados | Mostrar campos só com "Sim" | Obrigatório ao fechar | Relatório sobre o campo |
|---|---|---|---|---|
| Zendesk | Todos os planos, até 2.000 valores | Suite Growth e acima | "Required to solve", todos os planos | Explore, Suite Professional e acima |
| Freshdesk | Growth e acima (não Free) | Campos dependentes Growth+, seções dinâmicas Pro+ | "Required when closing", Growth+ | Relatórios personalizados, Pro e acima |
| Gorgias | Todos os planos, 25 campos ativos | Todos os planos, até 70 condições | Todos os planos | Relatório de campos de ticket, todos os planos, só listas suspensas |
| HubSpot Service Hub | Todos os planos, até 5.000 opções | Professional e acima | Propriedades de etapa obrigatórias no pipeline | Relatórios personalizados, Professional e acima |
| Help Scout | Plus e Pro, 10 campos por caixa de entrada | Não documentado | Obrigatório ao responder, não ao fechar | Plus e Pro |
No Zendesk, a parte de "mostrar só com Sim" é um campo condicional. O editor de condições também permite tornar os campos dependentes obrigatórios por status, de modo que o Tipo de exceção só se torna obrigatório quando o ticket é resolvido:
O Gorgias faz o mesmo com condições de campo, em todos os planos do Helpdesk:
Quatro armadilhas nas letras miúdas
São os detalhes que quebram em silêncio um registro de exceções seis semanas depois de configurado:
- O campo obrigatório do Zendesk tem furos. A configuração está em todo campo, mas a documentação do Zendesk diz que campos obrigatórios "podem ser contornados por gatilhos e automações" e "também são ignorados quando um agente mescla um ticket" (Zendesk). A solução sugerida é uma tag
okay_to_closeque a sua automação de fechamento aguarda. - O Gorgias só gera relatório de listas suspensas. Seu relatório de campos de ticket "só acompanha campos de ticket personalizados do tipo lista suspensa", então campos Número, Texto e Sim/Não não aparecem (Gorgias). Faça de Exceção concedida uma lista suspensa, não um campo Sim/Não. O Gorgias também observa que seu AI Agent "pode fechar um ticket sem ter preenchido um campo de ticket obrigatório" (Gorgias).
- O Help Scout verifica ao responder, não ao fechar. Campos personalizados obrigatórios precisam ser preenchidos "ao enviar uma resposta", e os dados do campo não acompanham se a conversa for movida para outra caixa de entrada (Help Scout).
- Excluir um campo apaga o seu histórico. O Freshdesk diz que remover um campo "o oculta no Analytics", e o Help Scout diz que excluir um apaga seus dados "para sempre". Arquive tipos de exceção antigos em vez de excluí-los.
Um bônus para equipes de Zendesk no Suite Professional ou acima: o conjunto de dados Updates history do Explore pode acompanhar mudanças nos valores dos campos ao longo do tempo (Zendesk), o que responde a "quem mudou isto para Sim, e quando". Minha receita de campos personalizados no Explore percorre o relatório.
Passo 3: Use as ferramentas que já tratam exceções pontuais
Seu helpdesk registra a exceção. Mas a ação em si muitas vezes acontece em outra ferramenta: o app de devoluções, o admin da loja, o sistema de cobrança. Várias delas têm um mecanismo de exceção próprio, e usá-lo é melhor do que um agente contornando as regras.
| Ferramenta | Mecanismo de exceção pontual | O que registra |
|---|---|---|
| Loop Returns | Colocar um pedido ou e-mail na lista de permitidos para sobrepor o prazo de devolução, a venda final ou a lista de bloqueio | Entrada na lista, exportável em CSV |
| Redo | Redefinir uma devolução recusada na etapa Policy Window ou Final Sale Check | O histórico de processamento da devolução |
| Shopify | A equipe cria a devolução no admin e edita taxas por devolução | Motivos de recusa são só internos |
| AfterShip Returns | Lista de permitidos por pedido, tipo de produto, e-mail ou tag | Até 20 motivos de recusa predefinidos |
| Stripe Billing | Ajuste de saldo de crédito com nota interna | Uma "lista imutável" de transações |
A Loop é o modelo mais claro. Seu recurso Listings existe "para gerenciar exceções e restrições de devolução", e colocar um pedido na lista de permitidos "sobrepõe qualquer entrada da lista de bloqueio, produtos marcados como Final Sale ou o prazo de devolução do pedido" (Loop). Gosto ainda mais da melhor prática da própria Loop: permitir o pedido, enviar a devolução pelo cliente e remover a entrada da lista logo em seguida. Uma exceção temporária que se limpa sozinha é exatamente o que você quer. A Loop também orienta compradores fora do prazo a "contact your support team directly for any exceptions" (Loop), então esses tickets chegarão à sua fila, você planejando ou não.
O Loop Workflows transforma exceções repetidas em regras. Quando a revisão do Passo 4 disser que uma exceção deve virar política, o Workflows pode aplicá-la automaticamente, com ações como Bypass final sale, Set return window e Set handling fee para "sobrepor, somar ou isentar taxas existentes" (Loop Workflows). Falei mais sobre isso no meu guia de automação de devoluções.
As regras da Shopify podem carregar as exceções que você já conhece. Sobreposições do prazo de devolução permitem dar 14 dias a itens de liquidação e 90 a móveis, e itens de venda final são descritos como "exceções às suas regras de devolução padrão" (Shopify). O que não encontrei na documentação da Shopify é um interruptor para tornar um pedido elegível quando as regras dizem que não. O caminho documentado é uma devolução criada pela equipe no admin, onde as taxas podem ser editadas por devolução.
O saldo de crédito da Stripe é um crédito de cortesia com trilha de auditoria embutida. Todo saldo de cliente é "calculado a partir de um livro-razão, uma lista imutável de transações de débito e crédito" (Stripe). Cada ajuste pode levar uma nota interna que o cliente nunca vê, e as entradas não podem ser excluídas, apenas estornadas. Se os créditos de cortesia do seu produto SaaS vivem em qualquer outro lugar, são mais difíceis de auditar do que precisam ser.
Passo 4: Revise o registro e promova exceções repetidas
É aqui que a gestão de exceções se paga. Uma vez por mês, puxe todos os tickets com Exceção concedida em Sim e agrupe-os por tipo e motivo. Para cada grupo, você faz uma pergunta: isto é uma exceção de verdade ou uma regra não escrita?
Do lado do cliente, exceções sem revisão parecem aleatórias. Um comentarista, depois de receber alívio de um supervisor, escreveu: "There's no particular rhyme or reason for why extraordinary relief is sometimes granted though, it seems completely random!" (gnicholas, Hacker News). Do lado da equipe, é pior: você gasta tempo de aprovadores em decisões que toma do mesmo jeito sempre.
Escolha um tipo de exceção do mês passado e coloque os números dele aqui:
Os limites do widget (10 solicitações por mês, 80% concedidas) são meu ponto de partida, não um padrão do setor. Ajuste-os ao seu volume. O que importa é que a revisão termine em uma de quatro decisões, e que cada decisão mude alguma coisa:
- Transformar em política. Atualize a política escrita e a central de ajuda, atualize suas macros e avise agentes e o seu agente de IA no mesmo dia. Meu guia de gestão de mudanças de políticas de suporte cobre a implantação.
- Manter como discricionariedade do agente. Deixe dentro do orçamento, mas continue registrando.
- Enviar a um aprovador nomeado. Alto custo, ou um padrão em que você quer um segundo par de olhos.
- Roteirizar o não. Se você recusa uma solicitação em 80% das vezes, os 20% de sins ensinam os clientes a continuar pedindo. Como disse um funcionário de varejo, "They are getting something out of it, so it continues" (Cheshire1871, Reddit).
A revisão também alimenta outros dois ciclos. Agentes cuja taxa de exceções está muito longe da média da equipe são uma conversa de coaching, e é aí que entram a calibração de QA de suporte e o feedback aos agentes. E um pico em um motivo, como atrasos de transportadora, é um problema de operações que o suporte paga em silêncio. Sinalize-o junto com o restante da sua análise de tickets de suporte.
Passo 5: Dê ao seu agente de IA regras de exceção por escrito
Agentes de IA tornam a gestão de exceções mais urgente, não menos. Uma pessoa consegue ler o ambiente e flexibilizar uma regra discretamente. Um agente de IA ou segue as regras que você escreveu ou improvisa, e os dois tipos de falha aparecem em público.
A primeira preocupação é que os clientes convençam a IA a abrir exceções:
"People will find out how to convince the LLM you do meet the requirements for a refund.
And if you check the requirements using something deterministic (last order was within last 2 weeks, customer has a high loyalty points score, they're subscribed to some premium service) then why do you need an agent at all?"
A falha oposta é igualmente ruim: um bot que não consegue conceder uma exceção e não deixa o cliente chegar a alguém que consiga. Um cliente descreveu um chat de suporte com IA que ficava oferecendo cancelar no fim do período de cobrança: "I ask for human. It repeats. I ask for human again. It repeats. I disconnect" (kldg, Hacker News).
A resposta para ambos é a mesma que para as pessoas. Escreva as exceções que a IA pode aplicar como regras simples, dê a ela um limite firme em tudo o que movimenta dinheiro e garanta que qualquer outro pedido de exceção chegue a um humano com contexto. São guardrails de IA aplicados à política, e o caminho de escalonamento de IA é metade disso.
As principais ferramentas de IA para helpdesk já oferecem esse formato:
| Ferramenta de IA | Como você escreve regras de exceção | O que acontece com o resto |
|---|---|---|
| Zendesk AI agents | Generative procedures com contexto de política, como "Sem reembolsos em liquidação", e segmentos por tipo de cliente | Uma etapa "Escalate to" passa para uma pessoa ou equipe e a IA para |
| Gorgias AI Agent | Skills com limites, como "não se comprometa com um reembolso antes de o item devolvido chegar" | Tópicos de transferência que você escreve em linguagem natural, mais gatilhos embutidos que "não podem ser desativados" |
| eesel | Instruções em linguagem natural com um modelo de "exceções e casos extremos" | Escala com uma nota interna; ações com dinheiro aguardam aprovação |
O construtor de procedimentos do Zendesk é uma boa imagem do que significa "deixar a exceção por escrito" para uma IA. Você descreve a política em linguagem natural, e ele monta um mapa com ramificações e uma verificação antes de qualquer coisa irreversível acontecer (Zendesk):
A documentação do Zendesk também é honesta sobre o limite: o contexto em um procedimento não pode "garantir o comportamento exato da IA", e tudo o que precisa ramificar deve usar um bloco Check condition (Zendesk). Esse é o instinto certo. A redação orienta a IA, mas limites firmes sobre dinheiro pertencem às configurações de ações.
Como eu escreveria regras de exceção com a eesel
Na eesel, as exceções vão nas instruções do agente em linguagem natural, do mesmo jeito que você orientaria um novo contratado. A documentação traz um modelo "Cover exceptions and edge cases" com linhas como "Reclamações de dano abaixo de US$ 50: pule o pedido de foto, aprove o reembolso" e "Pedidos feitos na última hora: cancelamentos não precisam de aprovação", além de uma regra de que clientes com a tag VIP sempre escalam (documentação da eesel). O modelo de escalonamento cobre a outra metade: deixar uma nota interna que diga "o que o cliente quer, o que você encontrou e o que você teria respondido" e atribuí-la a uma pessoa.
Você também pode corrigir o agente como corrigiria uma pessoa. Um administrador de suporte com quem trabalhei ensinou ao agente uma regra que é, na verdade, uma política de exceção: um pedido de cancelamento ou reembolso com um problema não resolvido recebe primeiro a solução do problema:
"I have a rule in CS where we do not address a cancel or refund request when there is an issue attached to it."
Um administrador de suporte codificando uma política de "resolva antes de cancelar" no agente
Para tudo o que custa dinheiro, as configurações de ações garantem o cumprimento. Cada ação tem uma de três configurações por agente: Auto, Needs approval ou Disabled (documentação da eesel). Você pode deixar uma ação em Auto e ainda assim dizer ao agente que pergunte antes em situações específicas, que é como uma política de exceção escrita vira uma barreira de verdade. Quando uma aprovação é necessária, o aprovador vê a ação exata e o valor, e as aprovações nunca são executadas sozinhas após um tempo limite.
A página Activity registra quem aprovou o quê e quando, o que serve de registro de exceções para tudo o que a IA tocou.
Erros comuns na gestão de exceções
Estes são os que eu corrigiria primeiro, mais ou menos na ordem do que custam:
- Registrar exceções em notas. Notas não dá para contar. Use uma lista suspensa obrigatória e, no Gorgias, garanta que seja uma lista suspensa e não um campo Sim/Não.
- Não ter orçamento de discricionariedade. Sem um, cada agente inventa o seu, e os clientes aprendem a pedir a um segundo agente. Escreva o que cada função pode conceder.
- Tratar exceções por culpa nossa como favores. Um crédito por entrega atrasada que você concede sempre deveria ser uma regra. Fazer o cliente pedir só gera tickets e prejudica o CSAT.
- Nunca fechar o ciclo. Se a revisão mensal não muda a política, a central de ajuda ou as macros, é só um relatório. Todo tipo de exceção deve terminar a revisão com uma decisão.
- Deixar a IA improvisar. Um agente de IA sem regras de exceção escritas diz não a tudo ou sim às coisas erradas. Dê a ele regras, um limite de dinheiro e um caminho de escalonamento limpo.
- Excluir campos antigos. Arquive tipos de exceção aposentados para que os dados do ano passado ainda apareçam nos relatórios.
Trate exceções de suporte com a eesel
Se sua equipe trabalha com Zendesk, Gorgias ou Freshdesk, o colega de IA para helpdesk da eesel é o caminho mais direto para fazer suas regras de exceção pegarem. Ele entra na sua fila existente, aprende com seus tickets anteriores, sua central de ajuda e suas macros, e segue as exceções que você escreve em linguagem natural. Tudo o que custa dinheiro espera a aprovação da pessoa certa, no painel ou no Slack, e tudo o que está fora das suas regras vai para a sua equipe com uma nota explicando o que o cliente quer e o que ele encontrou.
Antes de ele tratar uma exceção real, você pode rodar uma simulação nos seus tickets passados e comparar as respostas dele com o que sua equipe realmente enviou. O preço é por ticket com assentos ilimitados, então todo aprovador pode ter acesso, e você pode começar com 100 créditos grátis e sem cartão. Experimente a eesel.