Modelos de resposta para tickets de suporte que não soam a copiar e colar

Escolhe um cenário, usa o modelo

Oito dos tickets que vejo mais frequentemente, com a resposta que eu realmente enviaria. Substitui as partes entre parênteses retos, e também a sintaxe de placeholders, pelo que o teu helpdesk usar. A tabela mais abaixo tem a grafia exata para cada um.

Porque é que a maioria dos modelos de resposta para tickets de suporte soa a copiar e colar

Aqui está algo que eu questionaria: as equipas reescrevem o texto quando o problema é a forma.

Lê um modelo que os clientes odeiam e vais quase sempre encontrar a mesma estrutura por baixo. Começa com um agradecimento. Depois repete a política, pede desculpa na voz passiva, e termina a pedir ao cliente que entre em contacto se tiver mais dúvidas. Quatro frases, e nenhuma delas menciona aquilo sobre o que ele escreveu. Alguém que esperou nove horas por uma resposta lê isso e conclui, corretamente, que ninguém leu a sua mensagem.

Os modelos que ninguém repara são os que começam pelo específico. "A tua encomenda saiu do armazém na terça-feira e está parada em Milão" soa humano mesmo que cada palavra depois disso tenha sido pré-escrita.

A versão mais afiada desta regra que já li veio de um tópico do Hacker News, e tem mais de uma década.

"I've worked in customer service, and the reps use 'canned text' all the time for common issues. I assumed this was common knowledge. Not doing so would be a recipe for RSI within a couple weeks.

The problem with canned text is when it's reused on the same person, which leads to anger on the part of the recepient (or suspicions that they're being serviced by a robot)."

mullingitover, Hacker News

A falha está na repetição para a mesma pessoa, não no uso de modelos em si. O que significa que a proteção que precisas não é de todo um tom mais caloroso. É uma regra: nunca disparar a mesma macro duas vezes no mesmo tópico.

Os próprios dados de teste da eesel dão um número real a isto. Na implementação de uma equipa alemã de ecommerce, os agentes enviaram os rascunhos de IA tal como estavam apenas 12% das vezes, e o padrão dominante foi "olhar por alto e reescrever": transformavam rascunhos de 8 a 15 frases em respostas de 1 a 3 frases. Cerca de 65% dessas reescritas foram por causa do comprimento e do tom. Apenas cerca de 5% foram porque o rascunho estava factualmente errado. E é exatamente a mesma queixa que os agentes fazem sobre as respostas predefinidas. O modelo está correto e mesmo assim tem o comprimento errado, o tom errado para o ticket que têm à frente.

Portanto, aqui está a estrutura de cinco partes a que eu sujeitaria todos os modelos:

1. Nomeia o problema exato na primeira frase, usando as palavras deles e o número da encomenda.
2. Diz o que já fizeste. No passado, de forma específica. "Verifiquei com o armazém" ganha a "estamos a analisar isto".
3. O que acontece a seguir, e quando. Uma data. Não "em breve", não "assim que possível".
4. O que precisas deles, ou explicitamente que não precisas de nada.
5. Uma saída para um humano, para que a resposta não pareça um muro.

Retira o ponto 3 e a resposta soa a desprezo. Retira o ponto 5 e soa a bot. Tudo o resto é estilo. Há mais catorze exemplos trabalhados no artigo de modelos de email de atendimento ao cliente se quiseres a mesma estrutura aplicada especificamente ao email.

Para quem deixa a IA escrever o primeiro rascunho, essa descoberta sobre o comprimento tem uma consequência prática. Um melhor prompt não vai resolver isso. Alimentá-la com as respostas realmente enviadas pela tua equipa, sim, porque é assim que ela aprende quanto tempo a tua equipa realmente escreve. O que é todo o argumento a favor de manter a voz da marca a partir de exemplos reais em vez de um controlo de tom.

Onde vivem os modelos em cada helpdesk

Todos os helpdesks têm esta funcionalidade. E cada um chama-lhe algo diferente também, o que é o seu próprio pequeno imposto quando estás a migrar. Aqui está a mesma funcionalidade em seis ferramentas, com o que realmente muda.

