Como não perder clientes por demora na resposta do WhatsApp?

1. Meça a espera que a cliente realmente sente

Comece separando três momentos: a mensagem chegou ao WhatsApp, a conversa entrou no inbox e uma resposta foi aceita pelo provedor. Eles podem acontecer em tempos diferentes. A tela mostra o horário da última mensagem e atualiza a lista por polling e eventos em tempo real, mas a interface não transforma esse relógio em uma promessa de atendimento. Antes de comparar semanas, escolha o intervalo, o fuso e o que conta como primeira resposta.

Uma pergunta de preço, uma confirmação de agenda e uma reclamação não têm o mesmo risco. A secretária de IA pode tratar uma mensagem repetitiva, mas o código também reconhece pedidos de atendimento humano e cria um aviso persistente quando a conversa precisa de alguém. A demora aceitável deve ser uma regra de operação da clínica, não uma frase de marketing copiada de outro sistema.

Registre uma linha de base com conversas reais: quando a mensagem entrou, quando a IA respondeu, quando a equipe assumiu e quando a conversa foi encerrada. Não conte presença online da equipe como resposta entregue. O produto guarda histórico de mensagens e estados; ele não fornece um percentual universal de satisfação ou uma garantia de que a cliente leu.

• Defina primeira resposta, período, fuso e denominador.
• Separe demora do provedor de demora da decisão humana.
• Use dados da própria clínica antes de escolher uma meta.

2. Faça do inbox a fonte única da conversa

A caixa de entrada do sistema lista até cinquenta conversas ordenadas pela mensagem mais recente e mostra nome, telefone, prévia, não lidas e modo atual da IA. Ao abrir uma conversa, a tela carrega as últimas mensagens, zera o contador de não lidas e mantém a seleção mesmo enquanto atualizações chegam. Isso evita que a recepção procure a mesma cliente no celular pessoal, numa planilha e em uma aba diferente.

Mensagens de texto, áudio, imagem, vídeo, documento, localização, reação e contato têm renderização própria. O histórico também diferencia cliente, IA, equipe e mensagem enviada pelo celular da proprietária, além de mostrar estados de entrega. Uma mídia que ainda não pôde ser carregada aparece como estado de erro localizado; não deve ser substituída por uma resposta inventada só para a lista parecer completa.

O inbox é uma área autenticada e mostra conversas reais quando o WhatsApp está conectado. Em modo demonstração ele fica desativado, e uma conta sem conversas mostra um estado vazio. Essa diferença importa para o atendimento: não confunda uma tela de teste com uma fila comercial nem prometa que uma página pública fará a triagem de clientes sem uma conexão autorizada.

• Abra a conversa pelo inbox antes de responder em outro canal.
• Use prévia, não lida, mídia e entrega para reconstruir o contexto.
• Modo demonstração sem WhatsApp não é uma fila de clientes.

3. Deixe o debounce juntar mensagens da mesma pessoa

Clientes costumam enviar várias mensagens curtas: nome do procedimento, foto, horário e uma pergunta. O motor não dispara uma resposta isolada a cada bolha. Depois que uma mensagem chega, `scheduleAiReply` lê a configuração de debounce e agenda o processamento; o padrão é trinta segundos e o limite configurável é de trezentos segundos. Uma nova mensagem na mesma conversa remove o trabalho anterior e reinicia a janela.

Em produção, a fila `nl-ai-reply` usa BullMQ sobre Redis quando a conexão está disponível. O worker processa até cinco trabalhos em paralelo e os jobs têm identificador determinístico por conversa. Se Redis não estiver acessível, o serviço registra o aviso e usa um timer em memória. Esse fallback ajuda desenvolvimento e continuidade controlada, mas não é uma promessa de durabilidade de fila depois de reiniciar o processo.

A clínica deve escolher uma janela que a equipe consiga acompanhar. Debounce curto pode responder antes que a cliente termine de explicar; debounce longo pode parecer silêncio. Compare a configuração com o horário de funcionamento, o volume de mensagens e a capacidade de takeover. Não use a palavra instantâneo para descrever uma rotina que deliberadamente espera contexto.

• Mensagens novas reiniciam o debounce da mesma conversa.
• O padrão é 30 segundos; o teto do código é 300 segundos.
• Redis ativo e fallback em memória têm garantias diferentes.

4. Configure a IA com uma fonte que a equipe possa revisar

A resposta nasce da configuração publicada da secretária e do histórico recente da conversa. A clínica pode testar uma versão, publicar depois da revisão, pausar e voltar a uma configuração anterior conforme o fluxo administrativo. O idioma, o catálogo, as regras de agenda e as instruções de segurança entram no contexto do agente; quando um dado não foi configurado, a resposta deve pedir confirmação em vez de preencher o espaço com preço ou disponibilidade.

O agente pode responder, não responder, encerrar ou pedir atendimento humano. Quando uma ferramenta de agenda falha ou uma alteração não foi confirmada, o fluxo usa uma mensagem de fallback e deixa a decisão para a responsável. Reclamações e sinais adversos também geram alerta persistente. Isso evita que velocidade seja obtida à custa de uma promessa clínica ou comercial que ninguém conferiu.

Revise o que a IA sabe antes de procurar um problema de tempo. Catálogo ativo, políticas, fuso e instância conectada precisam refletir a operação de hoje. Uma alteração publicada não torna o provedor mais rápido e uma instrução longa não substitui o gate de envio. A melhor configuração é a que permite à equipe reconhecer o limite e assumir a conversa sem recomeçar do zero.

• Publique somente a configuração revisada pela clínica.
• Dado ausente deve virar confirmação, não preço inventado.
• Fallback e handoff preservam o contexto para a equipe.

5. Confira os gates antes de deixar uma resposta sair

