Vários atendentes podem responder pelo mesmo número de WhatsApp?

Sim. O número fica conectado uma vez na API e todos os atendentes trabalham pela tela do seu helpdesk. Quem responde cada conversa é decidido pelo seu sistema, não pelo WhatsApp.

O cliente final percebe quando a conversa é transferida?

Não, a menos que você avise. A transferência acontece dentro do helpdesk e as mensagens continuam saindo do mesmo número. Muitas plataformas mandam uma frase curta dizendo quem assumiu, o que costuma reduzir repetição de pergunta.

Dá para saber se o cliente leu a resposta do atendente?

Sim. A API envia os eventos message.delivered e message.read para o seu webhook. O helpdesk usa esses eventos para mostrar os ticks na conversa e para medir o tempo até a leitura.

Como medir SLA de primeira resposta com a API?

Todo evento messages.received traz o timestamp da mensagem. O helpdesk grava esse horário ao abrir o ticket e fecha a contagem quando o primeiro envio de um atendente é aceito pela API.

E se a conexão de um cliente do helpdesk cair durante o expediente?

O evento connection.status avisa a mudança de estado. A D-API tenta recuperar a conexão sozinha, e o helpdesk deve mostrar um alerta ao administrador para o caso de o número ter sido desconectado no celular.

Posso ligar um chatbot antes da fila humana?

Pode. O bot recebe o mesmo webhook, responde as perguntas simples e, quando precisa de gente, o helpdesk coloca a conversa na fila com o contexto já coletado.

API de WhatsApp para helpdesk multiagente

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 sessionId e 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.

API de WhatsApp para helpdesk: filas, SLA e vários atendentes num número