Como escrever um ticket de suporte eficaz

Um ticket de suporte bem escrito fornece à equipe os detalhes necessários para investigar sem fazer suposições. Ele não garante um prazo de resposta nem um resultado, mas deixa a próxima etapa mais clara. Este guia explica o que incluir e oferece modelos para categorias comuns de tickets.

Para saber como enviar um ticket, onde clicar e quais campos preencher, consulte Usar a Central de Suporte. Este artigo trata do conteúdo.

A estrutura essencial de um bom ticket

Todo ticket útil responde a quatro perguntas:

1. O que eu estava tentando fazer: seu objetivo, não apenas o que deu errado.
2. O que realmente aconteceu: o erro, status ou comportamento exato que você observou.
3. O que eu já tentei: isso evita repetir uma verificação básica.
4. Informações de identificação: domínio, caixa de correio, número da fatura ou horários que identificam o caso.

Quanto mais contexto você fornecer, mais fácil será verificar a área correta do produto. Nunca inclua senha, código 2FA ou token de API.

O que incluir por categoria

Tickets de cobrança

• Número da fatura ou referência do pagamento exibido em Billing ou no recibo do pagamento.
• A cobrança esperada e a cobrança efetiva, caso sejam diferentes.
• Se o problema envolve uma renovação, uma ativação de complemento, uma solicitação de reembolso ou outro assunto.
• Últimos 4 dígitos do cartão em problemas específicos do cartão, mas nunca o PAN completo nem o CVV.
• Moeda e valor da contestação.

Exemplo:

Ontem cobraram $52, mas eu esperava $39. O número da fatura da minha página Billing está incluído abaixo. Últimos 4 dígitos do cartão: 4242. Explique se a diferença corresponde a outro item ou a impostos. Anexei uma captura do dashboard que mostra a cobrança.

Tickets técnicos ou de envio

• Endereço da caixa de correio remetente.
• Endereço do destinatário ou padrão, por exemplo, "todos os destinatários @gmail.com".
• Mensagem de erro exata, com o texto completo e todos os códigos de erro, como 550 e 421.
• Quando começou: inclua data, hora e fuso horário sempre que possível.
• Se a mesma caixa consegue enviar para outros endereços: isso mostra se o problema está limitado a um destinatário ou provedor.
• Se o webmail consegue enviar a mesma mensagem: isso ajuda a diferenciar um problema de configuração do aplicativo de email de um problema de conta ou entrega.

Exemplo:

A caixa alice@mycompany.com não consegue enviar para nenhum endereço gmail.com desde esta manhã. Outros destinatários (yahoo.com, outlook.com) funcionam normalmente. A mensagem de devolução é "550 5.7.1 [2026-05-15.05] Our system has detected an unusual rate of sending. Please try again later." O webmail mostra o mesmo erro. O problema começou por volta das ~09:00 UTC em 2026-05-15. Outras caixas do mesmo domínio também não conseguem chegar ao gmail.com.

Tickets de DNS

• Nome do domínio.
• O status que a TrekMail mostra para o domínio e o registro exato que não foi verificado.
• O resultado de uma consulta DNS, se disponível. Por exemplo, a saída de dig para um registro MX ou SPF TXT.
• Seu provedor de DNS, como Cloudflare ou GoDaddy.
• O registro específico que não é verificado.
• Se você alterou o DNS recentemente, incluindo o horário aproximado.

Exemplo:

Domínio: mycompany.com. O registro DKIM ainda está vermelho na página Domains. Adicionei o registro na Cloudflare ontem e configurei como DNS-only, sem proxy. dig +short TXT dkim._domainkey.mycompany.com retorna o valor esperado v=DKIM1; k=rsa; p=.... A TrekMail ainda o marca como ausente. Também verifiquei a propagação em outro serviço de consulta DNS.

Tickets de entregabilidade ou spam

• Domínio e caixa de correio remetentes.
• Taxa de devolução no painel Domain Email Stats.
• Destinatários de exemplo cujas mensagens são devolvidas ou vão para o spam, sem compartilhar a lista completa.
• Origem da sua lista: formulário de opt-in, provedor anterior ou outra fonte.
• Padrão recente de envio: informe se o volume ou o público mudou recentemente.

Exemplo:

A taxa de devolução do domínio mycompany.com subiu de 0.5% para 8% nos últimos sete dias. Anexei uma captura de Email Stats. Envio para uma lista de newsletter com opt-in de cerca de 2,000 assinantes. As devoluções incluem "user unknown" e "mailbox over quota". Removi cerca de 200 assinantes inativos há duas semanas, a única mudança recente. Devo verificar o restante da lista antes de enviar novamente?

Tickets de API

• Nome do token de API, sem colar o token real.
• O endpoint que você está chamando.
• O corpo da solicitação, com todos os dados confidenciais ocultados.
• A resposta, incluindo código de status e corpo.
• Comportamento esperado e comportamento observado.