Se só precisares do passo a passo para uma ferramenta, há guias separados sobre criar uma macro no Zendesk. O guia de macros do Gorgias cobre o lado do ecommerce, e respostas predefinidas do Freshdesk tem o equivalente do Freshdesk.

Três coisas dessa tabela vale a pena destacar.

As macros do Zendesk não conseguem ser automatizadas de todo. As pessoas que estão a migrar ficam sempre surpreendidas com isto. O Zendesk é explícito ao dizer que as macros «só contêm ações, não condições», porque nada está a avaliar tickets em teu nome, é um agente que o faz. Não existe nenhuma ação de trigger que dispare uma macro, e o pedido da comunidade para isso continua em aberto. A solução alternativa documentada funciona ao contrário: a tua macro adiciona uma tag, depois a tag dispara um trigger. Queres primeiras respostas automáticas? Isso é trabalho para as regras de resposta automática do Zendesk ou um agente de IA, não para a biblioteca de macros.

O Freshdesk obriga-te a escrever o texto duas vezes. As respostas predefinidas não podem ser associadas a uma regra de automação. O editor de automação dá-te em vez disso um corpo de texto livre "enviar email ao requerente", por isso o teu texto de confirmação vive em dois sítios e editar a resposta predefinida nunca atualiza a regra. Vale a pena saber antes de construires um respondedor automático do Freshdesk por cima da tua biblioteca.

Só o Help Scout e o Front te dão um valor alternativo. A sintaxe do Help Scout é {%customer.firstName,fallback=there%}, e a do Front é {{recipient.first_name | 'there'}}. No Zendesk, Freshdesk e Gorgias um campo vazio simplesmente aparece em branco, por isso "Olá," chega a quem se registou sem nome próprio. Isso é uma coisa real que acontece em filas reais todos os dias.

As armadilhas dos placeholders

Já enviei um partido. Tal como toda a gente que trabalhou numa fila há mais de um mês, mais ou menos. Abaixo estão os que mordem mais forte, todos documentados pelos próprios fornecedores, e a maioria volta a aparecer no resumo de problemas de macros do Zendesk.

Os tickets Problem vazam o nome errado no Zendesk. Se respondes a um ticket Problem com uma macro que contém {{ticket.requester.name}}, o Zendesk envia o nome desse requerente para todos os tickets de incidente associados, além do dele próprio. A solução é uma barra invertida: Hello \{{ticket.requester.first_name}}. Essa é a solução alternativa documentada pelo Zendesk, e não é algo que adivinharias sozinho.

Aplicar uma macro em massa parte a linha de assunto. O Zendesk permite aplicar uma macro a até 100 tickets de uma vez a partir de uma vista, mas os placeholders no assunto ficam guardados como o texto literal entre parênteses retos, segundo a documentação de atualização em massa. O teu cliente recebe um email com o título {{ticket.created_at}}. Os anexos também são silenciosamente descartados em massa, e qualquer ação de CC na macro simplesmente não acontece.

Os modelos disparados por regra assinam com a pessoa errada. O Gorgias resolve todas as variáveis current_user para o dono da conta quando é uma regra, e não um agente, que aplica a macro, por isso a tua resposta automática fica assinada pelo teu CEO. O Front tem o mesmo problema com o sintoma inverso: em respostas enviadas por regra, as variáveis {{user...}} voltam vazias.

Migrar do Help Scout para o HubSpot significa reescrever todos os modelos. O HubSpot proíbe explicitamente as chavetas em snippets e modelos porque quebram o seu serviço de renderização, por isso cada {%customer.firstName%} tem de ser substituído manualmente através do seletor Personalize. Reserva uma tarde para isso.

E o que mais dói, porque é nosso. Enviámos um rascunho em alemão a um cliente com um {{ticket.requester.first_name}} em bruto no meio do texto, e um em neerlandês com um [Employee Name] por preencher. Corrigimos, mas é exatamente por isso que agora trato "isto renderiza bem num ticket com campos em falta?" como uma verificação obrigatória antes de um modelo ser partilhado, não como algo simplesmente agradável de ter.

