O que muda quando o canal é WhatsApp e não e-mail
Plataforma de atendimento nasceu em cima de e-mail, onde o ticket é natural: uma mensagem longa, uma resposta, um assunto. No WhatsApp o cliente manda seis mensagens curtas, um áudio e uma foto em dois minutos, e espera resposta no ritmo de conversa. O helpdesk que só "pluga" o WhatsApp no modelo de ticket entrega uma experiência ruim para o atendente e para o cliente final.
Os pontos que mais geram reclamação de quem usa helpdesk com WhatsApp são sempre os mesmos: conversa caindo na fila errada, dois atendentes respondendo a mesma pessoa, SLA que não reflete a realidade e número desconectado que ninguém percebeu até o fim do dia.
Quem faz o quê: a API e o seu helpdesk
A confusão mais comum em projeto de helpdesk é esperar que a API de WhatsApp resolva regra de atendimento. Ela não resolve, e não deveria. A divisão fica assim:
| Funcionalidade do helpdesk | O que a API entrega | O que o seu produto decide |
|---|---|---|
| Filas | Evento messages.received com remetente e conteúdo | Para qual fila a conversa vai, por horário, palavra-chave ou resposta de menu |
| Atribuição | O sessionId diz de qual cliente e de qual número veio | Rodízio, carga por atendente, dono fixo da conta |
| SLA | timestamp de cada mensagem recebida | Metas, pausas fora do expediente, alerta de estouro |
| Status de leitura | Eventos message.delivered e message.read | Como exibir os ticks e se isso conta para o SLA |
| Transferência | Nada muda: o número continua o mesmo | Quem assume, se leva histórico, se o cliente é avisado |
| Saúde do canal | Evento connection.status e reconexão por API | Alerta no painel do administrador |
Essa separação é o que permite trocar ou combinar tipos de conexão sem mexer nas regras. Na D-API, um cliente do helpdesk pode usar a API oficial e outro a não oficial, e o motor de filas nem percebe.
Exemplo: um endpoint por responsabilidade
Em helpdesk, vale separar os eventos por destino desde o começo. Mensagem nova vai para o serviço de roteamento, leitura vai para o serviço de status e queda de conexão vai para alertas. O modo per_event da configuração de webhook faz exatamente isso:
curl -X POST https://api.d-api.cloud/api/v1/sessions/helpdesk-cliente-318/webhook-config \
-H "Authorization: SUA_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"enabled": true,
"type": "per_event",
"events": {
"messages.received": { "enabled": true, "webhookUrl": "https://api.seuhelpdesk.com/wa/roteamento" },
"message.delivered": { "enabled": true, "webhookUrl": "https://api.seuhelpdesk.com/wa/status" },
"message.read": { "enabled": true, "webhookUrl": "https://api.seuhelpdesk.com/wa/status" },
"connection.status": { "enabled": true, "webhookUrl": "https://api.seuhelpdesk.com/wa/alertas" }
}
}'Com isso, um pico de leituras não atrasa a chegada de mensagens novas na fila. Se o volume da sua base for alto, a mesma configuração existe para RabbitMQ, e o helpdesk consome os eventos da fila no ritmo dele. Mais sobre formatos e reentregas em webhook de WhatsApp.
Três armadilhas de helpdesk com WhatsApp
Conversa duplicada por reentrega
O webhook é reenviado em caso de falha, com até 7 tentativas. Se o serviço de roteamento demorou para responder e o evento chegou de novo, a mesma mensagem pode abrir dois tickets. Trave pela chave do id da mensagem antes de qualquer outra lógica.
Resposta dada pelo celular da empresa
Na API não oficial, o número segue ativo no aparelho. Se um supervisor responde pelo celular, a mensagem chega com fromMe verdadeiro e precisa entrar no histórico do ticket, senão o próximo atendente responde por cima.
SLA contado em mensagem, não em conversa
Seis mensagens seguidas não são seis tickets. Agrupe mensagens do mesmo remetente numa janela curta e conte o SLA a partir da primeira, não da última.
Roteiro para colocar WhatsApp na sua plataforma de atendimento
- Onboarding do cliente: criar a conexão por API com o id do cliente no
sessionIde exibir o QR Code. - Webhook separado por evento, com deduplicação pelo id da mensagem.
- Agrupamento de mensagens em conversa e regra de roteamento para fila.
- Envio de resposta, mídia e documentos pela tela do atendente.
- Ticks de entrega e leitura, e métricas de SLA calculadas a partir dos timestamps.
- Painel de saúde das conexões por cliente, com botão de reconectar.
O passo 3 é o que diferencia um helpdesk do outro, e é onde o seu time deveria gastar tempo. A parte de manter cada número conectado e isolado dos demais fica com a D-API, com self-healing e IP próprio por conexão. Os 14 dias grátis falando com o time comercial servem justamente para validar os passos 1 e 2 com a sua base real.
Próximos passos
Se a sua plataforma também faz pré-atendimento automático, veja chatbot de WhatsApp com IA. Se ela nasceu como CRM e está ganhando fila e SLA, a leitura complementar é WhatsApp para CRM. O modelo comercial para quem oferece WhatsApp aos próprios clientes, com uma conexão por cliente, está em API de WhatsApp para SaaS.