Sete perguntas que separam as arquiteturas de comércio B2B

A cena se repete em quase todo comitê de seleção. A planilha comparativa tem duzentas linhas, cinco fornecedores em colunas, e quase todas as células dizem “sim”. Preço por cliente: sim. Aprovação de desconto: sim. Multi-armazém: sim. Integração com ERP: sim. No fim da reunião, a decisão acaba saindo por preço de licença ou por simpatia com o time de vendas, porque a planilha não separou ninguém.

A planilha não separou porque a pergunta estava errada. “Você faz preço por cliente” é uma pergunta que toda plataforma responde com sim, e cinco arquiteturas completamente diferentes cabem dentro desse sim. Uma calcula o preço no momento em que a tela é montada. Outra lê uma tabela que foi sincronizada de madrugada. As duas marcam a mesma célula, e a diferença entre elas aparece dezoito meses depois, na forma de um time comercial que voltou a fechar pedido por WhatsApp.

O que separa arquiteturas de comércio B2B é uma coisa só, e ela não costuma estar na planilha: onde mora a regra comercial. Dentro da plataforma, onde ela é editável e executada no ato, ou fora dela, num sistema de origem que precisa ser consultado, sincronizado ou reimplementado a cada mudança.

As sete perguntas abaixo servem para expor isso antes da assinatura. Elas não são um checklist para pontuar fornecedor. São sete lugares onde uma resposta vaga custa caro depois, e onde uma resposta boa é reconhecível na hora.

1. O preço do seu cliente é um dado guardado ou o resultado de uma função?

Esta é a pergunta que mais separa, e é a que mais recebe sim de todo mundo.

Em comércio B2B o preço quase nunca é um valor armazenado. Ele é o resultado de uma função cujas entradas são a identidade do comprador, o armazém que atende, o volume, o prazo, a forma de pagamento, a origem da mercadoria e a regra fiscal que se aplica àquela combinação. Uma plataforma que trata preço como um campo precisa de uma linha na tabela para cada combinação possível, e as combinações crescem em produto, não em soma.

O que acontece quando isso não cabe é previsível e raramente é registrado como decisão: a empresa achata a política de preço. Nivela a tabela porque manter preço diferente por filial cruzado com preço por cliente virou impossível de administrar. É um contorno técnico que se disfarça de simplificação comercial, e ele entrega margem de antemão em todo cliente que pagaria mais, além de perder o negócio em todo cliente que precisaria de um preço abaixo da tabela achatada. Não existe relatório que mostre o preço que se deixou de cobrar.

Uma boa resposta soa assim: o preço é calculado no momento da exibição, a partir das entradas, com uma hierarquia declarada de quem vence quem (contrato acima de regra, regra acima de tabela).

Um sinal de alerta soa assim: “a gente sincroniza a tabela de preços do ERP a cada quatro horas”. Isso não é uma resposta sobre preço, é uma resposta sobre latência.

2. Quem edita a regra comercial, e em quantos dias?

Qualquer ERP consegue representar uma regra de preço complexa. O gargalo nunca foi representar. O gargalo é distribuir essa regra para centenas de vendedores e milhares de compradores sem treinar todo mundo no ERP, e mudá-la quando o mercado muda.

Se cada ajuste de política comercial abre um chamado de TI, a política comercial passa a andar na velocidade da fila de TI. Na prática, ela para de andar. A área comercial aprende que pedir mudança não compensa, e passa a operar por exceção manual, que é a mesma coisa que não ter política.

Uma boa resposta soa assim: quem edita é uma pessoa de negócio, na mesma semana, sem publicação de código, e existe registro de quem mudou o quê.

O teste que vale mais que a resposta: peça, na demonstração, para criarem uma regra nova na sua frente. Não uma regra que já existe no ambiente de demonstração, uma que você inventa na hora. É notável quantas demonstrações não sobrevivem a esse pedido, e é notável quantas vezes ele simplesmente não é feito.

3. Qual é a unidade de configuração: a empresa ou o armazém?

