Como tratar os pedidos de reembolso no Zendesk antes de se tornarem chargebacks

Um chargeback é muitas vezes um pedido de reembolso a que ninguém respondeu a tempo. O cliente escreve ao suporte, espera, recebe uma resposta vaga ou nenhuma, e depois liga ao banco. A partir desse momento, um simples reembolso transforma-se numa disputa com uma taxa, um prazo, uma marca na sua taxa de disputas e um resultado que já não controla.

Este guia mostra como configurar o Zendesk para que os pedidos de reembolso sejam detetados, respondidos depressa e decididos de forma consistente, e como guardar o registo de que vai precisar se mesmo assim houver uma disputa. Baseia-se na documentação do Zendesk sobre a condição Comment text, as macros, a intelligent triage e imprimir tickets, e nas páginas do Stripe How disputes work, boas práticas de prevenção de fraude e boas práticas para as provas das disputas (todos consultados em novembro de 2026). Do lado dos pagamentos, o exemplo é o Stripe; se usar outro processador, verifique as regras dele.

Porque é que a rapidez conta mais do que a decisão

Dois factos da documentação do Stripe explicam porque os pedidos de reembolso merecem prioridade:

• Quando uma disputa está aberta, a porta do reembolso fecha-se. A página How disputes work do Stripe diz que não pode emitir um reembolso fora do processo de disputa enquanto uma disputa estiver aberta. A única forma de a reverter é submeter provas.
• Um reembolso total evita uma disputa; um parcial não. Segundo a mesma página, os clientes não podem disputar pagamentos totalmente reembolsados, mas podem disputar os parcialmente reembolsados.

Assim, a questão não é só “devemos reembolsar?”, mas “conseguimos decidir antes de o cliente ir ao banco?”

Detetar os pedidos de reembolso no Zendesk

Trigger por palavras-chave

Um ticket trigger com a condição Comment text apanha a maioria dos pedidos. A condição olha para o assunto na criação e para o último comentário nas atualizações. Em “Meet ANY of the following conditions”, acrescente uma condição por frase:

• “reembolso”, “devolução do dinheiro”, “cobrado duas vezes”, “cobrança duplicada”
• “não autorizei”, “não autorizado”, “sem autorização”, “não reconheço esta cobrança”
• “disputa”, “chargeback”, “o meu banco”

Ações: acrescentar a tag refund-request, definir a prioridade como High, atribuir ao grupo de faturação.

Dê ao segundo grupo de frases a sua própria tag (charge-not-recognized). Um cliente que não reconhece uma cobrança é o mais propenso a ir diretamente ao banco, e o mais propenso a ser um caso de fraude e não de reembolso.

Intelligent triage

Se tem intelligent triage, a intenção e o sentimento previstos podem encaminhar os tickets de reembolso sem listas de palavras-chave. O guia de casos de uso do Zendesk sugere, por exemplo, aumentar a prioridade dos tickets muito negativos ou enviá-los para um grupo sénior. Usar estas previsões em triggers exige o add-on Copilot; as classificações em si estão disponíveis nos planos Suite e Support Professional e superiores.

Um formulário ou campo de faturação

Um formulário de ticket “Faturação” com um campo “Tipo de pedido” (Reembolso, Cobrança não reconhecida, Pergunta sobre fatura, Cancelamento) dá dados mais limpos do que qualquer palavra-chave. Só funciona para os tickets criados através do seu centro de ajuda ou widget, por isso mantenha o trigger para o email.

Responder depressa

Defina para os tickets refund-request e charge-not-recognized um objetivo de tempo de primeira resposta mais curto do que o normal, e mantenha uma vista desses tickets ordenada por antiguidade para que nada fique à espera sem ser visto. A resposta não precisa de conter a decisão. Precisa de dizer ao cliente que uma pessoa está a tratar do assunto e quando terá notícias.

Uma macro de primeira resposta:

Olá {{ticket.requester.first_name}}, obrigado pelo seu contacto sobre esta cobrança. Estou a analisá-la agora e responderei até [hora] com uma resposta. Não precisa de contactar o seu banco; vamos resolver isto diretamente.