Exemplo:

Estou chamando POST /api/v1/verify/bulk com um array emails ocultado e mode: quick. Recebo HTTP 422; o corpo da resposta está anexado abaixo, sem os endereços de email. Eu esperava que uma tarefa de verificação fosse criada. Nome do token: "production-verify-token". Isso começou hoje por volta das 13:00 UTC, e a mesma solicitação funcionava ontem.

Tickets de conta ou login

• O email da conta, ou seja, seu endereço de login.
• O que está acontecendo, como não conseguir entrar, não receber a redefinição de senha ou o 2FA não funcionar.
• Navegador e sistema operacional.
• Se você entra por um provedor social, como Google, Microsoft ou um serviço semelhante.
• Data aproximada do último login bem-sucedido.

Em uma solicitação de recuperação de 2FA, descreva o problema de acesso e forneça apenas os dados da conta solicitados pelo fluxo oficial de suporte. Nunca envie senha atual, código 2FA, código de recuperação ou documento de identidade em uma mensagem comum de ticket, a menos que um processo verificado da TrekMail solicite isso explicitamente.

O que NÃO incluir

Não compartilhe:

• Senhas em texto simples. Nunca. Nem a senha do dashboard, nem senhas de caixas de correio, nem senhas de serviços de terceiros.
• Números completos de cartão de crédito, CVVs ou dados bancários completos. Os últimos 4 dígitos são suficientes para identificação.
• Tokens de API em texto simples. Podemos identificá-los pelo nome.
• Endereços ou dados de outros clientes em anexos. Torne-os anônimos ou oculte-os.
• Dados pessoais confidenciais dos destinatários, a menos que sejam essenciais para a investigação.

Se você compartilhar um segredo por engano, revogue-o ou altere-o quando possível e avise o suporte imediatamente para que a equipe possa orientar a próxima etapa.

Orientações para anexos

• Capturas de tela: apenas imagens JPEG, PNG, GIF ou WebP, com no máximo 5 MB. Mostre a página e o erro relevantes, mas corte ou oculte URLs que contenham token, endereço de caixa de correio ou outras informações privadas.
• Saída de consulta DNS: cole como texto, formatado com crases para facilitar a leitura, e não como captura de tela.
• Logs de erro: cole as linhas relevantes, não o log completo.
• Texto de devolução de email: inclua o relatório completo, especialmente a linha Diagnostic-Code:.
• Capturas do navegador: evite mostrar outras abas, notificações, senhas salvas ou dados não relacionados de outros clientes.

Os anexos de imagem dos tickets estão programados para remoção 30 dias após o fechamento do ticket. Guarde uma cópia local de tudo o que for importante.

Um problema por ticket

Se você tiver dois problemas separados, envie dois tickets separados. Isso mantém cada conversa focada e facilita o acompanhamento do histórico.

Se os dois problemas estiverem relacionados, por exemplo, "a cobrança falhou E o envio parou", você pode usar um único ticket, desde que a relação esteja clara.

Atualizar um ticket

Se o problema se resolver antes da resposta do suporte, por exemplo, porque a propagação DNS terminou ou um serviço de terceiros voltou, adicione uma atualização curta como: "Resolvido: a propagação DNS terminou. Fechem este ticket, por favor." Você também pode fechar um ticket ativo por conta própria na página dele.

Se uma solução alternativa parcial for aceitável, mas não for a correção que você queria, diga isso: "Contornei o problema fazendo X, mas ainda gostaria de entender por que a forma original não funcionou."

Modelos que você pode copiar

Para um ticket genérico de algo que não funciona:

Subject: <one-line summary of the issue>

What I was trying to do:
  <your goal>

What happened:
  <exact error or behaviour, including error messages>

Started:
  <timestamp or "always", "since yesterday", etc.>

What I tried:
  - <attempt 1>
  - <attempt 2>

Identifying info:
  - Domain: <domain.com>
  - Mailbox: <user@domain.com>
  - <Invoice number if billing, API token name if API, and similar identifiers>

Para uma solicitação de recurso:

Subject: Feature request: <one-line description>

What I'd like to do:
  <user story: "as a <type of user>, I'd like to <action> so that <benefit>">

Current workaround:
  <if any>

Why this would help:
  <use case, frequency, scale>

Similar in other tools:
  <if any reference example>

Para uma contestação de cobrança:

Subject: Billing dispute: <one-line summary>

Invoice number or payment reference: <from Billing or the payment receipt>
Charge amount: $X.XX
Expected amount: $Y.YY
Account email: alice@mycompany.com

What I was expecting:
  <explanation of what your subscription should have charged>

What was actually charged:
  <explanation of the actual invoice / charge>

Resolution requested:
  <refund / credit / explanation / something else>