O que é um guia de tom para atendimento ao cliente?
Um guia de tom para atendimento ao cliente é a fatia do guia de estilo da marca que cabe ao time de suporte. Ele responde a uma pergunta para cada resposta: dado quem é esse cliente e o que acabou de acontecer, como isso deve soar?
A distinção útil vem do guia de estilo de conteúdo do Mailchimp, que muitas equipes de redação tomam como base. A voz é sua personalidade e quase não muda. O tom é como essa personalidade se adapta à pessoa à sua frente. A analogia do Mailchimp: você fala diferente num jantar com amigos e numa reunião com seu chefe, e nunca usaria o mesmo tom com alguém assustado ou chateado e com alguém rindo.
O suporte precisa da sua própria versão porque escreve nos piores momentos. O marketing pode se animar com lançamentos. O suporte precisa dizer não a reembolsos, explicar quedas e responder a um cliente que está na terceira mensagem sobre o mesmo pedido com defeito. Trabalho na fila de suporte da eesel todos os dias, e as respostas que dão errado raramente têm os fatos errados. São os fatos certos no tom errado: um "Sem problemas!" descontraído num erro de cobrança, ou um pedido de desculpas rígido de três parágrafos por um erro de digitação numa fatura.
Um bom guia de tom é curto, geralmente de duas a quatro páginas, e tem cinco partes:
| Parte | O que cobre | Linha de exemplo |
|---|---|---|
| Traços de voz | 3 a 4 traços fixos de personalidade, cada um com um "não" | "Direto, não ríspido" |
| Tom por situação | Ajustes dos controles para cada tipo de ticket comum | "Reembolso negado: sério, respeitoso, objetivo" |
| Mecânica | Contrações, pontos de exclamação, emoji, saudações, despedidas | "No máximo um ponto de exclamação, nunca em más notícias" |
| Frases para cortar | Frases de script que soam falsas | "Cortar 'Entendo sua frustração'" |
| Regras de idioma | "Você" formal ou informal por idioma | "Alemão: sempre Sie" |
Se você já tem um glossário de tradução para suporte, a linha de regras de idioma pode apontar para ele em vez de repeti-lo.
Por que o tom dá errado no suporte?
A maioria dos problemas de tom vem de dois lugares: scripts e escala. Scripts fazem a empatia soar obrigatória em vez de sentida. Escala significa que 20 agentes, 200 macros e agora um agente de IA escrevem em seu nome, cada um se desviando um pouco.
Os clientes notam o script primeiro, e é por isso que a empatia no atendimento ao cliente é sobre ser específico, não sobre frases prontas. No Hacker News, um comentarista descreveu atendentes lendo frases de empatia de um cartão:
"It reminds me of the new customer support script where they make them use empathetic words. " Awesome, let me help" and " Thats frustrating" sound worse coming from humans that don't care."
Os agentes sentem isso do outro lado. Quando um agente de call center reclamou que os líderes de equipe o avaliam por "palavras floridas", outro agente explicou o que a empatia realmente é:
"It really isnt flowery words, theres no apology or saying sorry. Unless you personally caused it. It's just an acknowledgement followed by a resolution."
Essa segunda citação é quase um guia de tom completo em uma linha. Ela também bate com a pesquisa. No estudo da NN/g com 100 adultos, uma seguradora de carros brincalhona foi avaliada como mais simpática do que uma séria, mas 0,3 ponto menos confiável, sem aumento na disposição de recomendar. Um banco informal, mas sério, superou um banco formal em simpatia (+0,7), confiança (+0,3) e recomendação (+0,4). Informal tudo bem. Leviano não.
A terceira falha é mais recente: tom amigável sem nada por trás. Um cliente que recebe uma resposta calorosa e conversadora que não resolve nada acaba mais irritado, não menos. Um comentarista do HN resumiu:
"I don't immediately hate talking to an chatbot, my dislike comes from chatbots that sound like humans but can't actually do anything useful."
Portanto, o trabalho de um guia de tom não é fazer as respostas soarem mais simpáticas. É fazê-las soar como se alguém competente estivesse cuidando do caso.
Os quatro controles de tom que todo guia de suporte precisa
"Seja amigável, mas profissional" é a linha mais comum nos guias de tom e é inútil, porque ninguém sabe onde fica o limite. As quatro dimensões de tom da NN/g resolvem isso transformando o tom em quatro controles separados:
- Formal a informal. "Pedimos desculpas pelo inconveniente" vs. "Desculpa por isso."
- Sério a engraçado. Se você tenta usar humor ou não.
- Respeitoso a irreverente. A irreverência geralmente é dirigida ao assunto, nunca ao cliente.
- Objetivo a entusiasmado. "Seu reembolso foi emitido" vs. "Boas notícias, seu reembolso está a caminho!"
O próprio exemplo da NN/g move uma mensagem de erro ao longo dos controles: "We apologize, but we are experiencing a problem" fica mais informal com "we're" e "sorry", depois mais entusiasmada com um "Oops!" na frente. Os mesmos fatos, quatro empresas diferentes.
O truque é definir os controles por situação, não uma vez para a marca toda. Sua voz decide até onde cada controle pode ir. Um app de consumo brincalhão pode deixar as mensagens de agradecimento irem até o engraçado; uma empresa de folha de pagamento pode limitar em "caloroso". Em ambos os casos, uma recusa de reembolso deve ficar perto de sério e objetivo, porque é nesse momento que o cliente decide se confia em você.
A NN/g também recomenda combinar suas palavras de tom com palavras de "antitom", como "com autoridade, não pedante". Esse hábito sozinho elimina a maioria das discussões nas revisões de QA, porque nomeia a falha dos dois lados.
Tom por situação: escolha um tipo de ticket
Esta é a seção do guia que os agentes realmente abrem no meio de um ticket. Escolha uma situação para ver onde eu colocaria cada controle e como isso fica numa resposta real.
Regra: diga não na primeira frase, explique o motivo em palavras simples e depois ofereça a próxima melhor opção. Sem pontos de exclamação.
Regra: o que está quebrado, de quem é a culpa, o que acontece a seguir e quando o cliente terá notícias. Nunca "não se preocupe".
Regra: reconheça em uma frase o que deu errado de específico e depois mostre a solução. Nomeie o problema; não narre os sentimentos do cliente.
Regra: primeiro a resposta, depois os passos, e por último o empecilho mais provável. Sem preâmbulo.
Regra: é aqui que um "desculpa" simples merece seu lugar. Assuma a culpa uma vez e depois dê a correção exata.
Regra: o único lugar em que sua voz tem mais liberdade. Um pouco de humor é bem-vindo se sua marca permitir.
Repare que a coluna "Cortar" quase sempre é mais formal, mais longa e mais vaga. Essa é a falha de tom mais comum no suporte: se esconder atrás de linguagem formal quando a notícia é ruim. As próprias diretrizes de voz da Shopify dizem o mesmo para textos de produto: seja franco e honesto mesmo quando você errou, e peça desculpas quando a culpa for sua, "within reason".
Para o contato repetido e irritado, meu guia sobre como lidar com clientes irritados vai mais a fundo, e estas frases de empatia são um bom banco de falas que não soam como script.
Frases para manter, frases para cortar
Seu guia de tom precisa de uma seção de mecânica, porque é onde os agentes mais discordam. Os grandes guias de estilo também não concordam entre si, o que vale saber antes de escolher um lado:
| Regra | O que dizem os guias de estilo | O que eu colocaria num guia de suporte |
|---|---|---|
| Contrações | Mailchimp e Shopify incentivam. GOV.UK proíbe "can't" e "don't" porque os leitores as interpretam mal | Use. Escreva "cannot" só em recusas por política em que um mal-entendido causaria dano |
| Pontos de exclamação | Mailchimp: nunca em mensagens de falha. Shopify: no máximo um por página | Um por resposta, no máximo. Zero em más notícias |
| "Sorry" | Atlassian diz para omitir, a menos que o problema seja grave. Shopify diz para pedir desculpas quando a culpa é sua | Diga uma vez, quando for culpa sua. Nunca por reflexo. Veja estes exemplos de pedido de desculpas |
| "Please" | Atlassian diz que pode fazer uma etapa obrigatória parecer opcional. GOV.UK diz que geralmente é desnecessário | Tudo bem em pedidos; corte "please note" e "please be advised" |
| Culpa | Atlassian usa "nós" em vez de "você" para que ninguém se sinta culpado | "Não conseguimos processar o pagamento", não "Seu pagamento falhou" |
| Emoji | Mailchimp permite com pouca frequência | Espelhe o cliente. Nunca em más notícias |
E as frases de script para cortar, com o que dizer no lugar:
- "Entendo sua frustração." Nomeie o problema real: "Você foi cobrado duas vezes."
- "Pedimos desculpas por qualquer inconveniente." Pede desculpas por nada específico. Diga o que deu errado.
- "Não se preocupe." As diretrizes da Shopify alertam contra pedir confiança sem dados. Dê os dados.
- "Conforme nossa política." Explique em uma frase por que a política existe.
- "Obrigado pela paciência" no início de uma resposta demorada. Reconheça a espera sem rodeios: "Desculpa por isso ter levado dois dias."
Os próprios exemplos de instruções de IA do Freshdesk tomam a mesma decisão: reconhecer a frustração em uma frase e dispensar enrolação como "I apologize for any inconvenience" (guia do agente de IA do Freshdesk). Quando um fornecedor de helpdesk escreve isso na própria documentação, você sabe que a era do script acabou.
Como escrever um guia de tom para atendimento ao cliente em 7 passos
Dá para ter uma primeira versão funcional numa tarde. Esta é a ordem que eu seguiria.
- Separe 30 respostas reais. Pegue 15 que tiveram ótimo CSAT e 15 que deram errado (uma reabertura, uma escalação, uma nota 1 estrela). Problemas de tom são muito mais fáceis de ver nos seus próprios tickets do que na teoria.
- Escreva 3 a 4 traços de voz, cada um com um "não". "Direto, não ríspido. Caloroso, não exagerado. Confiante, não arrogante." Use o truque do antitom da NN/g para que os revisores apontem a linha que foi ultrapassada.
- Defina os quatro controles para seus 6 a 8 principais tipos de ticket. Use o widget acima como ponto de partida. A maioria das equipes precisa de reembolso ou cancelamento, queda, erro, contato repetido e irritado, dúvida de como fazer, cobrança e elogio.
- Escreva a mecânica. Contrações, pontos de exclamação, emoji, saudação e despedida, e o "você" formal ou informal para cada idioma que você atende (mais sobre isso no meu guia de suporte multilíngue). O Zendesk, por exemplo, tem uma configuração de pronome por idioma exatamente para isso, definida como formal por padrão.
- Reescreva suas 10 principais macros. Suas macros são onde o tom antigo vive por mais tempo. Se uma macro reprova no guia, todo mundo que a usa reprova no guia. Meus posts sobre modelos de e-mail e scripts de chat ao vivo têm exemplos reescritos para começar.
- Carregue em todas as ferramentas. Central de ajuda, macros, onboarding de agentes, as configurações do agente de IA e sua ficha de QA. Mais sobre isso abaixo.
- Avalie e revise a cada trimestre. Adicione um critério de tom ao QA e atualize o guia quando a mesma correção aparecer três vezes.
O passo 6 é o que decide se o guia será usado. Um PDF numa pasta compartilhada não muda nada. Coloque-o nos seus SOPs de suporte e no seu onboarding de agentes, e faça dele a primeira coisa nos seus cenários de treinamento.
Onde seu guia de tom precisa morar no helpdesk?
Todo grande helpdesk já tem alguma forma de mudar o tom, mas eles dividem isso em duas coisas diferentes: um botão que reescreve a resposta de um único agente e uma configuração que controla como o agente de IA escreve. Cada um recebe seu guia em formatos bem diferentes.
| Helpdesk | Botão "mudar tom" do agente | Configuração de tom do agente de IA | Limites que vale conhecer | Requisito | Fonte |
|---|---|---|---|---|---|
| Zendesk | Enhance writing: Make more friendly, Make more formal, Rewrite in your tone | Professional, Informal, Enthusiastic ou Custom, mais formalidade do pronome por idioma | Plano gratuito: 5 usos por agente ao mês, limitado a 500 por conta | Complemento Copilot $50/agent/month para uso ilimitado | Documentação do Zendesk |
| Freshdesk | Writing Assistant: More formal, Less formal, Rephrase | Instruções personalizadas em texto livre, sem seletor de predefinições | O tom segue o idioma do perfil do agente | Freddy AI Copilot $29/agent/month nos planos Pro e Enterprise | Documentação do Freshdesk |
| Gorgias | Nenhum botão nativo encontrado | Friendly, Professional, Sophisticated ou Custom | Custom até 3.000 caracteres; saudação, despedida e termos até 600 cada | Voz da marca listada a partir do Basic | Documentação da Gorgias |
| Help Scout | AI Assist: Make it friendlier, Make it more professional | Campo Identity em texto livre | AI Drafts aprende o tom com respostas anteriores | AI Assist nos planos Plus e Pro | Documentação do Help Scout |
| HubSpot | Change tone: Friendly, Heartfelt, Professional | Friendly, Professional, Casual, Empathetic, Witty ou voz da marca | IA da caixa de entrada: 30 usos por minuto, 1.000 por dia | Customer agent nos planos Pro e Enterprise | Documentação do HubSpot |
| Front | Compose: adjust tone (somente e-mail) | Nenhuma configuração de tom encontrada para o Autopilot | 200 ações de Compose por pessoa por dia | Copilot $20/seat/month | Documentação do Front |
Todos os requisitos e limites foram verificados na documentação e nas páginas de preços de cada fornecedor em outubro de 2026.
Os botões do editor são a parte fácil. O menu Enhance writing do Zendesk fica bem na caixa de resposta:
A versão do Freshdesk fica atrás de um botão Write with AI, e o AI Assist do Help Scout mostra a reescrita antes de você substituir seu texto:
Eis o problema de todos esses, e da maioria dos copilotos de IA: "mais amigável" e "mais formal" são controles genéricos, não os seus controles. O próprio exemplo do Zendesk mostra "Make more formal" transformando "We will do our best to assist you" em "We shall make every effort to provide you with the assistance you require" (central de ajuda do Zendesk). É mais formal, claro. Provavelmente não é a sua marca. O botão conhece o formal; só o seu guia sabe como o formal soa na sua empresa. A resposta do Zendesk são as diretrizes de comunicação no complemento Copilot, onde suas regras escritas vencem quando conflitam com o estilo que a IA infere do ticket.
Como ensinar um guia de tom a um agente de IA?
É aqui que a maioria dos guias de tom quebra hoje, porque o agente de IA muitas vezes escreve mais respostas do que qualquer pessoa da equipe. Cada fornecedor dá uma caixa, e as caixas são pequenas. O campo de descrição de tom personalizado do Zendesk mostra um contador de 300 caracteres:
Trezentos caracteres cabem seus traços de voz. Não cabem seis situações, uma lista de frases e uma regra de formalidade por idioma. Os fornecedores também são honestos sobre os limites. O Freshdesk chama suas instruções de IA de "behavioral guidance" em que "edge cases can still occur", e o HubSpot avisa que as respostas "may not always exactly match the specified formatting or wording" (base de conhecimento do HubSpot).
Rodando IA em filas de suporte reais na eesel, aprendi três coisas para fazer uma IA manter um tom:
- Dê situações, não adjetivos. "Amigável" não significa nada para um modelo. "Ao negar um reembolso, diga não na primeira frase e ofereça crédito na loja" funciona.
- Deixe-a aprender com suas melhores respostas anteriores. Os tickets reais da sua equipe carregam seu tom melhor do que qualquer descrição. É por isso que o AI Drafts do Help Scout e a eesel aprendem com conversas anteriores.
- Corrija-a onde o erro acontece. O ciclo de feedback mais rápido é o que acontece no ticket.
Esse terceiro ponto vem direto de clientes da eesel. Um administrador do Zendesk perguntou exatamente isso durante a configuração:
"When I hit 'Reject - too formal, make it friendlier' as a comment in an internal tool, do you have an example for this? I want to know if I can iteratively train it ... within ZenDesk."
Um administrador do Zendesk configurando um agente de IA
É assim que funciona o colega de helpdesk com IA da eesel. O tom vive em instruções em linguagem simples, que ele lê a cada resposta em cada app. Quando você corrige um rascunho ("formal demais, deixe mais amigável") e diz sim, ele escreve a correção nas próprias instruções, ou edita a regra existente se já houver uma que a cubra. Assim a correção vale na semana que vem, não só neste ticket.
Depois você verifica antes que os clientes vejam. A habilidade de simulação da eesel reproduz tickets anteriores reais, avalia cada resposta contra o que sua equipe realmente enviou e sugere mudanças nas instruções. No exemplo de execução da documentação, 17 de 20 tickets da amostra coincidiram com a resposta da equipe. Esse é o passo que eu nunca pularia: ler 20 respostas simuladas diz mais sobre o tom da sua IA do que qualquer página de configurações.
Funciona também do lado humano. Eddie Stephens, Service Desk Lead na CartonCloud, descreveu o que isso faz pelos rascunhos dos seus agentes:
"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 na CartonCloud
Se você está configurando isso, meus guias sobre treinar um agente de suporte com IA e sobre manter a voz de marca da IA consistente vão passo a passo.
Como evitar que um guia de tom fique desatualizado?
Avalie-o. Um guia de tom que não está no QA é só uma sugestão, qualquer que seja a ferramenta de QA que você use. O Smart QA do Front é uma boa referência de como é um critério de tom: seu critério "Tone" padrão pergunta se o tom do agente "suited the situation", com variantes para tom adaptativo, neutro e positivo, ao lado de critérios separados de Empathy e Professionalism (central de ajuda do Front).
"Suited the situation" é o enquadramento certo, e também a armadilha. Se sua ficha checa frases de empatia específicas, você terá agentes recitando frases. Um agente de call center contou como isso se parece:
"My best call was pulled and I was coached for not showing empathy by congratulating the member on their new car immediately. I instead congratulated them at the end of the call and that was against script."
Avalie se o tom se adequou à situação do seu guia, não se uma linha apareceu. Meus posts sobre QA de suporte com IA e exemplos de feedback de QA explicam como escrever critérios que recompensam o bom senso.
Depois faça uma revisão de 30 minutos a cada trimestre: reúna as correções de tom do QA e do histórico de edições da sua IA, e se a mesma correção aparecer três vezes, ela pertence ao guia. Use sessões de feedback para agentes para passar pelas mudanças e leve as correções repetidas para o seu software de coaching.
Coloque seu guia de tom para trabalhar com a eesel
Um guia de tom só importa nas respostas que ele realmente molda. O colega de helpdesk com IA da eesel entra na sua fila atual do Zendesk, Freshdesk, Gorgias ou Help Scout, aprende como sua equipe já escreve a partir de tickets e macros anteriores e segue suas regras de tom como instruções em linguagem simples que você pode corrigir no ticket. Comece com rascunhos como notas internas, reproduza um lote de tickets anteriores para verificar o tom e deixe-o responder tickets de rotina quando ele soar como você. É grátis para testar, com 100 créditos, e os planos pagos começam em US$ 299 por mês na página de preços da eesel.