Pesquisa de satisfação (NPS) no WhatsApp com enquete pela API

Para fazer pesquisa de satisfação no WhatsApp pela API não oficial, envie uma enquete nativa com POST /message/poll logo após o atendimento ou a entrega, para o próprio cliente atendido, e receba o voto pelo webhook. O cliente responde com um toque, sem sair da conversa e sem abrir link de formulário — e é exatamente isso que faz a taxa de resposta de uma enquete no WhatsApp ser tão maior que a de um e-mail com pesquisa.

A seguir: como montar a pergunta, quando disparar, como tratar cada nota e os cuidados para a pesquisa não virar motivo de denúncia.

Por que enquete, e não link de formulário

O modelo clássico de pesquisa é mandar um link. O cliente precisa tocar, esperar a página carregar, encontrar a escala, clicar, confirmar. Cada passo perde gente.

A enquete nativa do WhatsApp elimina todos eles. A pergunta e as opções aparecem dentro da conversa; o cliente toca numa opção e pronto. Três vantagens práticas:

• Um toque só. Nenhuma página, nenhum login, nenhum carregamento.
• Contexto preservado. A pesquisa aparece logo abaixo do atendimento que ela está avaliando.
• Resposta estruturada. Diferente de pedir "responda de 0 a 10", você não precisa interpretar texto livre como "nota 9, mas demorou".

A enquete é um dos recursos que a camada não oficial libera por conectar como o WhatsApp Web — junto com figurinha, reação e status. Veja o panorama completo em recursos da API não oficial.

Os dois endpoints: poll e survey

A WAME tem duas formas de enviar enquete.

A poll dá controle de quantas opções o cliente pode marcar:

curl -X POST "https://us.api-wa.me/SUA_KEY/message/poll" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "5511999999999",
    "name": "Como foi seu atendimento hoje?",
    "values": ["😍 Excelente", "🙂 Bom", "😐 Regular", "😞 Ruim"],
    "selectableCount": 1
  }'

A survey é a forma simplificada, com options:

curl -X POST "https://us.api-wa.me/SUA_KEY/message/survey" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "5511999999999",
    "name": "Seu pedido chegou certinho?",
    "options": ["Sim, tudo certo", "Chegou com problema"]
  }'

Para pesquisa de satisfação, use selectableCount: 1. Permitir várias marcações faz sentido em outro tipo de pergunta ("o que você mais gostou?"), não em nota.

NPS de 0 a 10 cabe numa enquete?

O NPS tradicional pergunta "de 0 a 10, quanto você recomendaria?". São onze opções — cabe, mas no celular vira uma lista comprida, e parte das pessoas desiste de rolar.

Duas saídas que funcionam melhor:

1. NPS em faixas. Você mantém a lógica de promotores, neutros e detratores, com três opções:

{
  "to": "5511999999999",
  "name": "De 0 a 10, quanto você recomendaria a gente para um amigo?",
  "values": ["9 ou 10 — com certeza", "7 ou 8 — talvez", "0 a 6 — não recomendaria"],
  "selectableCount": 1
}

2. CSAT curto. Em vez de recomendação, pergunte satisfação com o atendimento específico, com três a cinco opções. É a métrica mais útil para avaliar atendente, fluxo de bot ou prazo de entrega.

Escolha uma e mantenha. Trocar a escala a cada mês destrói a comparação histórica.

Quando enviar

O momento decide a taxa de resposta — e também o risco.

A regra que não pode ser quebrada: a pesquisa vai para quem acabou de conversar com você. A conversa já está quente, o cliente reconhece o número e sabe do que se trata. Mandar enquete para uma lista de pessoas que nunca falaram com o seu número é outra coisa — é mensagem não solicitada, e é o tipo de envio que gera denúncia.

Mais dois cuidados:

• Uma pesquisa por interação. Se o cliente teve três atendimentos na semana, ele não precisa de três enquetes.
• Não insista. Quem não respondeu não recebe lembrete de pesquisa.