A maioria das plataformas configura no nível da empresa, e trata filial, centro de distribuição e loja como atributos de entrega. Isso funciona enquanto a operação é homogênea, e quebra no primeiro momento em que duas unidades da mesma empresa têm realidades comerciais diferentes, o que em distribuição é a regra e não a exceção.

Uma unidade que atende outra região tem outro custo de frete, outro prazo, outro mix, às vezes outra tributação, e frequentemente outro teto de desconto. Se a unidade de configuração é a empresa, tudo isso vira exceção, e exceção em volume vira trabalho manual.

Uma boa resposta soa assim: a unidade de configuração é a menor unidade que tem realidade comercial própria, e ela carrega catálogo, preço, região, logística, pagamento, crédito e alçada próprios, dentro do que a configuração central permite. Descentralizar a configuração sem perder a governança é o ponto, e as duas metades dessa frase importam igualmente.

4. O que acontece quando dois descontos se encontram?

Toda plataforma tem desconto. Poucas têm uma resposta para o encontro de dois.

O vazamento de margem em B2B raramente vem de um desconto grande, que seria visível. Vem do empilhamento de descontos pequenos, cada um legítimo isoladamente, que se somam sem que ninguém tenha aprovado a soma. Some a isso a aprovação informal, em que cada gerente aprova de um jeito e nada fica registrado, e a margem líquida se descola da bruta sem que exista um relatório capaz de mostrar onde.

Vale também perguntar sobre prazo. Desconto e prazo são a mesma moeda numa negociação real, e são conversíveis um no outro. O vendedor que só pode mexer no desconto tem uma alavanca, e vai usá-la até o limite. Dar as duas alavancas dentro de guarda-corpos costuma ser o jeito mais barato de proteger margem.

Uma boa resposta soa assim: existe bloqueio preventivo antes do envio do pedido, e não só aprovação depois; existe alçada em níveis; e toda exceção grava o motivo, de forma que a auditoria seja uma consulta e não um projeto.

5. O checkout aceita como o seu cliente realmente paga?

Pagamento B2B é um serviço financeiro, não um formulário de cartão. Prazo de trinta, sessenta ou noventa dias, limite de crédito usado como meio de pagamento, permuta, divisão entre vendedores diferentes no mesmo pedido. Uma plataforma que trata o checkout como o passo final de um fluxo de varejo transforma todo o esforço anterior em desperdício, porque a negociação morre exatamente no fechamento.

Aqui a pergunta tem uma segunda metade, que quase ninguém faz: o crédito é consultado no ato, ou é uma informação que veio da última sincronização? Um limite de crédito desatualizado é pior que ausência de limite, porque ele autoriza o que deveria barrar.

Uma boa resposta soa assim: o crédito entra no pedido como um produto transacional governado por regra, avaliado no momento do fechamento, e não como um favor negociado por telefone depois.

6. O estoque que a tela mostra é o estoque que existe?

Sistemas de registro operam em lote. O front comercial opera em tempo real. Quando a verdade do primeiro chega ao segundo com uma janela de horas, o comprador descobre o erro no pior momento possível, que é depois de ter decidido comprar. O efeito não aparece como reclamação, aparece como retorno silencioso ao telefone, e o canal digital vira métrica de vaidade sem que ninguém saiba explicar por quê.

A pergunta tem uma continuação que separa ainda mais: o que a plataforma faz quando o estoque zera? Encerrar a venda é a resposta comum. Rotear para outro armazém, inclusive o de um fornecedor parceiro, sem que o comprador precise saber, é a resposta que transforma ruptura em venda adiada em vez de venda perdida. Sortimento limitado por capital de giro é uma escolha de arquitetura antes de ser uma escolha financeira.

7. Quando a IA entrar, quanto custa cada decisão?

Esta é a pergunta mais nova, e é a que nenhum comitê de seleção está fazendo ainda. Quem a fizer agora vai economizar bastante em dois anos.

