O que é uma matriz de aprovação de reembolsos no suporte (e por que um único limite não basta)
A maioria das equipes começa com uma única regra: "agentes podem reembolsar até X $, qualquer valor acima vai para um gerente". Funciona até o primeiro reembolso de 20 $ para um cliente que já pediu seis reembolsos neste trimestre, ou o primeiro reembolso de 400 $ que obviamente é culpa do depósito e deveria sair em um minuto.
Uma matriz resolve isso adicionando um segundo eixo. O valor define o aprovador inicial, e os sinais de risco o movem para cima ou para baixo. Estas são as dimensões que eu incluiria, na ordem em que importam:
| Dimensão | Por que importa | Move o aprovador |
|---|---|---|
| Valor do reembolso | O custo de um sim errado | Define a faixa inicial |
| Dentro ou fora da política | Prazo de devolução, venda final, comprovação de dano | Fora da política sobe um nível |
| Histórico de reembolsos do cliente | Clientes que reembolsam com frequência são onde o abuso se esconde | Cliente que reembolsa com frequência sobe um nível |
| Forma de reembolso | Crédito na loja e substituições mantêm o dinheiro no negócio | Crédito ou substituição pode descer um nível |
| Disputa ou chargeback aberto | Reembolsar agora pode pagar duas vezes | Sempre vai para o responsável por disputas |
Essa última linha não é teórica. A Stripe cobra uma taxa de disputa de US$ 15,00 por cada disputa recebida, mais outros US$ 15,00 se você contestar, e a taxa de chargeback do PayPal é de US$ 20,00 nos EUA. Nenhum dos dois processadores devolve as taxas da transação original quando você reembolsa: a Stripe diz que as "taxas de processamento da transação original não são devolvidas" em sua documentação de reembolsos.
Os donos de lojas Shopify aprendem a regra do chargeback do jeito difícil:
"Também conheço donos de loja que se queimaram ao reembolsar e depois receber um chargeback. Eles perdem 3x (o pedido, o reembolso e o chargeback). Um reembolso não garante encerrar nem impedir um chargeback. Se há um chargeback em andamento, de jeito nenhum reembolse."
Veja como fica uma matriz preenchida com limites de exemplo. Os números são um ponto de partida, não uma recomendação para todos os negócios; uma marca de joias e uma loja de capinhas de celular de 12 $ precisam de faixas bem diferentes.
Monte sua própria matriz de aprovação de reembolsos
Insira seus próprios limites e teste um reembolso que você tratou esta semana. A matriz é redesenhada enquanto você digita, e o painel à direita diz quem deveria aprovar o caso de teste e por quê.
Como definir os limites em dólares
O objetivo de um limite não é impedir reembolsos ruins. É garantir que o custo de checar seja menor que o custo de errar. Quando um gerente gasta dez minutos em um reembolso de 12 $, essa checagem custa mais que o reembolso, e o cliente esperou na linha por isso.
Os clientes percebem. Um comentarista do Hacker News descreveu uma empresa em que os atendentes só podiam autorizar valores minúsculos:
"Os atendentes do serviço de atendimento ao cliente literalmente me diziam que só podiam autorizar um reembolso de 1 $. 2 $ era "demais" e exigia todo tipo de aprovação do gerente, e nunca havia um gerente disponível..."
No outro extremo está a regra de empoderamento mais citada no suporte, que aparece toda vez que esse debate surge:
"[...] o Ritz Carlton, como é famoso, dá a cada funcionário 2.000 $ de gasto discricionário para consertar as coisas para um hóspede sem burocracia. Contrate boas pessoas, confie em boas pessoas, dê poder a boas pessoas."
A maioria das equipes fica em algum ponto entre os dois, e os grandes contact centers tendem a empilhar os níveis. Um comentarista do r/verizon descreveu os limites deles assim: "Supervisores podem aprovar até cerca de 300 $ em créditos, e o que sobrar sobe para os gerentes deles" (Reddit).
Colocada no papel, uma matriz pode ser surpreendentemente curta. Um comentarista do Hacker News esboçou uma política de reembolso completa em três condições:
"Por exemplo, qualquer cliente pode fazer suas primeiras 2 devoluções sem perguntas, desde que o valor seja inferior a 200 $, 1 reembolso integral se o valor for inferior a 50 $, e todas as devoluções abaixo de 200 $ são aceitas desde que a taxa geral de devolução na conta dele seja inferior a 15%. Se nenhuma dessas condições for cumprida, escale."
Assim eu escolheria os números de cada faixa:
- Faixa automática. Comece no valor de reembolso em que você já aprova quase tudo. Levante os reembolsos do último trimestre, encontre o valor abaixo do qual os gerentes disseram sim em mais de 95% das vezes e coloque a linha automática logo abaixo. Mantenha essa faixa estritamente dentro da política.
- Faixa do agente. De um a três pedidos médios é um ponto de chegada comum. Os agentes devem conseguir resolver um pedido normal com problema sem colocar ninguém em espera.
- Faixa do líder de equipe. É aqui que ficam as decisões "fora da política, mas razoáveis". Os líderes conhecem a política de devolução bem o bastante para flexibilizá-la uma vez.
- Faixas de gerente e financeiro. Reembolsos grandes, créditos B2B e qualquer coisa que envolva um contrato. Nomeie uma pessoa por faixa, não um grupo, para que nunca fique parado em "alguém vai cuidar disso".
Mais uma checagem: garanta que seus limites resistam a uma semana movimentada. Se seu líder é o único aprovador de 250 a 1.000 $ e está ausente, todos esses reembolsos travam. Adicione um substituto nomeado para cada faixa, do mesmo jeito que você planejaria o transbordo do suporte.
Onde seu helpdesk pode (e não pode) aplicar a matriz
É aqui que a maioria dos modelos de matriz de reembolsos para, e onde o trabalho de verdade começa. Percorri a documentação de reembolsos e permissões dos helpdesks que mais vejo na fila da eesel. Nenhum documenta um teto em dólares por agente. O que eles oferecem é um interruptor:
| Helpdesk | Reembolso a partir do ticket | Quem pode reembolsar | Teto em dólares por agente | Etapa de aprovação |
|---|---|---|---|---|
| Zendesk | Total ou parcial pelo app da Shopify (todos os planos Suite) | Não é definido por agente na documentação | Não documentado | Solicitações de aprovação a partir do Suite Professional |
| Freshdesk | Total ou parcial pelo widget da Shopify (Growth em diante) | Uma configuração de admin para todos os agentes | Não documentado | O fluxo de aprovação é só para artigos da base de conhecimento |
| Gorgias | Reembolsos e cancelamentos da Shopify por macros e pela barra lateral | Funções Basic, Lead e Admin; Observer e Lite não podem | Não documentado | Nenhuma para pessoas |
| Gladly | Ação de reembolso no cartão do pedido, apenas o valor total | "All Agents can perform all Actions" | Não | Nenhuma para pessoas |
| Kustomer | Valor total, parcial ou manual | Ações da Shopify no conjunto de permissões | Não documentado | A IA passa reembolsos de alto valor para uma pessoa |
| eDesk | Reembolsos por item, sem exceder o original | Permissão de função "Shopify Refunds" | Não documentado | Os procedimentos de IA escalam por padrão |
Alguns detalhes dessa tabela importam mais do que parecem.
A permissão da Shopify não acompanha os reembolsos até o seu helpdesk. A Shopify divide os reembolsos em permissões de equipe separadas para a forma de pagamento original e para o crédito na loja, o que é ótimo. Mas o changelog dela diz que a permissão de reembolso "se aplica no admin da Shopify e no app móvel, mas não em outros apps da Shopify ou de terceiros que permitem aos usuários reembolsar pedidos". Se um agente pode reembolsar pelo Gorgias ou pelo Zendesk, a configuração de funções do próprio helpdesk é o único portão.
O Gladly dá o botão para todos os agentes. A documentação de ações da Shopify diz "All Agents can perform all Actions" e o reembolso no cartão do pedido sempre reembolsa o valor total, incluindo o frete (Gladly). Se você usa o Gladly, sua matriz vive no treinamento e no controle de qualidade, não nas configurações.
O eDesk adiciona um freio útil. Os reembolsos "não podem ser maiores que o valor original", e se o valor for diferente do original, o agente precisa escolher um motivo de discrepância (Discrepancy Reason) (eDesk). Esse campo de motivo é o tipo de trilha de auditoria que eu gostaria de ver em todo lugar.
O Zendesk é o mais próximo de um objeto de aprovação de verdade. No Customer Service Suite Professional e acima, um agente pode criar uma solicitação de aprovação em um ticket, e o próprio exemplo do Zendesk é um reembolso indo para o líder de equipe do agente. Os detalhes são bons para uma matriz de reembolsos: até 5 aprovadores por solicitação, o aprovador não pode ser quem solicita nem o responsável pelo ticket, e uma aprovação pendente impede o ticket de ser fechado (Zendesk). O que ele não faz é escolher o aprovador para você com base no valor. O agente ainda lê a matriz e escolhe.
Na prática, então, o lado do helpdesk da matriz se resume a três configurações: quem tem a permissão de reembolso (veja minhas notas sobre o controle de acesso de agentes de suporte), uma macro ou formulário que obrigue os agentes a registrar o motivo e uma tag de ticket sobre a qual você possa gerar relatórios.
O Zendesk adiciona automaticamente uma tag shopify_refund quando um agente reembolsa pelo app da Shopify (Zendesk), o que facilita a revisão trimestral.
Aplique o limite em dólares na camada de pagamento
Se você precisa de um limite rígido que uma pessoa não consiga ultrapassar com um clique, ele precisa viver onde o dinheiro se move. Veja o que cada ferramenta de pagamento ou comércio realmente consegue aplicar:
| Ferramenta | Quem pode reembolsar | Limite de valor aplicado? | Aprovação embutida | Prazo de reembolso |
|---|---|---|---|---|
| Stripe | Funções como Refund Analyst, Support Associate, Support Specialist | Sim, uma condição de valor em "Refund is created" (prévia pública) | Exigir aprovação ou bloquear; as solicitações expiram em 14 dias | Limite de cartão não informado na documentação de reembolsos |
| PayPal | Até 200 usuários secundários com permissões definidas pelo titular | Não documentado | Não documentado | 180 dias, total ou parcial |
| Admin da Shopify | Permissões separadas para pagamento original e crédito na loja | Não, apenas ligado ou desligado | A equipe aprova ou recusa solicitações de devolução; o POS Pro pode exigir um PIN de gerente | O lojista define 14, 30, 90 ou dias personalizados |
| Loop Returns | Equipe do lojista | Sim, regras por valor da devolução ou do pedido | Ação Manual Review | Definido pelo lojista |
A Stripe é o destaque. As aprovações de duas partes permitem que um admin adicione uma regra em "Refund is created" com uma condição de valor, de modo que a aprovação entra em ação "somente se o valor exceder um limite". O controle é Require approval, que pausa o reembolso até que um revisor o aprove, ou Block. "A user can't approve their own request", as solicitações paradas por 14 dias expiram, e apenas uma regra ativa pode se aplicar a uma determinada ação, então você expressa os níveis por condições combinadas em vez de uma escada de regras. A Stripe também traz regras de aprovação padrão para reembolsos criados por chaves de API marcadas como de agente, o que mostra como as empresas de pagamento pensam sobre IA e dinheiro.
A Shopify é um interruptor, não um botão de ajuste. As permissões da loja listam "Refund to original payment method" e "Refund to store credit" como permissões separadas, sem limite de valor em nenhuma das descrições. Mesmo assim, essa divisão é útil: você pode deixar agentes novos reembolsarem apenas como crédito na loja. Observe também que "you can't cancel or reverse a refund after you initiate a refund" na Shopify (Shopify), então um sim errado é permanente.
Apps de devolução podem cuidar do roteamento por valor. Os fluxos de trabalho da Loop podem rotear por total da devolução, total do pedido, tag do cliente ou motivo da devolução, e enviar uma solicitação para Manual Review. O próprio exemplo da Loop envia devoluções acima de 300 $ para revisão manual, para que o depósito inspecione primeiro os itens de alto valor.
Se as devoluções geram a maior parte dos seus reembolsos, é aqui que o topo da sua matriz deve ficar, e combina bem com as ferramentas de devolução que já comentei. Meu guia de automação de devoluções cobre o restante desse fluxo.
Evite que as aprovações virem o gargalo
Uma matriz de aprovação falha em silêncio quando as aprovações ficam paradas. O cliente não vê seu organograma, ele vê uma espera:
"Tive que consultar meu supervisor para obter a aprovação do reembolso, porque o pedido completo estava um pouco acima do que eu mesmo posso aprovar. Falei que o colocaria em espera por um instante. O supervisor precisou de um minuto, então fiquei esperando."
E quando o limite é definido baixo demais, os aprovadores também se ressentem:
"[...] não deveria ser necessário esperar 15 minutos pela aprovação do gerente da loja para um reembolso de 37 centavos, nem ele deveria precisar lidar com isso, é um desperdício do tempo e do salário dele cuidar de algo tão pequeno."
Isto é o que mantém a matriz rápida:
- Coloque a aprovação onde o aprovador já trabalha. O Zendesk adicionou as aprovações no Slack em maio de 2026, e os aprovadores agora também podem deixar comentários lá. Uma aprovação que vive em uma caixa de entrada que ninguém abre é um reembolso que nunca sai.
- Dê a cada faixa uma meta de tempo de aprovação. O Zendesk não documenta nenhum lembrete nativo para solicitações de aprovação, então configure uma visualização ou automação que sinalize aprovações pendentes após algumas horas.
- Escreva o contexto uma vez. O aprovador deve ver o pedido, o valor, a linha da política que está sendo quebrada e a recomendação do agente. O Zendesk limita a descrição da solicitação a 2.500 caracteres, o que é bastante se você usar um modelo.
- Nunca deixe quem solicita aprovar. O Zendesk bloqueia o responsável de aprovar, a Stripe bloqueia a autoaprovação e o HubSpot faz o mesmo com cotações. Se sua ferramenta não faz isso, transforme em regra.
- Decida o que a expiração significa. A Stripe expira as solicitações após 14 dias. Decida com antecedência se uma aprovação expirada é um não ou sobe um nível, e diga ao cliente qual dos dois foi.
Dê ao seu agente de IA uma linha na matriz
Esta é a parte com a qual a maioria das políticas de reembolso ainda não se atualizou, mesmo em equipes que já usam IA para solicitações de reembolso. Se um agente de IA pode mexer em pedidos, ele precisa de uma faixa própria na matriz, e essa faixa deve ser mais estreita que a de um novo contratado.
O melhor enquadramento que li sobre isso veio de uma discussão sobre o que as pessoas deixam os agentes de IA fazerem sem aprovação:
"a linha que acabei traçando não era o quão arriscada é a ação, era se eu consigo desfazê-la. dinheiro acabou sendo fácil, você reembolsa. [...] um reembolso ruim é uma tarde ruim. uma mensagem ruim fica na caixa de entrada de alguém para sempre e não existe botão de desfazer para isso."
Concordo com o teste da reversibilidade, com uma ressalva: na Shopify e no PayPal, um reembolso enviado não pode ser cancelado. Então, para reembolsos, "desfazer" significa "arcar com o custo", e é exatamente para isso que servem as faixas em dólares. Outro comentarista do Hacker News descreveu a configuração que a maioria das equipes acaba querendo: uma IA que "prepara uma recomendação e uma pessoa passa para aprovar ou negar" (lubujackson, Hacker News).
Toda decisão de reembolso da IA deve terminar em um de três lugares. Esse é o design human-in-the-loop aplicado ao dinheiro, e é a salvaguarda de IA que eu definiria antes de qualquer outra:
Os fornecedores convergiram para esse padrão, com alavancas diferentes:
| Ferramenta de IA | Como os reembolsos rodam | Onde fica a salvaguarda |
|---|---|---|
| Zendesk Copilot auto assist | Cancela e reembolsa pedidos da Shopify depois que um agente aceita | O Zendesk diz que as ações de reembolso "should be marked as agent-approved" |
| Gorgias AI Agent | Reembolsos como parte de cancelar, remover item ou substituir item | Condições de ação sobre o total do pedido; confirmação do cliente ativada por padrão em ações irreversíveis |
| Richpanel | Uma ferramenta Refund Order | "Require approval" por ferramenta; reembolsos limitados pelo total do pedido e pela política |
| Kustomer AI Agent | Reembolsos e devoluções | Acima de um valor definido, uma pessoa aprova e depois a IA conclui a conversa |
| Gladly AI | Reembolsos totais ou parciais | O valor é exibido e confirmado antes com o cliente |
| eDesk AI Agent | Resultado "Approve Refund" nos procedimentos | O resultado padrão é escalar para uma pessoa |
Dois deles merecem uma olhada mais de perto. A documentação de ações do Zendesk alerta que ações pré-aprovadas "may be executed in a different order than specified", que é o motivo documentado para não pré-aprovar reembolsos. E a confirmação do cliente do Gorgias é uma confirmação do comprador, não de um gerente. Ela impede cancelamentos acidentais, mas não é uma aprovação interna. As ações do Gorgias AI Agent também não estão incluídas no plano Starter, segundo a página de preços do Gorgias, e cada interação automatizada custa de US$ 0,85 a US$ 1,00 dependendo do plano. Meu detalhamento dos preços do Gorgias AI Agent tem a tabela completa.
A versão da Kustomer é a que eu copiaria para a devolução ao agente de IA: a pessoa aprova o reembolso, deixa uma nota para a IA, e a IA avisa o cliente e encerra a conversa.
Como eu escreveria a faixa da IA com a eesel
Na eesel, cada ação que o colega de IA pode executar tem uma de três configurações por agente: Auto, Needs approval ou Disabled (documentação da eesel). A conexão com a Shopify inclui Refund Order e Cancel Order como ações de escrita, e nada muda em uma loja até que você crie uma automação e as ative (integração com a Shopify).
A matriz em si vai nas instruções do agente, em linguagem simples. A documentação traz um modelo de escalonamento que inclui "The conversation involves a refund over $100", e um modelo de exceções com linhas como "Damage claims under $50: skip the photo request, approve the refund" (documentação de instruções). Um administrador de suporte com quem trabalhei ensinou ao agente uma regra que fica acima de qualquer faixa em dólares:
"Tenho uma regra no CS em que não tratamos uma solicitação de cancelamento ou reembolso quando há um problema associado a ela."
Um administrador de suporte codificando uma política de "resolva o problema antes de cancelar" no agente
Quando um reembolso precisa de um sim, o aprovador recebe um cartão mostrando a ação exata e o valor, com Approve, Always allow ou Deny. As aprovações nunca rodam sozinhas após um tempo limite, e a página Activity registra quem decidiu e quando.
Se você preferir aprovar pelo Slack, a mesma solicitação aparece no tópico com os botões Approve, Deny e Review, o que mantém a aprovação dentro do dia do aprovador. Mais sobre isso no meu guia de escalonamento com IA.
Erros comuns na matriz de reembolsos
Estes são os que mais vejo na fila, mais ou menos em ordem de quanto custam:
- Uma linha em dólares, sem coluna de risco. Um único limite aprova o reembolso de 20 $ do seu cliente que mais reembolsa e bloqueia o de 300 $ que obviamente é culpa sua. Os dois machucam: um vaza dinheiro, o outro empurra um bom cliente para o churn. Adicione pelo menos as colunas de fora da política e de cliente que reembolsa com frequência.
- Presumir que o helpdesk aplica. A menos que você tenha configurado as aprovações da Stripe ou uma configuração de ação da IA, seus limites são uma política, não um controle. Audite os reembolsos por agente todo mês usando a tag ou o relatório de reembolsos.
- Aprovadores que são grupos. "O canal dos líderes" não é um aprovador. Nomeie uma pessoa e um substituto para cada faixa e registre isso no seu processo de escalonamento.
- Tratar crédito na loja como dinheiro. O crédito na loja mantém o dinheiro no negócio. Dê a ele uma faixa mais folgada e os agentes o oferecerão mais, o que muitas vezes é o que o cliente queria de qualquer forma. Minhas macros de reembolso mostram como redigir essa oferta.
- Nenhum responsável por chargebacks. Um reembolso emitido depois que uma disputa é aberta pode pagar duas vezes e ainda custa a taxa de disputa. Encaminhe os chargebacks a uma pessoa, sempre.
- Nunca revisar as faixas. Se seu líder de equipe aprovou 98% da faixa dele no trimestre passado, a faixa está baixa demais. Trate a matriz como uma política de suporte viva e atualize agentes e a IA no mesmo dia.
Rode sua matriz de reembolsos com a eesel
Se seus reembolsos chegam pelo Zendesk, Freshdesk ou Gorgias com uma loja Shopify por trás, o colega de IA para helpdesk da eesel é a forma mais fácil de tornar a matriz real. Ele entra na sua fila existente, aprende com seus tickets anteriores, sua central de ajuda e suas macros, e executa os reembolsos da sua faixa automática. Tudo acima de um limite que você escreve em linguagem simples espera a aprovação da pessoa certa, no painel ou no Slack, e tudo fora da política vai para sua equipe com uma nota explicando o que ele encontrou.
Antes de tocar em um reembolso real, você pode rodar uma simulação nos seus tickets passados e ver como ele teria tratado suas solicitações de reembolso em comparação com o que sua equipe realmente fez. O preço é por ticket tratado, com assentos ilimitados, então todo aprovador da sua matriz pode ter acesso sem custo extra.
Comece com 100 créditos grátis, conecte sua loja Shopify e seu helpdesk, e defina Refund Order como Needs approval no primeiro dia. Experimente a eesel.