Pedido por WhatsApp costuma misturar texto, áudio, foto, PDF e correções posteriores. A integração útil não é copiar a última mensagem para o Protheus: é transformar uma conversa em uma proposta estruturada, pedir confirmação e só então acionar a rotina de pedido.
O canal e o ERP têm responsabilidades diferentes. A WhatsApp Business Platform entrega e recebe mensagens; uma camada intermediária mantém contexto, catálogo e estado da confirmação; o Protheus continua responsável por cadastro, preço, crédito, estoque e faturamento.
Arquitetura do canal ao ERP
A entrada oficial usa webhook do WhatsApp Business Platform. Cada evento é autenticado, armazenado e respondido rapidamente; o processamento pesado ocorre em fila. Texto e anexos são normalizados, e a conversa é associada ao telefone, CNPJ solicitado e cliente/loja candidatos no Protheus.
O orquestrador monta um carrinho temporário com código, descrição, quantidade e unidade. Antes de criar o pedido, envia um resumo ao comprador e registra sua confirmação. Mudanças depois da confirmação viram uma nova versão, não uma edição silenciosa.
Catálogo e correspondência de produtos
O bot pode aceitar código exato, busca por nome ou lista guiada. A fonte de produto deve vir de uma réplica ou API controlada, com preço e disponibilidade tratados como consulta momentânea. Uma descrição parecida não basta para itens com modelo, voltagem, lote ou unidade diferentes.
Quando o cliente usa o próprio código, o de/para produto-cliente é mais confiável. Novas correspondências ficam para aprovação e depois alimentam o mapa, reduzindo perguntas nas próximas compras.
Criação na MATA410
Após a confirmação, o conector usa API suportada ou MSExecAuto da MATA410. Cabeçalho e itens passam pelas mesmas regras da operação normal. O retorno precisa distinguir pedido criado, bloqueio de crédito, falta de estoque, preço divergente e erro técnico.
O número da conversa e uma referência externa formam a chave de idempotência. Uma retentativa do webhook ou do conector não deve gerar dois pedidos. O cliente recebe um status compreensível somente depois de a transação ser confirmada.
Limites do WhatsApp
Mensagens proativas fora da janela de atendimento usam templates aprovados e a empresa precisa cuidar de opt-in, finalidade e dados pessoais. O número não deve virar um canal aberto para consultar qualquer cadastro do ERP; autorização e escopo são definidos por perfil.
Também é preciso prever atendimento humano. Produto ambíguo, condição especial, negociação e reclamação saem do fluxo automatizado com todo o contexto preservado.
Piloto que prova valor
Começamos por clientes recorrentes e um subconjunto de produtos com códigos claros. Medimos pedidos concluídos sem redigitação, tempo até confirmação, divergências e intervenções humanas.
Para estimar o projeto, precisamos de amostras de conversas, política de preço, regra de identificação do cliente, release do Protheus e canal oficial do WhatsApp. O piloto deve rodar primeiro em homologação e com limite de valor ou cliente.