O chat pode coletar intenção, mostrar produtos, responder dúvidas e informar progresso. Ele não deve virar o banco de clientes, estoque, pedidos, pagamentos, entregas, consentimento ou ownership do atendimento. Comércio conversacional confiável mantém o WhatsApp na borda e sistemas duráveis por trás.
A WhatsApp Business Platform conecta mensagens a backends e equipes de atendimento. A conversa contém pedidos, seleções, dúvidas e notificações; o CRM controla identidade e consentimento, o catálogo controla produtos, o OMS controla o pedido, o PSP confirma o pagamento e o WMS ou transportador produz eventos de fulfillment.
Cada ação precisa de identificador de negócio durável. O cliente pode começar em anúncio, continuar no WhatsApp, pagar no app do banco, ligar para o suporte e receber uma atualização horas depois. O pedido precisa sobreviver a trocas de canal, webhook duplicado, sessão expirada, transferência e falha de entrega.
A policy atual da Meta exige número e opt-in antes de contato iniciado pela empresa. Fora da janela de atendimento de 24 horas, a comunicação depende de template aprovado; automação também precisa oferecer escalonamento claro. Por isso o consentimento não pode ser uma observação solta no CRM.
Armazene finalidade, categoria, versão do texto, origem, horário, jurisdição, ator e revogação. Avalie esse registro antes de cada envio. Separe atualização de pedido, suporte, recomendação e promoção para permitir que marketing seja recusado sem perder alerta de entrega.
Receber o webhook e processar o negócio são responsabilidades diferentes. O endpoint público valida, grava um evento mínimo e imutável, deduplica e retorna rápido. Workers normalizam schema, ordenam, repetem com limites, atualizam CRM/OMS e enviam respostas.
Use o ID do provedor, hash e chave de negócio. Registre received, normalized, routed, applied, ignored, failed e quarantined. Uma redelivery devolve o resultado anterior, sem criar outro carrinho, pedido, chamado ou estorno.
O número no WhatsApp identifica um canal; não comprova identidade legal nem ownership da conta. Mantenha vínculos explícitos entre WABA, número da empresa, usuário, contato do CRM, conta, sessão autenticada, pedido e conversa do agente, com origem e confiança de cada ligação.
Exija verificação adicional antes de expor endereço, fatura, saldo ou alterar dados sensíveis. Não solicite cartão completo, conta bancária ou documento integral no chat. Direcione para jornadas seguras e retorne apenas status mascarado e necessário.
Mensagens de catálogo ajudam na descoberta, mas o card não é cotação definitiva. No momento da seleção, resolva SKU, variante, disponibilidade, região, preço, imposto, promoção e policy. Crie snapshot com expiração e peça confirmação quando houver mudança.
O modelo não deve inventar atributo, trocar variante ou prometer estoque. Retrieval usa campos aprovados, e ferramentas determinísticas validam e fazem commit.
A mensagem “já paguei”, screenshot ou clique no link não prova liquidação. Crie payment intent ou cobrança Pix ligada ao pedido e consuma webhook autenticado ou consulte a API do PSP. Reconcilie ID, valor, moeda, recebedor, status e horários antes de avançar o pedido.
Modele iniciado, pendente, autorizado, pago, falhou, expirou, cancelado, estornado, parcialmente estornado e contestado. Webhooks podem duplicar ou chegar fora de ordem. Retry do cliente deve reutilizar ou substituir explicitamente a cobrança, nunca gerar pagamento duplo silencioso.
Mantenha fulfillment no OMS/WMS e projete apenas eventos úteis: alocado, separando, embalado, entregue ao carrier, em trânsito, saiu para entrega, tentativa, entregue, retirada disponível, devolução solicitada, recebida e reembolsada. Preserve event time, origem, precisão e motivo de exceção.
GS1 EPCIS oferece vocabulário para o que aconteceu, quando, onde e por quê entre organizações. Mesmo sem adotá-lo integralmente, esconda payloads de transportadoras em adapters e publique eventos internos estáveis.
O handoff deve guardar motivo, prioridade, owner, fila, SLA, resumo, identidade verificada, consentimento, carrinho, pedido, pagamento, entrega, ações tentadas, erros e próximo passo. Assim o cliente não recomeça a história.
Transfira quando o cliente pedir, a identidade for insuficiente, a policy bloquear, houver disputa financeira/logística, vulnerabilidade, baixa confiança ou falha repetida. Pause writes concorrentes do bot enquanto o agente controla o caso e defina a devolução de controle.
IA pode classificar intenção, traduzir, resumir, recuperar conteúdo aprovado, extrair campos, sugerir resposta e escolher ferramenta. Não deve atualizar preço, emitir estorno, trocar endereço ou marcar pagamento como concluído diretamente. APIs autenticadas validam schema, autorização, limite e auditoria.
Proteja contra prompt injection em texto do cliente, descrição de produto, notas do CRM e documentos recuperados. Separe instrução de dado, use allowlist de ferramentas, valide argumentos, redija campos sensíveis e avalie o trace completo.
| Intenção | Caminho automático | Evidência necessária | Resposta | Gatilho de handoff |
|---|---|---|---|---|
| Consultar produto | Catálogo, disponibilidade, região e recomendação limitada. | Catálogo aprovado, idioma, visibilidade atual de preço/estoque. | Mensagem de produto com condições e expiração quando necessário. | Item regulado, região sem suporte ou dados conflitantes. |
| Alterar carrinho | Resolver SKU/variante, cotar, versionar e mutar idempotentemente. | Vínculo do carrinho, quote, promoções e policy de reserva. | Resumo atualizado e confirmação explícita. | Disputa de preço, substituição ou bundle complexo. |
| Pagar pedido | Criar cobrança Pix/intent e acompanhar eventos do provedor. | Total, recebedor, transação e status autenticado. | Jornada segura, status pendente e recibo confirmado. | Divergência, duplicidade, fraude, contestação ou incerteza. |
| Rastrear entrega | Ler projeção OMS/WMS e eventos do carrier. | Acesso ao pedido, evento mais recente, origem e exceção. | Marco atual, horário, expectativa e link aprovado. | Falha repetida, extravio, endereço ou dado stale. |
| Devolver/estornar | Elegibilidade, autorização, coleta/etiqueta e workflow financeiro. | Item, entrega, versão da policy, motivo e trilho de pagamento. | Etapas, prazo, autorização e status verificado. | Exceção, alto valor, parcialidade ou reclamação. |
| Falar com pessoa | Criar/anexar caso, congelar writes do bot e rotear por skill. | Resumo, identidade, estado, ações e erros. | Confirmação de ownership e expectativa realista. | Imediato; nunca force outro loop automático. |
Correlacione message ID, conversa, contato, carrinho, quote, pedido, payment intent, envio, caso, agente e trace. Meça lag e aceite de webhook, duplicatas, rejeição de template, entrega/leitura, conclusão automática, falhas de tool, espera por agente, confirmação financeira, exceções e estornos.
Métricas de negócio incluem conversão após cotação verificada, pedido pago concluído, pagamento duplo evitado, resolução no primeiro contato, repetição, exceções abertas, opt-out, bloqueio, precisão da promessa e custo por pedido finalizado.
Teste webhooks duplicados e fora de ordem, template expirado, consentimento revogado, troca de telefone, contatos mesclados, preço alterado, perda de estoque, pagamento confirmado antes da resposta, notificação Pix atrasada, retry duplicado, carrier fora do ar, tracking stale, envio parcial e corrida bot/agente.
Use fixtures reexecutáveis e sem dados sensíveis. Verifique estado final e eventos emitidos, não apenas o texto. Reconciliação deve encontrar pedido pago não liberado, envio sem aviso, estorno sem confirmação e conversa sem owner.
Eu construiria adapter para WhatsApp Cloud API, inbox imutável de webhooks, serviço de identidade e consentimento, router de conversa, adapter de catálogo, serviço de carrinho/cotação, OMS, orquestrador de pagamento, projeção logística, gateway de tools com policy, workspace de agentes e serviço de notificações consciente de templates e janela.
O contrato central seria uma API e stream do ciclo do pedido. WhatsApp, web, app, email e agentes usariam a mesma máquina de estados, sem duplicar lógica financeira ou logística por canal.
Comércio conversacional funciona quando a conversa parece simples porque o backend é explícito. Identidade, consentimento, preço, estoque, pagamento, logística, ownership e auditoria ficam em sistemas duráveis. O WhatsApp apresenta a jornada, mas não guarda sozinho a memória dela.
Artigo sobre automação de vendas no WhatsApp, incluindo webhooks da Cloud API, consentimento, CRM, catálogo, cotação, pedidos, Pix, confirmação de pagamento, logística, IA, handoff humano, testes, segurança e observabilidade.