O worker faz uma checagem inicial: a conversa precisa existir, estar aberta e ter a IA ativa; a cliente precisa existir e não pode ter opt-out ou bloqueio. Imediatamente antes de cada bolha, `finalSendEligibility` consulta novamente o estado fresco, a lista de supressão e os mesmos critérios. Se a equipe assumiu a conversa enquanto a IA preparava o texto, o envio é bloqueado pelo motivo `human_takeover`.

O gate da plataforma também pode interromper a resposta por clínica suspensa, kill-switch ou limite de orçamento. Uma instância ausente, provider sem conexão ou falha de saúde não deve ser escondida por uma mensagem otimista no inbox. O caminho seguro é registrar o estado, avisar a equipe e não repetir automaticamente um envio cuja confirmação ficou ambígua.

Essas verificações podem parecer lentas quando comparadas a um disparo direto, mas protegem a cliente e a clínica. Opt-out, bloqueio e conversa fechada vencem a meta de velocidade. A mesma disciplina vale para campanhas: a automação de marketing usa fila, horários e limites e não transforma a caixa de entrada em ferramenta de envio em massa.

• Conversa aberta e IA ativa são requisitos de cada resposta.
• Opt-out, bloqueio e supressão impedem o envio.
• Uma resposta preparada pode ser descartada por mudança de estado.

6. Faça o takeover quando a situação pedir uma pessoa

A equipe não precisa esperar a IA terminar para assumir. O botão de takeover muda o modo da conversa para `paused_takeover`, grava quem assumiu, registra auditoria e emite um evento de início. A lista passa a mostrar que a IA está pausada e, quando possível, quem está atendendo. Uma segunda pessoa não deve disputar a mesma conversa sem perceber: o servidor aplica o vínculo e informa quando ela já foi assumida.

A equipe pode assumir uma conversa pausando a IA e devolver o atendimento depois, sem misturar as duas respostas.

O handoff também pode nascer do próprio agente. Reclamação, reação adversa, dúvida sensível ou uma tarefa que não foi concluída criam um aviso humano ligado à conversa. A recepção abre o histórico, lê o motivo e responde no contexto. A velocidade que importa nesse momento é reduzir a repetição para a cliente, não manter um robô falando enquanto alguém precisa decidir.

Takeover não apaga mensagens nem encerra a conversa. Ele pausa a IA e mantém o histórico, a mídia, o contato e os estados de entrega. A responsável pode escrever a resposta, registrar a decisão no sistema e devolver a conversa quando a situação estiver pronta para o fluxo automático. Se a clínica não deseja que a IA retome, deve deixar o modo pausado e tratar a fila como atendimento humano.

• Takeover pausa a IA e identifica a pessoa responsável.
• Handoff gera aviso persistente sem apagar o histórico.
• Outra equipe não deve responder por cima de quem assumiu.

7. Responda e devolva a conversa sem duplicar mensagens

Ao responder pelo compositor do inbox, a equipe envia uma mensagem de texto ligada à conversa e ao tenant. O servidor reserva o envio antes de falar com o WhatsApp, usa `clientMessageId` quando fornecido e uma chave de intenção para impedir duas inserções quando a mesma ação é repetida. Se o provider falhar ou o recibo ficar ambíguo, a mensagem recebe estado próprio e o sistema não tenta uma segunda cópia às cegas.

Uma resposta humana também coloca a conversa em `paused_takeover` automaticamente, para a IA não escrever por cima enquanto a equipe continua o atendimento. O placeholder da tela avisa que responder pausa a IA, e o botão de devolução exige uma ação explícita. Depois da devolução, uma nova mensagem pode voltar a agendar o debounce; o histórico anterior continua sendo contexto, não uma conversa nova.

Escreva o próximo passo com o que foi realmente confirmado: preço do catálogo, horário salvo ou orientação para a responsável retornar. Não use uma resposta rápida para prometer estoque, reembolso, resultado clínico ou vaga que não passou pelo servidor. Velocidade sem idempotência, elegibilidade e autorização apenas troca espera por retrabalho e risco de duas mensagens iguais.

• A reserva e a chave de intenção protegem contra duplo envio.
• Responder como equipe pausa a IA automaticamente.
• Devolver à IA é explícito e conserva o histórico.

8. Revise estados, falhas e limites toda semana

Uma rotina de atendimento termina na leitura dos estados, não no clique em enviar. Veja conversas abertas, pausadas, não lidas e com alerta humano. Para cada resposta, diferencie pendente, enviada, entregue, lida, falha e desconhecida. Uma falha de atualização pode deixar a tela com os últimos dados conhecidos; ela não deve ser interpretada como uma fila vazia nem como autorização para repetir a mensagem.

A fila expõe métricas de modo, trabalhos ativos, aguardando, atrasados e falhos. Use esses sinais para procurar Redis indisponível, provider instável, debounce excessivo ou uma configuração que está gerando handoffs demais. O sistema registra auditoria de takeover, devolução e envio da equipe, mas não calcula sozinho o valor de cada venda recuperada nem prova que uma cliente foi perdida por uma demora específica.

Feche a semana com uma amostra de conversas lidas do começo ao fim. Marque quando uma resposta foi adequada, quando faltou dado e quando a pessoa precisou assumir. Se a clínica precisar de SLA, roteamento por equipe, confirmação de leitura comercial ou disponibilidade garantida do provider, registre como oportunidade de produto. Até lá, a página deve dizer a verdade: a Bia organiza a resposta e o fallback; a operação ainda decide e verifica.

• Estado desconhecido pede investigação, não reenvio automático.
• Métricas de fila mostram saúde técnica, não receita recuperada.
• SLA e disponibilidade do provider não são promessas atuais.