Automação de pedido de venda: do WhatsApp, e-mail ou planilha ao lançamento e ao faturamento no ERP

Dá para automatizar a entrada do pedido de venda, inclusive o pedido que chega como mensagem de WhatsApp escrita à mão. O que costuma ser mal dimensionado em um projeto de automação de pedido de venda é onde mora o trabalho: quem pede orçamento imagina que o custo está em ler o texto, e o custo está em transformar aquele texto em dados que o sistema de gestão reconhece.

Automação de pedido de venda: as sete etapas e em qual grupo cada uma cai

O pedido de venda tem sete etapas — recebimento, identificação do cliente, conferência de itens e preço, checagem de estoque e limite de crédito, lançamento no ERP (o sistema de gestão onde a empresa registra pedido, estoque, preço e faturamento), emissão da nota e retorno ao cliente. Elas caem em três grupos: regra determinística, leitura de documento e decisão humana. Só o recebimento por canal não estruturado justifica IA, e a liberação comercial é a etapa que não deve ser automatizada.

O critério cabe em uma frase: é regra quando o dado já existe em campo definido e a decisão cabe em política escrita; é leitura quando o dado está preso num texto ou PDF feito para olhos humanos; é humano quando falta alguém assumir a decisão, não informação.

Essa lista é a versão genérica. A sua empresa tem a dela, com exceções próprias — cliente com tabela especial, item que só sai por encomenda, representante que manda pedido em dois blocos —, e elas aparecem no mapeamento do processo. A lógica geral está em automação de processos.

O canal de chegada é o gatilho: WhatsApp, e-mail, planilha do representante e marketplace

O canal define o tratamento. Quatro canais comuns, quatro trabalhos diferentes:

• Texto livre no WhatsApp: não estruturado. O cliente escreve como fala, mistura item e observação na mesma frase e corrige o pedido na mensagem seguinte.
• PDF anexado em e-mail: muitas vezes a ordem de compra do próprio cliente, com layout diferente para cada cliente e nenhuma garantia de que o próximo virá igual.
• Planilha do representante: semiestruturada. Tem colunas, mas cada representante monta a sua, e a coluna "obs" costuma guardar informação que muda o preço.
• Arquivo de marketplace ou EDI — Electronic Data Interchange, troca eletrônica de dados, o conjunto de padrões que grandes redes usam para enviar pedido: é o único canal que costuma chegar estruturado, com layout documentado e versão definida.

Quando não precisa de IA: arquivo com colunas fixas, código de produto já padronizado, integração de marketplace com campos nomeados. Ler isso é regra, e contratar IA aqui é pagar caro por uma leitura que um programa faz sem inferência nenhuma.

Quando precisa: texto corrido sem formato, PDF sem padrão, produto descrito pelo nome comercial ou pelo apelido que aquele cliente usa, quantidade escrita por extenso ou em unidade diferente da do cadastro — caixa, fardo, milheiro.

Uma distinção que evita orçamento inflado: OCR só entra quando o PDF é imagem escaneada, porque PDF gerado por sistema já traz camada de texto. A IA entra na etapa seguinte — decidir o que naquele texto é item, o que é quantidade e o que é observação. O critério completo entre entrada estruturada e não estruturada está em IA na automação de processos.

E o ponto de entrada precisa ser um só — um número de WhatsApp da central de pedidos, uma caixa de e-mail dedicada, uma pasta onde o representante deposita a planilha. Pedido que chega por três lugares não tem gatilho, e o que não tem gatilho não começa sozinho. Os caminhos de captura estão em integração de sistemas.

O problema real não é digitação: casar cliente e produto com o cadastro do ERP

O cliente escreve "Mercado do João" e o ERP tem "J. Silva Comércio de Alimentos LTDA". Identificação confiável exige uma chave: CNPJ, código do cliente ou o número de WhatsApp já vinculado ao cadastro. Nome não é chave — dois clientes se chamam parecido e o mesmo cliente se chama de três jeitos.

