Como usar os tickets do Zendesk como prova num chargeback

Quando um subscritor disputa uma cobrança, o seu histórico de suporte é muitas vezes a prova mais forte que tem. Um ticket em que o cliente fez uma pergunta sobre o produto depois da renovação, ou um ticket em que confirmou o seu cancelamento e o reembolsou, pode decidir o caso. Um ticket parafraseado, mal ocultado ou exportado sem datas vale muito menos.

Este guia explica o que torna um ticket do Zendesk útil como prova, como configurar campos e macros para que os factos certos sejam registados no momento, e como tirar os tickets do Zendesk num formato que um revisor da rede de cartões consiga ler. As funcionalidades do Zendesk vêm da própria documentação do Zendesk: imprimir tickets, exportar dados, campos de ticket personalizados, ações de macros, ocultação e as APIs Ticket Audits e Ticket Comments. Os campos de disputa vêm das categorias de disputas e das boas práticas para as provas do Stripe (todos consultados em novembro de 2026).

O que procura um revisor

Uma disputa é decidida por alguém no emissor do cartão que nunca ouviu falar do seu produto e tem poucos minutos para ler o seu processo. Nas disputas de subscrições, as perguntas são normalmente simples:

• O cliente sabia que ia ser cobrado?
• Tentou cancelar e, se sim, quando, e o que aconteceu?
• Continuou a usar o serviço depois da cobrança?

Para a categoria “subscription canceled”, a página de categorias de disputas do Stripe aponta para o campo cancellation_rebuttal (porque é que a subscrição não foi cancelada, ou porque é que a cobrança continua válida) e para customer_communication (correspondência que mostra que o cliente continuou a usar o serviço ou sabia da renovação). As boas práticas do Stripe recomendam juntar várias comunicações, como emails e transcrições de chat, num único ficheiro para esse campo.

Um ticket do Zendesk pode responder às três perguntas, se tiver três coisas.

As três coisas que fazem de um ticket uma prova

1. Timestamps fiáveis

Cada comentário no Zendesk tem a sua própria hora de criação, e o Zendesk mantém um registo de auditoria. A API Ticket Audits descreve as auditorias como um histórico só de leitura de todas as atualizações de um ticket, cada uma com o seu próprio created_at. Isso conta: uma disputa depende muitas vezes de o cliente ter escrito antes ou depois de uma data de renovação.

Quando apresentar um ticket, mostre a data e a hora de cada mensagem e indique o fuso horário. A página de exportação de dados do Zendesk indica que os timestamps em CSV usam o fuso horário por defeito da conta; o seu prestador de faturação pode usar UTC. Ponha ambos na mesma base antes de construir uma cronologia.

2. As palavras do próprio cliente

Cite, não parafraseie. “O cliente confirmou que estava a usar a funcionalidade de relatórios” é a sua opinião. Uma mensagem datada, vinda do email do cliente, a dizer “a exportação nos relatórios voltou a avariar, podem corrigir antes da nossa reunião de direção” é uma prova.

Mantenha estas regras:

• Cite a mensagem completa, ou um excerto claramente assinalado com “[…]” onde cortou.
• Nunca corrija, resuma ou traduza dentro da citação. Se traduzir, ponha o original ao lado.
• Inclua as mensagens que prejudicam o seu caso se forem relevantes. Um revisor que encontre um pedido de cancelamento omitido não vai confiar no resto do processo, e submeter um processo enganador não é algo que deva fazer de qualquer forma.

3. Uma resolução clara

O ticket deve mostrar como terminou: cancelado numa dada data, reembolsado, crédito emitido, pergunta respondida. Se um agente cancelou uma subscrição, o ticket deve dizê-lo numa resposta pública ao cliente, e não apenas numa nota interna.

Configurar o Zendesk para registar isto no momento

As provas são muito mais fáceis de encontrar quando foram etiquetadas no dia em que foram criadas.

Campos personalizados

O guia de campos de ticket personalizados do Zendesk explica que os administradores acrescentam campos no Admin Center em Objects and rules > Tickets > Fields. Cada opção de uma lista pendente recebe a sua própria tag. Campos úteis para as disputas:

Campo	Tipo	Valores
Pedido de faturação	Lista pendente	Pedido de cancelamento, Pedido de reembolso, Pergunta sobre cobrança, Downgrade, Nenhum
Resultado do cancelamento	Lista pendente	Cancelado de imediato, Cancelado no fim do período, O cliente retirou o pedido, Não aplicável
Reembolso emitido	Caixa de verificação	Sim / Não
ID do cliente na faturação	Texto	O ID do seu sistema de faturação