A tua biblioteca de modelos vai apodrecer, prepara-te para isso

Aqui está o padrão que ouço vezes sem conta em chamadas com clientes. No primeiro mês, escreves 20 macros e todos adoram. Ao sexto mês há 80, porque cada agente acrescentou as suas. Segundo ano: 300, seis das quais contêm um custo de envio que mudou em 2025, e mesmo assim ninguém consegue encontrar a boa na caixa de pesquisa.

Isto não é hipotético. Um responsável de operações de uma marca DTC de suplementos que gere cerca de 7.000 tickets por mês contou-nos que o conhecimento deles vivia espalhado por documentos SOP, vídeos tutoriais não transcritos, e «muitas macros desatualizadas». O que tinham não era realmente um ativo. Era dívida de manutenção com uma caixa de pesquisa em cima.

Os agentes descrevem a mesma coisa por dentro, e são mais engraçados quanto a isso.

"lol i'm helping the supes clean up a 6 year old macro library that has sunset nothing. some of the most used ones get an update when the policies or products change but typically we just write a whole new one and leave the old one to rot 🥲"

u/mensfrightsactivists, Reddit

Esse é o mecanismo real. Ninguém edita, todos duplicam.

Os limites são generosos o suficiente para que nada te trave. O Zendesk permite 5.000 macros partilhadas por conta, e o Gorgias tem o mesmo limite de 5.000. Nenhum dos dois números é uma meta.

O que eu faria realmente, trimestralmente:

• Ordenar por utilização e eliminar os zeros. Tudo o que não foi usado em 90 dias sai. No Zendesk isto precisa de Suite Growth ou Support Professional para sequer ordenar por utilização, algo que vale a pena saber antes de prometeres um relatório ao teu responsável.
• Atribuir um responsável a cada modelo que mencione um número. Preços, prazos de reembolso, tempos de SLA, estimativas de entrega. Esses são os que ficam errados em silêncio.
• Usar a convenção de nomenclatura como se fossem pastas. O Zendesk aninha através de dois pontos duplos no título, como Refunds::Declined::Outside window, e é o único aninhamento que existe. Há mais sobre organizar categorias de macros se a tua lista já tiver crescido demasiado. O Help Scout não tem qualquer ordenação manual, por isso as respostas aparecem alfanumericamente e uma convenção de nomenclatura é a tua única alavanca.
• Decidir o que fica pessoal. O Zendesk é o único que permite que agentes individuais mantenham macros privadas, o que é ótimo para atalhos pessoais e terrível para texto de política que devia ser partilhado. O guia sobre macros pessoais vs. partilhadas cobre onde traçar essa linha.
• Exportar antes de eliminar. O Gorgias exporta para um CSV de quatro colunas (name, body_text, tags, id) e voltar a importar com um id correspondente atualiza no mesmo sítio, o que torna agradável a edição em massa numa folha de cálculo. O Zendesk também tem um caminho de exportação, com a mecânica no guia de exportação e importação de macros.

A auditoria é aborrecida. Também é o jogo todo. Uma biblioteca de 40 modelos todos corretos ganha a 300 dos quais seis estão a mentir.

A melhor descrição de uma rotina funcional que já vi veio de um administrador do Zendesk a descrever o seu ciclo semanal.

"Yes. We run our email macros by our QA so we know we're doing best response (oh, we feed it in ChatGPT that's pre-configured with our support bible) and update everyone on Slack that it's good to go and everyone uses it, it saves so much time! We also create macros to auto-tag tickets and complete tagging of forms. In our weekly meetings we calibrate on correct tagging, macros to add, edit, archive."

u/fast8048, Reddit

Revisão de QA, depois um anúncio no Slack, depois uma calibração semanal onde as coisas são adicionadas, editadas e arquivadas. Outro administrador no mesmo tópico apontou um orçamento real para isto: cerca de uma hora por mês. Esse é o preço de uma biblioteca que não mente.

Quando parar de escrever modelos

Os modelos são a ferramenta certa numa faixa mais estreita do que a maioria das equipas assume. Duas variáveis decidem isso: quanto volume tem um tipo de ticket, e quanto os tickets variam dentro dele.