Todo fornecedor demonstra IA hoje, e as demonstrações funcionam. O que não aparece na demonstração é o custo por decisão quando aquilo é ligado para a operação inteira. Sem uma camada determinística que resolva regra de negócio antes do modelo, toda decisão trivial vira inferência paga. O piloto fecha a conta com dez usuários e não fecha com trezentos, e o projeto vira prova de conceito eterna.

Medimos isso na nossa própria operação, e o número é o motivo desta pergunta existir na lista: em doze dias e 2.151 chamadas de modelo, o custo médio ficou em US$ 0,0193 por chamada, com variação de sessenta vezes entre os tipos de tarefa. A tarefa mais cara custou setenta vezes a mais barata. Numa operação hipotética de cinquenta vendedores com vinte atendimentos diários, projetando esses custos sem uma camada determinística embaixo, a inferência sozinha passa do valor da licença por usuário em muitas operações.

Uma boa resposta soa assim: a maior parte das decisões nunca chega ao modelo, porque preço, estoque, alçada e catálogo são resolvidos por regra; o modelo é chamado para o que é ambíguo, e há medição de custo por tipo de tarefa.

Um sinal de alerta soa assim: um número de licença de IA por usuário, sem nenhuma conversa sobre o que gera chamada.

Como a CWS Platform responde a essas sete

Este é o blog da CWS Platform, então a resposta honesta é que as sete perguntas acima descrevem a arquitetura que a CWS escolheu, e é natural que ela se saia bem no próprio questionário. O leitor deve descontar isso na leitura.

O resumo é curto. A CWS trata preço como função e não como tabela, configura no nível do armazém, expõe a regra comercial em 1.029 parâmetros editáveis por gente de negócio sem publicação de código, e coloca uma camada determinística entre a operação e o modelo de linguagem. São 11 módulos e 6 AI Agents, e a tese que sustenta todos eles é que o produto não é uma loja online, é uma plataforma de negociação.

E o mais útil, que é onde a CWS não é a resposta: operação de preço fixo, catálogo estável e pouca negociação não precisa de nada disso. Nesse cenário, plataformas de comércio mais simples resolvem melhor e por menos dinheiro, e a complexidade da CWS Platform vira custo sem contrapartida. As sete perguntas acima só valem a pena para quem responde “depende” à maioria delas. Quem responde “é sempre igual” está diante de um problema diferente.

O que fazer com essas sete perguntas

Leve-as para a próxima demonstração e faça a de número 2 primeiro, porque ela é a que menos aceita resposta ensaiada. Peça para criarem uma regra nova na sua frente. O que acontecer nos dez minutos seguintes vai dizer mais sobre a arquitetura do fornecedor do que as duzentas linhas da planilha comparativa.

Perguntas frequentes

Essas perguntas servem para B2C também? Parcialmente. As de número 6 e 7 valem para qualquer operação. As de 1 a 5 tratam de negociação, alçada e crédito, que são características de comércio entre empresas. Em B2C, onde o preço é o mesmo para todo mundo, a maior parte delas perde sentido.

Já assinamos com um fornecedor. As perguntas ainda servem? Servem, e provavelmente rendem mais agora. Feitas depois do contrato, elas viram um diagnóstico de onde a sua operação está pagando em trabalho manual o que a arquitetura não resolve. Isso é útil na renovação e é útil para decidir o que integrar por fora.

Por que preço aparece em primeiro lugar? Porque é a pergunta cuja resposta errada é mais cara e mais silenciosa. Achatar a política de preço para caber no sistema não gera incidente, não gera reclamação e não aparece em nenhum relatório. É a única das sete cujo custo é invisível por construção.

Existe uma resposta certa para todas? Não. Existem respostas caras e baratas para o seu caso específico. Uma operação com um armazém e uma política de preço não precisa da resposta sofisticada da pergunta 3, e pagaria por complexidade que não usa. O objetivo das sete é fazer o custo aparecer antes do contrato, não eleger um vencedor.

Uma publicação da CWS Platform.