Recebendo o voto pelo webhook

Quando o cliente vota, o evento chega no webhook configurado na instância. O formato exato está na documentação; o que importa para o seu sistema é guardar três coisas:

1. o identificador da mensagem da enquete (que você recebeu na resposta do envio);
2. o número de quem votou;
3. a opção escolhida.

Um esqueleto em Node.js, sem depender do formato exato do evento:

// Ao enviar, guarde a relação enquete → atendimento
const envio = await fetch(`https://us.api-wa.me/${KEY}/message/poll`, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    to: cliente.numero,
    name: 'Como foi seu atendimento hoje?',
    values: ['😍 Excelente', '🙂 Bom', '😐 Regular', '😞 Ruim'],
    selectableCount: 1,
  }),
}).then(r => r.json());

await db.pesquisas.insert({
  atendimentoId: atendimento.id,
  numero: cliente.numero,
  mensagem: envio, // guarde o id retornado — o formato está em /docs
  enviadaEm: new Date(),
});

No webhook, responda 200 imediatamente e processe depois. Webhook lento é reenviado, e você grava o mesmo voto duas vezes — o artigo sobre webhook em produção mostra como tornar isso idempotente.

O que fazer com cada nota

Pesquisa que só vira gráfico não muda nada. A resposta tem que disparar uma ação:

• Nota alta (promotor ou "Excelente"): agradeça com uma mensagem curta. Se fizer sentido para o seu negócio, é o momento de pedir uma avaliação pública.
• Nota média: registre e acompanhe a tendência por atendente e por fluxo.
• Nota baixa (detrator ou "Ruim"): abra um alerta para um humano. Uma resposta rápida de alguém do time — "vi que sua experiência não foi boa, pode me contar o que aconteceu?" — recupera cliente que estava indo embora.

Esse último ponto é o que mais gera retorno. Para organizar quem precisa de follow-up sem montar um CRM, use labels na API: uma etiqueta "detrator" no chat já basta para o time encontrar.

Um fluxo completo, em quatro passos

1. O ticket é encerrado no seu sistema.
2. Seu backend envia a enquete pela API para aquele cliente, e guarda o id.
3. O voto chega no webhook; você grava a nota ligada ao atendimento.
4. Se a nota é baixa, uma label é aplicada e o time recebe o alerta.

É pouco código e roda em qualquer linguagem — com o SDK JavaScript, o SDK PHP ou HTTP puro, como no tutorial em Python.

Cuidados com volume

Uma pesquisa pós-atendimento acompanha naturalmente o ritmo do seu atendimento: se você atende cem pessoas por dia, envia no máximo cem enquetes, espalhadas ao longo do dia, para conversas que já estavam ativas. Esse é o cenário em que a API não oficial é muito estável e a taxa de bloqueio é muito baixa.

O que muda o cenário é transformar a pesquisa em campanha: pegar a base inteira de clientes dos últimos dois anos e mandar uma enquete para todo mundo de uma vez. Aí você tem muitos destinatários novos em pouco tempo, gente que não lembra de você, e denúncia. A WAME não apoia spam, e isso vale também para pesquisa. Se precisar de uma pesquisa com a base inteira, faça em lotes pequenos, só com quem deu opt-in, como descrito em opt-in e opt-out e em fila e rate limit.

Lembrete: a camada não oficial não é afiliada ao WhatsApp nem à Meta, e o uso é de responsabilidade de quem envia.

Conclusão

Enquete nativa é a forma mais simples de medir satisfação no WhatsApp: o cliente responde com um toque, dentro da conversa que acabou de ter com você. Pela API não oficial da WAME, basta um POST /message/poll (ou /message/survey), guardar o id do envio e ler o voto no webhook. Envie logo após o atendimento, só para quem foi atendido, use uma escala curta e transforme nota baixa em ação humana rápida. Assim a pesquisa melhora o atendimento — em vez de virar mais uma mensagem que ninguém pediu.