Só escreva a última frase se estiver a falar a sério e for cumpri-la.

Decidir de forma consistente

Escreva uma política de reembolso que os seus agentes possam aplicar sem escalar todos os tickets. Uma tabela de decisão simples:

Situação	Decisão típica
Cobrado depois de um cancelamento que o cliente pediu de facto	Reembolso total, confirmar o cancelamento
Renovação anual cobrada, o cliente não usou depois da renovação	Reembolso total ou proporcional, segundo a sua política publicada
Cobrança duplicada	Reembolsar o duplicado
O cliente não reconhece a cobrança, nenhuma conta corresponde	Escalar como possível fraude
O cliente usou o serviço e quer o dinheiro de volta	Segundo a sua política; explique-a claramente se recusar

Dois pontos do Stripe a ter em conta:

• Os reembolsos parciais podem ainda ser disputados. Se oferecer um reembolso parcial, explique-o, e saiba que o cliente pode ainda disputar o resto.
• Early fraud warnings. Se o Stripe sinalizar um pagamento com um early fraud warning, as suas orientações de prevenção de fraude dizem que pode reembolsar proativamente para evitar que o titular do cartão dispute, mas que reembolsar automaticamente todos os avisos não é uma boa estratégia. Um reembolso também não retira um relatório de fraude das contagens das redes de cartões.

Escrever a decisão

Quando reembolsa:

Reembolsei [montante] para o seu cartão terminado em [last4]. Pode levar alguns dias úteis a aparecer, consoante o seu banco. A sua subscrição está [cancelada / ainda ativa até data]. Diga-me se mais alguma coisa lhe parecer errada.

Quando recusa:

Analisei a sua conta. A sua subscrição foi renovada a [data] nos termos que aceitou na inscrição, que pode ler aqui: [política]. Desde então, a conta foi usada em [datas]. Não posso reembolsar esta cobrança, mas cancelei a renovação para que não volte a ser cobrado. Se tiver perguntas, responda aqui e eu ajudo.

Uma recusa escrita assim é também uma boa prova: é factual, datada e educada, e mostra que foi oferecida uma solução ao cliente.

Guardar o registo

Se mesmo assim chegar uma disputa, o ticket faz parte da sua resposta. As boas práticas para as provas do Stripe pedem-lhe que indique se o cliente tentou resolver o problema consigo antes de disputar, e que inclua as comunicações relevantes como excertos num único ficheiro.

A partir do Zendesk:

• Um ticket: use Print ticket no menu de opções do ticket e guarde como PDF a partir do navegador. Pode escolher se inclui as notas internas; para as provas, deixe-as de fora. Não existe impressão em massa.
• Muitos tickets ou automatização: o Zendesk aponta para as APIs Ticket Comments e Ticket Audits, que devolvem cada comentário com o seu autor e timestamp.

Mantenha as palavras do próprio cliente tal como estão, com as datas. Não as edite.

Medir

Acompanhe três números todos os meses: pedidos de reembolso recebidos, tempo mediano até à primeira resposta nesses pedidos, e disputas de clientes que tinham um ticket de reembolso aberto ou recente. Se este último número não for zero, analise esses tickets um a um. Normalmente mostram uma resposta que chegou tarde demais ou uma decisão que nunca foi explicada.

Fazer isto com o NoChurn

O conector do Zendesk do NoChurn é só de leitura, por isso os reembolsos, as respostas e os triggers ficam com a sua equipa no Zendesk e no Stripe. O NoChurn lê os tickets e associa-os aos clientes pelo email (as correspondências duvidosas são sugeridas, nunca fundidas automaticamente), e usa-os no score de churn. Quando se abre uma disputa no Stripe ou no Braintree, reúne as provas automaticamente, incluindo excertos datados e palavra por palavra dos tickets do Zendesk, respostas do fluxo de cancelamento, emails enviados e utilização, e redige uma resposta com IA que só é enviada depois de alguém da sua equipa a rever. Veja NoChurn + Zendesk.