O mesmo vale para o item. "Cabo 2,5 flexível azul" precisa virar um código de produto. A saída é a tabela de-para — sinônimo, nome comercial, código que o cliente usa internamente, código de barras — que a empresa vai alimentando conforme os pedidos entram. Ela não nasce pronta, e é patrimônio do projeto: quanto mais completa, menos exceção chega na mão de alguém.

Para cada linha do pedido há três desfechos possíveis: bate com confiança e segue; bate com dúvida entre dois códigos e para para alguém escolher; não bate e para. A automação nunca escolhe por aproximação silenciosa — item errado vira separação errada, entrega errada, devolução e nota cancelada, e esse custo é maior que o da digitação que se queria eliminar.

Cliente novo é caso à parte. Abrir cadastro é decisão com consequência fiscal e de crédito. O que se automatiza é preparar o cadastro com os dados já extraídos e deixá-lo pendente de liberação, não criá-lo sozinho. É o mesmo desenho do Autocadastro, produto que a Projask desenvolveu para escritórios de advocacia, onde o cadastro de processos é montado e validado automaticamente antes de entrar no fluxo.

A inversão útil é essa: a redigitação some rápido e é a parte barata. O de-para é o que dá trabalho, e é ele que decide se o projeto se paga.

O que precisa ser validado antes de o pedido entrar no ERP

São cinco checagens antes do lançamento:

1. Tabela de preço vigente para aquele cliente e aquela data.
2. Desconto dentro da alçada de quem vendeu.
3. Estoque disponível na data prometida.
4. Limite de crédito do cliente.
5. Título vencido em aberto.

Cada uma é consulta a dado já estruturado dentro do ERP — nada disso exige IA. A dificuldade é política, não técnica: qual tabela vale para esse cliente, quem pode dar quanto de desconto, o que fazer com pedido parcial quando falta estoque de um item e sobra dos outros.

Tolerância e exceção precisam ser decididas antes do código: arredondamento de preço, frete, quantidade mínima por embalagem, cliente com acordo comercial fora da tabela. São decisões de negócio, e quem responde por elas é a área comercial, não quem escreve a automação.

O desfecho de uma validação que falha não é bloqueio mudo. O pedido para numa fila, com o motivo escrito e o responsável certo — o mesmo desenho da fila de divergência do contas a pagar, com a análise já feita esperando decisão.

O ganho aparece antes mesmo do lançamento: pedido que entra já validado reduz o retrabalho de crédito suspenso na véspera do faturamento, entrega cancelada e nota reemitida.

Lançar o pedido no ERP: API, importação de arquivo, banco e, por último, robô de tela

A ordem é a de sempre: API documentada, importação por arquivo que o próprio ERP já aceita, acesso ao banco de dados e, no fim da fila, o robô de tela. No pedido de venda a importação por arquivo sobe na lista, porque gravar direto na base é mais arriscado aqui do que num título a pagar.

Importação de pedido por arquivo aparece com frequência em ERP nacional e é quase sempre subestimada. Vale confirmar com o fornecedor se o recurso já faz parte do que a empresa licenciou, porque em parte dos casos ele está ali e ninguém usa.

O alerta sobre a base é o seguinte: salvar um pedido de venda pela tela ou pela API costuma disparar reserva de estoque, cálculo de imposto e aplicação da regra de preço. Escrever direto na tabela pula essas rotinas, e reconstruí-las por fora costuma sair mais caro do que continuar digitando.

Idempotência é o ponto que ninguém pede e todo projeto precisa: reconhecer que aquele pedido já foi lançado antes de lançar de novo. Reprocessar uma mensagem de WhatsApp não pode gerar pedido em duplicidade, e para isso é preciso uma chave — número do pedido do cliente, número da ordem de compra ou uma assinatura calculada sobre a própria mensagem.

O que perguntar ao ERP antes de pedir orçamento:

1. Aceita pedido com item que ainda não existe no cadastro, ou exige cadastro prévio?
2. Devolve o número do pedido gerado? Sem ele, o retorno ao cliente vira busca por aproximação.
3. Permite gravar pedido bloqueado, aguardando liberação?
4. Respeita a tabela de preço na importação ou aceita o preço que vier no arquivo?

O mapa dos caminhos está em integração de sistemas; quando a tela é mesmo a única saída, o que isso cobra depois está em o que é RPA; e o degrau escolhido é o que move o preço, como detalha quanto custa automatizar um processo.

O que continua humano — e o que automatizar ao redor disso

Três decisões ficam com gente: liberar crédito para cliente no limite ou com título vencido, negociar desconto e prazo, e aprovar pedido fora da política comercial.

A distinção útil é essa: aplicar desconto já previsto em tabela, para quem tem alçada, é regra. Decidir vender para quem está devendo é julgamento, e julgamento tem dono.

Ao redor da decisão há bastante coisa automatizável: fila por alçada, notificação de quem está travando o pedido, prazo de resposta visível e registro de quem liberou, quando e com base em qual informação.

Liberação automática de crédito sem política escrita transfere para o software um risco que é do sócio. Na prática, o primeiro bloqueio indevido numa venda boa — ou o primeiro calote liberado — custa mais do que o tempo que se economizou, e a discussão volta para o começo.

Faturamento e retorno: a confirmação ao cliente é etapa do processo, não cortesia

Emitir a nota a partir de um pedido já validado é regra dentro do ERP: preço, item, cliente e condição já estão conferidos. O que a validação comercial não garante é a parte fiscal — CFOP, regime tributário, situação cadastral do destinatário e a autorização da SEFAZ, que só acontece no momento da transmissão.

Por isso a nota rejeitada precisa de tratamento explícito no desenho: volta para uma fila com o código de rejeição legível, não some. Sem isso, o pedido fica marcado como faturado e ninguém percebe que a nota não saiu.

O passo seguinte é o que costuma faltar. Sem confirmação, o cliente reenvia o pedido pelo mesmo canal para saber se chegou e o representante liga para o interno perguntando — exatamente o trabalho manual que o projeto queria tirar do caminho.

O que a confirmação precisa dizer:

• Número do pedido no ERP.
• Itens aceitos.
• Itens que ficaram pendentes e por quê.
• Preço aplicado.
• Previsão de faturamento.

O mesmo caminho serve de volta quando a nota sai: número da nota e chave de acesso, no canal em que o pedido chegou — e, quando a empresa já tem rastreio integrado com a transportadora, também o status de entrega.

Quando automatizar a entrada de pedidos não se paga

Não existe número universal de volume. Quando entram poucos pedidos por mês, sempre dos mesmos clientes e sempre no mesmo formato, o tempo economizado não cobre a construção nem a manutenção.

Outros sinais de que não é hora:

• Pedido sempre negociado caso a caso, com preço e prazo definidos na conversa.
• Catálogo instável, com item entrando e saindo toda semana — o de-para nunca estabiliza.
• Cadastro de cliente e de produto bagunçado; a automação só acelera a bagunça.
• Troca de ERP prevista para os próximos meses.

A automação parcial que costuma valer primeiro é só a conferência e a validação: o pedido chega, é lido, casado com o cadastro e checado contra preço, estoque e crédito, e alguém lança um pedido que já veio pronto. Não toca no ERP, é a parte barata e a que menos depende do sistema.

A segunda parcial possível é automatizar só o canal estruturado — marketplace, EDI, planilha padronizada — e deixar WhatsApp e PDF na mão por enquanto.

Quando nem isso se paga, o caminho é padronizar o canal e a planilha de pedido, tratado em quando a planilha deixa de ser suficiente, com a conta em quanto custa automatizar um processo.

Se quiser uma leitura do seu caso, descreva pelo WhatsApp quantos pedidos entram por mês, por quais canais eles chegam e qual ERP está em uso. A análise começa por aí — e às vezes termina em "ainda não vale a pena".