Volume alto e todos os tickets basicamente iguais, estado da encomenda, reposições de palavra-passe, "enviam para X", é o quadrante onde um humano a copiar um modelo quarenta vezes por dia é uma chamada de API cara. Um sistema de tickets com IA ganha o seu lugar aí, e os resultados aparecem como uma taxa de desvio em movimento em vez de uma sensação.

Volume alto mas variado, digamos uma disputa de faturação, é onde queres o modelo como esqueleto com um humano a escrever o meio. Esse é o trabalho que as macros de IA fazem. Volume baixo? Basta escrever.

As três categorias de ecommerce que vale a pena automatizar primeiro são quase sempre reembolsos, trocas e envios, já escritas como modelos de macros de IA se quiseres um ponto de partida em vez de uma página em branco. Encaminhá-los corretamente importa tanto como respondê-los, por isso combina isto com triagem de tickets que corre antes de a resposta ser redigida.

Um agente no r/Zendesk enquadrou o meio-termo melhor do que eu teria feito.

"Pretty accurate tbh. Macros work best as a 70% draft, not a final reply. Once they get stale, agents absolutely start retyping, and yeah, 20 to 40 "same-ish" responses a day isn't weird at all. What makes them stick is good naming, folders by scenario, placeholders, and letting agents edit/own them instead of using stuff leadership wrote years ago."

u/palestagnation, Reddit

Um modelo é um rascunho a 70%, e os últimos 30% são a parte que o cliente realmente lê. Verdade quer os primeiros 70% venham de uma macro quer venham de uma IA. Também funciona ao contrário, como outro agente no mesmo tópico assinalou: a redação com IA não substitui a biblioteca, alimenta-se dela. Por isso uma biblioteca de macros a apodrecer envenena silenciosamente também o resultado da IA.

A parte boa é que a transição não desperdiça o trabalho que já fizeste. As macros são uma fonte de conhecimento de primeira linha, não algo para deitar fora. Uma empresa alemã de eventos com quem trabalhamos funciona com 580 documentos compostos pelo seu centro de ajuda, pelas suas macros e por tickets passados, e o seu bot geriu tickets reais em alemão em piloto automático completo em reembolsos, vales e pedidos de anfitriões.

Essa é a reformulação com que te deixo. A biblioteca que já manténs é dados de treino, e o número de nove macros para 56 resoluções de há pouco é como isso se parece à pequena escala.

Experimenta a eesel

Se usas Zendesk, Freshdesk, Gorgias, Front ou Help Scout e a tua biblioteca de macros está a fazer mais trabalho do que os teus agentes, isto é o que especificamente a eesel faz: lê as macros, tickets passados e centro de ajuda que já tens, e depois redige a resposta dentro do helpdesk que já usas. Sem novo separador, sem reescrever os teus modelos para o formato de outra pessoa.

Há duas coisas que destacaria especificamente. Primeiro, o fluxo de trabalho é uma nota interna. Um agente escreve @eesel draft a reply num ticket e recebe um rascunho completo de volta para rever, o mesmo gesto automático que ir buscar uma macro. Segundo, antes de qualquer coisa disto chegar a um cliente, podes correr uma simulação sobre cerca de 100 dos teus tickets antigos, comparar o que a IA teria dito com o que os teus humanos realmente enviaram, e ler o relatório de diferença. Construímos isso porque já vimos bots com ar confiante a dar respostas erradas, e descobrir isso em tickets históricos é melhor do que descobrir numa fila ao vivo.

"It is getting us to the right articles really quickly and easily, as well as curating well-formed responses with consistent, on-brand tone, still keeping our own style and still keeping that human touch."

Eddie Stephens, Service Desk Lead, CartonCloud

É grátis para experimentar, e a configuração mede-se em minutos em vez de um projeto de implementação.

A integração com o Zendesk é aquela onde a maioria das equipas com muitas macros aterra primeiro. Também há uma nativa do Freshdesk, e Gorgias para filas de ecommerce. Se os teus melhores modelos já estiverem escritos, a maior parte do trabalho está feita.