preço, poder e panela

Todo consultor de CPQ já passou pela cena: o cliente pergunta por que o desconto de 15% não gerou o valor que ele esperava na linha, e a resposta educada é sempre a mesma, depende de quantos estágios o preço atravessou antes de chegar até ali. O Pricing Waterfall é exatamente esse mapa. Ele não é conceito de MBA de pricing, é estrutura literal de campos na Quote Line, e quem não conhece o caminho completo do List Price até o Net Price vai gastar tempo procurando bug onde só existe configuração.

O que torna esse post relevante agora é o momento de transição. Empresas que ainda vivem no CPQ clássico têm um conjunto de estágios bem conhecido, quase folclórico entre quem implementa. Mas o Revenue Cloud, com Pricing Procedures, reescreve boa parte dessa lógica com mais flexibilidade e, também, mais superfície pra errar configuração. Entender os dois modelos lado a lado é o tipo de conhecimento que separa quem sabe rodar um desconto simples de quem sabe desenhar uma estratégia de pricing inteira.

A série ganha força justamente por isso: não trata o waterfall como curiosidade acadêmica, trata como ferramenta de diagnóstico. Quando você sabe nomear cada degrau, fica muito mais fácil isolar em qual etapa o número saiu do trilho.

Esse post é complemento direto do anterior, e junto eles formam a dupla mais útil da semana pra quem vive no chão de fábrica do Revenue Cloud. A lista de sintomas é dolorosamente familiar: conta com contrato ativo volta pro preço de lista sem motivo aparente, rep edita desconto manualmente e o total simplesmente não move, quote calcula um valor e order calcula outro pra mesma linha. Cada um desses casos tem explicação técnica específica, e o post entrega o roteiro pra achar essa explicação antes de virar chamado.

O ponto que mais me interessa aqui é o reposicionamento do problema. A tentação natural é tratar divergência de preço como falha do produto. Na prática, na enorme maioria dos casos, é a pricing procedure obedecendo fielmente a uma sequência de elementos que alguém configurou sem prever aquele cenário de negócio. Isso muda completamente a postura de troubleshooting: em vez de esperar patch da Salesforce, você audita seus próprios elementos de pricing.

Pra quem arquiteta esse tipo de solução, o recado é indireto mas claro. Cada elemento novo na pricing procedure é um ponto de decisão que precisa ser documentado com a mesma disciplina que se documenta uma regra de aprovação. Sem isso, o próximo arquiteto que herdar o org vai gastar o dobro do tempo reconstruindo o raciocínio que já existiu um dia.

É fácil ler essa notícia como curiosidade de setor público e seguir adiante. Erro. O IL5 é o tipo de autorização que só existe porque alguém provou, em detalhe auditável, que dado sensível não sai do perímetro, que cada ação do agente é rastreável e que existe controle de acesso granular o suficiente pra satisfazer um órgão que não perdoa falha. Isso é, essencialmente, a versão mais rigorosa possível do que qualquer arquiteto de Agentforce deveria estar tentando implementar em ambiente corporativo comum.

O combo com o Army Human Resources Command, do outro destaque da semana, reforça o padrão. Não é sorte nem coincidência dois cases de Agentforce em setor de defesa aparecerem na mesma janela. É estratégia deliberada da Salesforce de usar o ambiente mais hostil possível pra prova de conceito de governança, e depois trazer esse desenho pra baixo, pra clientes comerciais que não têm a mesma exigência regulatória mas deveriam ter a mesma disciplina.

O que fica de lição prática: Zero Copy não é feature de marketing, é decisão arquitetural que evita duplicação de dado sensível e reduz superfície de ataque. Se o padrão aguenta ambiente classificado, aguenta tranquilamente o seu org de vendas ou de atendimento. A pergunta que cada arquiteto devia se fazer é se o desenho de permissão do agente na sua implementação resistiria, ainda que de forma simplificada, ao mesmo tipo de auditoria.

Durante anos, a régua de maturidade de integração Salesforce foi expor cada API como uma tool isolada e deixar o consumidor decidir a orquestração. O Headless 360 MCP Server inverte essa lógica. Em vez de mil tools específicas, quatro operações abstratas que permitem ao agente descobrir o que existe, entender o que cada coisa faz, executar e, quando precisa, só ler sem mutar nada. Na prática, é dar ao agente autonomia pra navegar o Setup como um administrador navegaria, sem que alguém tenha escrito automação específica pra cada clique.

O detalhe que merece atenção de arquiteto é o recorte de permissão. Dispatch Read Only existe justamente porque alguém, lá dentro do time de produto, entendeu que nem toda ação de agente deveria ter poder de escrita. Isso é o tipo de guardrail que separa ferramenta madura de brinquedo perigoso. Só que a existência do guardrail não resolve o problema de quem configura o perfil, a permission set e o escopo do agente que vai usar essas skills, isso continua sendo trabalho humano, e trabalho que exige cuidado redobrado.

O impacto de médio prazo é que times de administração vão precisar repensar completamente o que significa "dar acesso ao Setup". Hoje isso é sinônimo de perfil e permission set pra humano. Em pouco tempo, vai significar também definir com precisão quais skills um agente pode disparar, em qual ambiente, e com qual nível de log. Quem trata isso como detalhe técnico menor vai ser pego de surpresa quando o primeiro incidente de agente com permissão errada aparecer.