Chatbot de suporte que responde errado gera ticket humano com cliente mais irritado do que a fila. O problema é o texto que alimenta o bot, não o modelo. Este artigo traz cinco prompts, do FAQ à auditoria mensal, com uma regra comum: o bot só responde o que está na fonte colada, quando não sabe passa para uma pessoa, não promete prazo nem valor fora do que está escrito e nunca pede senha, cartão ou documento.
- A FAQ do bot nasce dos tickets reais (sem identificador de cliente), e a lista "sem fonte" é a documentação que falta.
- Usuário novo recebe três passos com caminho na tela; o bot nunca escreve "em breve" nem cita função que não existe.
- Cada versão nova deixa resposta velha na base: a resposta errada mais perigosa é a que era certa na versão anterior.
- Garantia, cobrança e cancelamento passam direto para humano, com uma mensagem de passagem que resume o que o bot já entendeu.
- A auditoria classifica o erro (inventou, desatualizado, passou tarde, tom) e faz uma correção por categoria; resposta inventada se remove, não se reescreve.
Chatbot que responde errado custa mais que chatbot nenhum
O bot que diz “o reembolso cai em 2 dias” quando a política é 10, que promete uma função que não existe, que pede a senha “para verificar”. Cada resposta dessas vira um ticket humano com um cliente mais irritado do que se tivesse esperado na fila. O problema quase nunca é o modelo: é o texto que alimenta o bot, escrito sem regra de fronteira.
Daí a espinha dos cinco prompts: o bot só responde o que está na fonte colada, quando não sabe, passa para uma pessoa, não promete prazo nem valor fora do que está escrito, e nunca pede senha, cartão ou documento. Já escrevemos sobre prompts para suporte parar de repetir resposta: aquele é sobre a pessoa que atende, este é sobre o bot que atende antes dela.
1. A FAQ do bot nasce dos tickets, não do menu do produto
Monte a base de respostas do chatbot a partir dos tickets abaixo.
TICKETS DOS ÚLTIMOS 30 DIAS: [cole 20 a 40 tickets, sem nome, e-mail,
telefone ou número de pedido]
DOCUMENTAÇÃO OFICIAL: [cole os trechos que respondem a eles]
Entregue: (1) as perguntas agrupadas, escritas como o cliente escreve,
não como o produto chama; (2) para cada uma, resposta de até 3 frases
e o trecho da documentação que a sustenta; (3) a lista "o bot NÃO
responde isto": tudo que envolve dinheiro, prazo, conta ou dado
pessoal, com a frase de encaminhamento para humano.
Se um ticket não tem resposta na documentação, não invente: coloque
em "sem fonte" para eu escrever.A lista “sem fonte” é o item mais útil: é a documentação que falta, descoberta pelo que o cliente já perguntou. E os tickets entram sem identificador: nome, e-mail e número de pedido não têm o que fazer numa ferramenta pública. Base em prompts para desenhar chatbot de FAQ e prompts para criar FAQ de produto.
2. Usuário novo: o bot conduz três passos, não sete
Escreva o fluxo do chatbot para quem acabou de criar a conta.
O QUE O USUÁRIO PRECISA FAZER NA PRIMEIRA SEMANA: [liste, em ordem]
ONDE ELES TRAVAM HOJE: [cole os tickets de conta nova, sem dados]
O QUE O PRODUTO NÃO FAZ E É PERGUNTADO: [liste]
Entregue: (1) mensagem de boas-vindas com UMA pergunta: o que a
pessoa quer fazer primeiro; (2) para cada resposta, os três
próximos passos, cada um com o caminho exato na tela; (3) a
resposta para "o produto faz X?" quando não faz: diz que não faz e
indica a alternativa, sem prometer roadmap.
Não cite função que não esteja na documentação. Não escreva
"em breve".“Em breve” é a mentira mais comum do onboarding: o bot promete e o cliente cobra em 30 dias. Três passos com caminho na tela vencem sete genéricos: usuário novo executa, não lê. Base em prompts para treinar chatbot para novos usuários.
3. Produto novo: o que muda e o que fica errado na base antiga
Toda versão nova deixa resposta velha na base. Ninguém revisa 200 respostas a cada release; o modelo compara.
Compare as notas da versão com a base atual do chatbot.
NOTAS DA VERSÃO: [cole as release notes]
BASE ATUAL DO BOT: [cole as respostas]
MUDANÇA DE PLANO OU PREÇO, SE HOUVER: [cole a tabela oficial]
Entregue: (1) as respostas que ficaram ERRADAS com a versão nova,
cada uma com o trecho da nota que a contradiz; (2) as respostas
novas necessárias, escritas em até 3 frases; (3) o que a nota
menciona sem detalhe suficiente para o bot responder: marque
"confirmar com produto".
Não escreva preço ou prazo que não esteja na tabela colada. Não
reescreva o que não mudou.O item 1 é a auditoria que ninguém faz: a resposta errada mais perigosa é a que era certa na versão anterior. Base em prompts para atualizar o chatbot para novos produtos e prompts para atualizar o conteúdo do bot por precisão.
4. Quando o bot passa para humano, e como, sem fazer o cliente repetir
Defina as regras de passagem do chatbot para atendimento humano.
TIPOS DE PEDIDO QUE CHEGAM: [liste: técnico, garantia, cobrança,
conta, cancelamento]
O QUE O BOT PODE RESOLVER SOZINHO HOJE: [liste]
HORÁRIO DO ATENDIMENTO HUMANO: [informe]
Entregue: (1) para cada tipo, a regra em uma frase: resolve, tenta
uma vez e passa, ou passa direto; (2) a mensagem de passagem, que
diz o que o bot já entendeu e o que a pessoa vai receber, sem pedir
para "explicar de novo"; (3) a mensagem fora do horário, com prazo
de resposta [A DEFINIR] em branco para eu preencher.
Regras: garantia, cobrança e cancelamento passam direto. O bot
nunca pede senha, cartão ou documento. Nunca escreve "seu problema
foi resolvido" antes de uma pessoa confirmar.Passar direto em garantia e cobrança parece perder eficiência; é o contrário. Bot que tenta resolver reembolso gera o ticket duas vezes, e o cliente conta a história nas duas. A passagem que resume o que o bot já entendeu é a única parte da conversa que o cliente elogia. Base em prompts para respostas de chatbot a consultas técnicas, prompts para consultas de garantia e prompts para treinar o bot em questões complexas.
5. Auditoria mensal: classificar o erro antes de corrigir a resposta
Audite as conversas do chatbot abaixo.
CONVERSAS DO MÊS: [cole 30 conversas, sem nome, e-mail ou pedido]
BASE ATUAL DO BOT: [cole]
Para cada conversa com problema, classifique em UMA categoria:
(a) inventou: disse algo que não está na base; (b) desatualizado:
estava na base, mas mudou; (c) passou tarde: devia ter ido para
humano na primeira mensagem; (d) tom: certo no conteúdo, errado no
jeito. Entregue: a contagem por categoria, os 3 exemplos mais
graves de cada uma com a frase exata do bot, e UMA correção por
categoria, não uma por conversa.
Não avalie o cliente. Não proponha resposta nova para o que está
em "inventou": a correção ali é remover, não reescrever.Uma correção por categoria, não trinta. Se o bot inventou, a correção é tirar a resposta, não melhorá-la: inventada e bem escrita é a pior das quatro. Base em prompts para otimizar chatbot por precisão e prompts para gerenciar o desempenho do chatbot.
A regra que atravessa os cinco
Nenhum deixa o bot dizer o que não está escrito. O modelo organiza tickets, documentação e notas de versão; a fronteira (dinheiro, prazo, conta, dado pessoal) vai para uma pessoa. E o texto que chega ao bot é o mesmo que um atacante lê: antes de dar ao chat acesso a qualquer sistema, veja o que a injeção de prompt faz com agentes de IA.
Para a loja que atende pelo bot: prompts para loja virtual. Para o site que vai receber o chat: prompts para desenvolvimento web na entrega. Para o caso mais repetido do bot: prompts para chatbot sobre rastreamento de pedidos.
Perguntas frequentes
Qual é a diferença deste artigo para o de prompts para suporte parar de repetir resposta?
Aquele é sobre a pessoa que atende: base de conhecimento interna, scripts para problema comum e complexo, moderação de e-mail e relatório de satisfação. Este é sobre o chatbot que atende antes dela: o que o bot pode dizer, como recebe um usuário novo, como a base envelhece a cada versão, quando passa para humano e como se audita o erro. O ponto comum é a regra de fronteira: o modelo organiza o que você deu e não inventa o que não está na fonte.
Por que o bot não deve tentar resolver reembolso ou garantia?
Porque são os pedidos em que a resposta errada custa dinheiro ou vira reclamação formal. O bot não tem acesso confiável ao status do pagamento nem ao estado físico do produto, e a política tem exceções que a base não cobre. O quarto prompt manda passar direto: o cliente chega à pessoa com o contexto resumido pelo bot, em vez de contar a história duas vezes depois de uma promessa que o bot não podia fazer.
Posso colar os tickets reais no ChatGPT ou no Claude para montar a FAQ?
O conteúdo do problema sim; o identificador do cliente não. Nome, e-mail, telefone e número de pedido saem antes de colar, e os prompts pedem isso de forma explícita. O que o modelo precisa é a pergunta e a resposta que funcionou; quem perguntou é dado pessoal de terceiro e não tem função na tarefa. O mesmo vale para as conversas da auditoria mensal.
Se a auditoria mostrar que o bot inventou uma resposta bem escrita, não vale corrigir o texto?
Não. Resposta inventada é a que não tem trecho de documentação sustentando; se está bem escrita, é mais perigosa, porque ninguém desconfia. A correção é remover a resposta e colocar a pergunta na lista de encaminhamento para humano até existir documentação. Reescrever mantém o problema de origem: o bot continua respondendo sem fonte.
