Prompts para suporte: 5 para parar de repetir resposta

O caro no suporte não é o ticket difícil

Quem toca atendimento aprende rápido que o custo não está no caso complicado. O que consome o time é o ticket que já foi respondido quarenta vezes — o mesmo problema, a mesma explicação, redigitada por gente diferente, com qualidade diferente, todo dia.

Modelo de linguagem ajuda nessa faixa com uma condição que não é negociável: o texto do suporte compromete a empresa. Prazo, reembolso, exceção e garantia dita no chat viram obrigação, e não adianta depois dizer que foi o robô. Por isso os cinco prompts abaixo carregam a mesma proibição no fim.

1. Transformar ticket resolvido em artigo de base

Transforme o atendimento abaixo em um artigo de base de conhecimento.

CONVERSA COMPLETA: [cole, do primeiro contato até a resolução]
O QUE RESOLVEU DE FATO: [a ação final, em uma frase]

Entregue: (1) o título como o CLIENTE descreveria o problema, não
como a empresa o classifica; (2) como reconhecer que é este caso;
(3) o passo a passo da solução; (4) o que fazer se não funcionar.

Regras: nada de jargão interno nem nome de sistema que o cliente
não vê. Se a solução dependeu de acesso que só o time tem, diga
isso no artigo em vez de fingir que o cliente resolve sozinho.

O item 1 é o que decide se o artigo vai ser encontrado. Base de conhecimento morre quando é organizada pelo vocabulário de quem escreveu — o cliente não busca “falha de sincronização de webhook”, ele busca “não recebi o e-mail”. Variações em prompts para artigos de base de conhecimento.

2. Script para o problema comum — e onde ele para de servir

Escreva o script de atendimento para o problema recorrente abaixo.

PROBLEMA: [descrição + com que frequência aparece]
SOLUÇÃO PADRÃO: [o passo a passo que o time usa hoje]
POLÍTICA APLICÁVEL: [cole o texto de prazo, garantia, reembolso]

Entregue: (1) a abertura; (2) as 3 perguntas de triagem, na ordem
que elimina mais casos primeiro; (3) a resposta padrão;
(4) o CRITÉRIO EXPLÍCITO para sair do script e escalar.

Regras: não prometa prazo, valor ou exceção que não esteja na
política colada acima. Se a política não cobre o caso, o script
manda escalar — não manda improvisar.

O item 4 é o que a maioria dos scripts não tem — e é o que gera o pior atendimento que existe: o atendente preso num roteiro que já não serve há três mensagens. Base em prompts para scripts de problemas comuns.

3. O caso complexo pede roteiro, não script

Monte um roteiro de condução para o caso complexo abaixo.

CASO: [o que o cliente pediu e por que sai do padrão]
O QUE PODE SER FEITO: [as opções reais, com custo e prazo de cada]
O QUE NÃO PODE: [limites técnicos, contratuais e de política]
QUEM DECIDE: [quem aprova exceção, e até que valor]

Entregue: (1) o que confirmar com o cliente antes de qualquer
promessa; (2) as opções, na ordem que resolve mais rápido;
(3) a frase de transição para quando a resposta for não;
(4) o que registrar no ticket para quem pegar depois.

Regras: nenhuma opção fora da lista "o que pode ser feito".
Se a decisão depende de aprovação, o roteiro diz isso ao cliente
em vez de antecipar o resultado.

Script é para executar, roteiro é para conduzir. Caso complexo com script vira atendimento robótico; caso simples com roteiro queima tempo. Ponto de partida em prompts para solicitações complexas.

4. Responder ao cliente irritado sem escalar

Escreva a resposta para a mensagem hostil abaixo.

MENSAGEM DO CLIENTE: [cole, literal, sem limpar]
O QUE ACONTECEU DE FATO: [a versão do time, com datas]
O QUE PODEMOS OFERECER: [só o que já está aprovado]

Entregue duas versões: (1) reconhecendo erro nosso, se houve;
(2) esclarecendo o mal-entendido, se o erro não foi nosso.
Em ambas: o que aconteceu, o que fazemos agora, e até quando.

Regras: não peça desculpa por algo que não fizemos — isso vira
prova. Não use "lamentamos que você se sinta". Nunca responda à
ofensa. Cada versão termina com UMA data.

A restrição sobre desculpa genérica não é etiqueta: em disputa de consumo, texto de atendimento é documento — e culpa reconhecida no vago aparece do outro lado da mesa. Mais em prompts para moderação de mensagens inadequadas.

5. Relatório de satisfação que aponta causa, não nota

Analise os dados de satisfação abaixo e escreva o relatório.

NOTAS E COMENTÁRIOS: [cole o CSAT/NPS com os comentários abertos]
VOLUME POR MOTIVO DE CONTATO: [quantos tickets de cada tipo]
PERÍODO ANTERIOR: [os mesmos números]

Entregue: (1) o que mudou em relação ao período anterior;
(2) os 3 motivos de contato que mais geram nota baixa, cada um com
o comentário que sustenta; (3) quais são problema de ATENDIMENTO e
quais são problema de PRODUTO.

Regra: comentário isolado não vira conclusão. Se o dado não
explica a variação da nota, escreva que não explica.

O item 3 é a parte que muda decisão. Boa parte da nota baixa em suporte não é sobre suporte — é sobre um produto que quebra num ponto específico, e o time de atendimento vira o para-raios. Separar as duas coisas é o que transforma o relatório em pauta de roadmap. Veja também prompts para relatórios de satisfação do cliente.

A proibição que vale para os cinco

Todos terminam com a mesma linha: o modelo não promete prazo, valor ou exceção que não esteja na política colada. Não é excesso de zelo: o modelo preenche lacuna com o que soa razoável, e “em até 5 dias úteis” soa razoável mesmo quando ninguém prometeu. No suporte, essa frase inventada vira obrigação.

É a mesma disciplina dos outros ofícios que já cobrimos — no atrito entre agência e cliente e na entrega de um site: dado bruto e restrição entram, estrutura sai. Quem responde continua respondendo pela resposta.