Alguns contatos do atendimento comercial (por exemplo, vendedores que atendem uma carteira com 15 empresas-cliente) mandavam pedidos via WhatsApp ou e-mail, e o BORDER criava o pedido com o nome correto do cliente na tela do operador — mas gravava o código SAP de outra empresa da carteira. Resultado: ao enviar ao SAP, o faturamento sairia para o cliente errado.
Em auditoria dos pedidos ativos, encontramos 2 casos críticos já aprovados, além de outros em rascunho com a mesma divergência. Nenhum chegou a ser faturado em produção, mas o padrão era consistente e sistêmico.
Quando um contato tem mais de uma empresa vinculada, o BORDER precisa saber para qual delas o pedido atual deve ser lançado. Duas coisas estavam acontecendo em conjunto:
1. O assistente recebia uma dica de qual era a empresa "padrão" da carteira e, se o cliente não dizia o nome da empresa na primeira mensagem, assumia essa padrão silenciosamente — em vez de perguntar.
2. Quando o pedido era enviado por anexo (PDF de ordem de compra), o assistente extraía o nome da empresa compradora do documento para mostrar ao operador, mas a gravação do código SAP continuava usando a empresa que já havia sido pré-selecionada. Os dois campos — o nome visível e o código que vai ao SAP — seguiam caminhos independentes e não eram cruzados.
Resultado: tela mostrava "CLIENTE A", pedido ia para "CLIENTE B" no SAP, porque ambos estão na mesma carteira do vendedor.
Camada 1 — o assistente pergunta. Reforçamos a instrução para o assistente: quando o contato tem 2 ou mais empresas vinculadas, ele é obrigado a identificar explicitamente a empresa antes de criar o pedido. Isso pode ser pelo nome citado pelo cliente (com match claro na carteira) ou por escolha numerada. Usar a empresa padrão sem confirmação está agora proibido.
Camada 2 — o contexto não sugere mais padrão. Removemos do contexto apresentado ao assistente a frase "Empresa padrão: X". Antes, essa sugestão acabava funcionando como caminho de menor atrito — o assistente escolhia por ela quando o cliente não identificava. Agora o contexto só apresenta a lista da carteira e pede que o assistente aguarde escolha explícita.
Camada 3 — conferência automática antes de salvar. No momento de gravar o pedido, o BORDER confere se o nome da empresa extraído (da conversa ou do documento) bate com o cadastro do código SAP que seria usado. Se não bater, ele procura na carteira do contato e, se achar exatamente uma empresa cujo nome bate com o que foi extraído, corrige automaticamente o código. Se não achar ou achar mais de uma, aborta o envio e obriga o assistente a pedir confirmação explícita ao cliente.
| Situação | Comportamento antes | Comportamento agora |
|---|---|---|
| Cliente envia PDF identificando a empresa ("pedido para CORR PLASTIK") | Pedido ia para a empresa padrão da carteira | Identifica CORR PLASTIK no documento e usa o código correto |
| Cliente apenas diz "quero fazer um pedido" sem mencionar a empresa | Pedido ia para a empresa padrão silenciosamente | Assistente pergunta qual empresa antes de prosseguir |
| PDF menciona um nome ambíguo que pode corresponder a mais de uma empresa da carteira | Escolhia uma das possibilidades sem confirmar | Bloqueia o envio e pede confirmação explícita |
| PDF menciona uma empresa que não está na carteira do vendedor | Silenciosamente usava outra empresa qualquer | Aborta e lista a carteira para o cliente escolher |
Situacao: Vendedores que atendem múltiplas empresas tinham
pedidos gravados na empresa padrão da carteira em vez da empresa que o cliente
queria. A tela mostrava o nome correto, mas o código SAP apontava para outra
empresa — risco de faturamento equivocado ao enviar ao SAP.
Correcao: Três camadas de defesa foram implementadas: o
assistente agora é obrigado a identificar explicitamente a empresa, o contexto
apresentado ao assistente não sugere mais uma padrão silenciosa, e uma
conferência automática antes de salvar cruza o nome extraído com o código SAP
e corrige ou aborta quando divergem.
Impacto: Pedidos de vendedores multi-empresa passam a ir para
a empresa correta. Casos ambíguos e nomes fora da carteira são bloqueados com
mensagem clara, eliminando o risco de faturamento em cliente errado.