Não crie um campo para números de cartão ou dados de pagamento completos. Nunca precisa deles como prova, e o Zendesk documenta a ocultação automática de números de cartão de crédito (planos Professional e superiores) para quando os clientes os colam na mesma. Segundo o Zendesk, mantém os seis primeiros e os quatro últimos dígitos e não se aplica aos números já existentes no sistema; os mais antigos têm de ser ocultados manualmente, o que é irreversível.

Macros para pedidos de reembolso e de cancelamento

As ações de macros do Zendesk podem definir campos de lista pendente, de escolha múltipla e de caixa de verificação, e definir, acrescentar ou retirar tags. Uma macro “Pedido de cancelamento tratado” poderia:

1. Publicar uma resposta pública a confirmar o cancelamento e a data em que produz efeito.
2. Definir Pedido de faturação como Pedido de cancelamento.
3. Definir Resultado do cancelamento com o valor correspondente.
4. Acrescentar uma tag como cancel_confirmed.

A resposta de confirmação é a parte importante. Transforma “cancelámos” numa mensagem datada na caixa de correio do cliente e no ticket. Mantenha um texto factual: o que foi cancelado, a partir de quando e se se aplica algum reembolso.

A lista de ações de macros do Zendesk cobre os campos que definem tags (lista pendente, escolha múltipla, caixa de verificação), por isso conte que o ID do cliente na faturação venha de uma integração ou seja escrito pelo agente.

Tirar os tickets do Zendesk

Um ticket de cada vez: imprimir

O artigo sobre imprimir tickets do Zendesk descreve como abrir o ticket, clicar no menu Ticket options e escolher Print ticket. Pode escolher se inclui as notas internas e as conversas paralelas (Suite Professional e superiores). Para as provas, deixe de fora as notas internas a menos que contem: são escritas para colegas e podem soar mal fora de contexto. Imprima em PDF e verifique que cada mensagem mostra a sua data.

Muitos tickets: exportação ou API

Método	Inclui comentários?	Notas da documentação do Zendesk
Exportação de dados do Admin Center, JSON	Sim	Desativada por defeito; o titular da conta pede ao Zendesk Support que a ative; os comentários são omitidos nos tickets acima de 1 MB
Exportação de dados do Admin Center, CSV	Não	Só os campos do ticket; sem comentários nem descrições
Exportação de uma vista para CSV	Não	Os campos dos tickets de uma vista
API Ticket Comments	Sim	Pode ser ordenada por created_at
API Ticket Audits	Sim, com cada alteração	Histórico só de leitura de todas as atualizações

Fontes: exportação de dados, exportação de vista, Ticket Comments, Ticket Audits.

As exportações CSV são úteis para encontrar os tickets certos (filtre pelo seu campo Pedido de faturação), mas não como prova por si só, porque deixam de fora o que o cliente escreveu.

Construir o processo de provas, passo a passo

1. Encontre todos os tickets do email do cliente que disputa, e de qualquer outro endereço associado à sua conta.
2. Ordene todas as mensagens por hora e coloque-as numa única cronologia com os eventos de faturação: inscrição, avisos de renovação, cobranças, cancelamento.
3. Escolha as mensagens que respondem às perguntas do revisor. Cite-as na íntegra com data, fuso horário e remetente.
4. Escreva uma nota de apresentação curta em linguagem simples: “O cliente contactou o suporte a [data] sobre [funcionalidade], [N] dias depois da cobrança disputada. Mensagem completa abaixo.”
5. Junte as transcrições num único ficheiro para customer_communication, como o Stripe recomenda.
6. Verifique que nada no processo contém números de cartão ou dados pessoais não relacionados.
7. Submeta antes do prazo indicado na disputa.

Fazer isto com o NoChurn

O conector do Zendesk do NoChurn é só de leitura: lê os tickets e nunca responde, etiqueta ou edita o que quer que seja no Zendesk. Os tickets são associados aos seus clientes pelo email; as correspondências duvidosas são-lhe sugeridas para confirmar e nunca fundidas automaticamente. Quando se abre uma disputa no Stripe ou no Braintree, o NoChurn reúne as provas automaticamente (respostas do fluxo de cancelamento, emails enviados, utilização, e as mensagens do Zendesk associadas, citadas palavra por palavra com as suas datas), redige uma resposta com IA e só a envia depois de a rever. O tratamento dos tickets, as macros e a ocultação ficam no Zendesk, e a decisão sobre a disputa fica com o emissor do cartão. Veja NoChurn + Zendesk.