Toda implementação de CPQ começa com a mesma promessa: o preço certo, para o cliente certo, no momento certo. A realidade que encontro nas auditorias costuma ser bem diferente.
Regras de preço que ninguém sabe explicar. Um Quote Calculator Plugin com centenas de linhas de JavaScript que "o dev que fez saiu da empresa". Descontos que o sistema aprova automaticamente sem verificar se a margem está positiva. Vendedores que sabem que existe um campo de "preço manual" que bypassa tudo — e que usam isso com frequência porque confiar no preço do sistema se tornou arriscado.
Isso é Dynamic Pricing mal implementado. E o custo não aparece em nenhum relatório do Salesforce — ele aparece na reconciliação mensal, na conta que fechou abaixo da margem mínima, na proposta que saiu com preço que ninguém conseguia explicar de onde veio.
O que é Dynamic Pricing no CPQ e como funciona
Dynamic Pricing é o conjunto de mecanismos que fazem o preço mudar dinamicamente com base em variáveis de negócio — volume, segmento do cliente, canal, moeda, combinação de produtos, data da proposta, maturidade da conta, entre outros.
No Salesforce CPQ, isso se materializa de diversas formas:
Price Rules e Price Actions: O motor declarativo do CPQ. Uma Price Rule define uma condição (se o produto X está na quote E o segmento do cliente é Y); uma ou mais Price Actions definem o que acontece quando a condição é verdadeira (aplica desconto de 10%, sobrescreve o preço com um valor fixo, ativa uma Discount Schedule). A lógica é sequencial e pode se tornar muito complexa com muitas regras ativas ao mesmo tempo.
Quote Calculator Plugin (QCP): Código JavaScript que roda no motor de cálculo do CPQ. O QCP foi projetado para lógica que Price Rules não conseguem expressar — cálculos matemáticos complexos, lógica condicional avançada, chamadas externas. É poderoso e, por isso, perigoso: código sem boas práticas de documentação e teste vira um sistema crítico que ninguém consegue manter.
Discount Schedules: Tabelas de desconto por volume ou bloco. Quando configuradas corretamente, são elegantes — o preço cai conforme o volume aumenta, de forma controlada. Quando configuradas de forma inconsistente entre produtos ou com sobreposição de regras, geram preços que ninguém consegue prever.
Rampas de Subscription Pricing: Para contratos com preço crescente ao longo do tempo — o que é muito comum em SaaS B2B. O primeiro ano custa X, o segundo X+10%, o terceiro X+20%. Quando mal configurado, as rampas geram surpresas desagradáveis na renovação.
Contracted Prices e Account-specific Pricing: Preços negociados individualmente para uma conta, que sobrescrevem a tabela padrão. Quando não são revisados periodicamente, podem estar ativos muito além do prazo previsto — concedendo descontos que já não fazem sentido comercial.
Por que a lógica de preço vira um problema ao longo do tempo
Um projeto de CPQ começa com uma arquitetura de precificação relativamente limpa. Com o tempo, ela acumula camadas:
A equipe comercial muda e pede novas regras. Um produto novo entra com uma lógica de preço diferente. Um segmento especial recebe uma Discount Schedule customizada. O dev que implementou o QCP saiu e o substituto adicionou lógica nova sem entender bem o que já existia. Uma integração com o ERP trouxe preços de fora que conflitam com os configurados internamente.
Cada uma dessas adições parecia razoável isoladamente. O problema é que ninguém estava gerenciando o todo — e as Price Rules passaram a interagir de formas não planejadas.
O sinal mais claro de que isso aconteceu: quando você cria uma cotação de teste e o preço que sai é inesperado, e ninguém consegue explicar por qual caminho de regras o sistema chegou naquele número.
Os cinco problemas mais comuns que encontro em auditorias de precificação
1. Price Rules com ordem de avaliação incorreta ou não documentada
No CPQ, quando múltiplas Price Rules se aplicam a um produto, elas são avaliadas em sequência e podem se sobrescrever. Se a ordem estiver errada — por exemplo, uma regra de desconto de volume sendo sobrescrita por uma regra de preço base que vem depois — o desconto some silenciosamente. E como o vendedor não sabe qual preço é o "correto", ele aceita o que aparece.
2. QCP com lógica proprietária e sem documentação
O Quote Calculator Plugin é o componente mais poderoso e mais perigoso do CPQ. Quando bem implementado, com comentários, testes e documentação do que cada função faz, é um ativo da empresa. Quando implementado às pressas, sem documentação, por alguém que já saiu, é um passivo — ninguém quer tocar porque qualquer mudança pode quebrar algo que ninguém sabe que está acontecendo.
3. Descontos sem teto de margem
Vendedores têm poder de oferecer desconto, e Approval Processes controlam até onde eles podem ir sozinhos. O problema é quando o Approval Process não está validando o impacto na margem — só o percentual de desconto. Um desconto de 20% sobre um produto de alta margem é completamente diferente de um desconto de 20% sobre um produto de margem fina. Se o sistema trata os dois da mesma forma, ele está concedendo um vira-mão na rentabilidade.
4. O escape do preço manual
Toda implementação de CPQ que conheço tem um campo de "Additional Discount" ou "Manual Price Override". Ele existe para casos legítimos — um desconto negociado fora do processo padrão que precisa ser registrado. O problema é quando esse campo vira o caminho padrão porque o preço calculado não é confiável. Quando você monitora qual porcentagem das quotes tem preço manual, o número costuma ser revelador.
5. Contracted Prices desatualizados
Preços contratuais negociados para contas específicas não têm prazo de validade automático no CPQ. Uma empresa que negociou um preço especial em 2022 pode ainda estar recebendo esse preço em 2025, sem que ninguém perceba — porque o sistema continua aplicando e nenhuma regra sinaliza que o contrato negociado expirou.
Como conduzir uma auditoria de precificação no Salesforce CPQ
Uma auditoria de precificação não é um projeto de uma semana. Mas tem uma estrutura clara:
Etapa 1 — Inventário completo (1-2 semanas)
Levantamento de todas as Price Rules ativas: nome, condição, ação, ordem de avaliação, data de criação, quem criou. Mesmo Price Rules "ativas" que você não reconhece precisam ser investigadas — podem estar interferindo sem que ninguém saiba.
Inventário do QCP: quantas funções existem, o que cada uma faz (com base no código, não na documentação — porque provavelmente não há documentação), quais são os pontos críticos.
Mapeamento de Discount Schedules: quais produtos têm, quais contas têm Contracted Prices, quando foram criados.
Etapa 2 — Testes das combinações críticas (1-2 semanas)
Identificar os cenários de configuração mais frequentes na operação real: os 10-20 tipos de quote mais comuns. Criar quotes de teste para cada cenário e validar se o preço calculado é o esperado pela política comercial.
Testar combinações de produtos que raramente são criadas — porque é exatamente nesses que as regras conflitantes aparecem.
Etapa 3 — Validação de controles de margem (1 semana)
Verificar se os Approval Processes estão efetivamente bloqueando quotes que violam a margem mínima. Criar quotes de teste que deveriam ser bloqueadas — elas são bloqueadas?
Verificar o histórico de quotes aprovadas que estavam abaixo da margem aceitável. Quantas existem? Por qual caminho passaram?
Etapa 4 — Remediação e documentação (2-4 semanas)
Com base no inventário e nos testes, criar um mapa completo da lógica de precificação — em linguagem que um administrador Salesforce sem conhecimento de JavaScript consiga entender.
Desativar ou corrigir regras conflitantes. Adicionar comentários ao QCP. Criar testes automatizados para os cenários críticos. Implementar monitoramento de quotes com preço manual acima de um threshold.
O que muda depois de uma auditoria bem feita
A mudança mais imediata e mensurável: os vendedores passam a confiar no preço do sistema. Isso é mais importante do que parece — quando há confiança, o preço manual deixa de ser o escape padrão, e a governança de precificação começa a funcionar de verdade.
No médio prazo: margem protegida por controles que realmente funcionam, capacidade de adicionar novos produtos e regras de preço sem medo de quebrar o que existe, e uma base documentada que qualquer administrador consegue manter.
Perguntas frequentes sobre precificação no Salesforce CPQ
O que é o Quote Calculator Plugin (QCP) no Salesforce CPQ?
O QCP é um arquivo JavaScript que roda dentro do motor de cálculo do CPQ, permitindo lógica de precificação mais complexa do que Price Rules declarativas conseguem expressar. É executado em três momentos: antes do cálculo, durante o cálculo de cada linha, e após o cálculo. Quando bem implementado, é poderoso; quando sem documentação, vira um risco operacional.
Como as Price Rules interagem entre si no CPQ?
Price Rules são avaliadas em sequência, na ordem definida pelo campo "Evaluation Order". Price Actions de regras posteriores podem sobrescrever as anteriores. Isso significa que a ordem importa — e que regras criadas sem verificar a ordem existente podem silenciosamente neutralizar regras anteriores.
Como proteger a margem na configuração de aprovações de desconto no CPQ?
A abordagem mais robusta combina: campos de margem calculada na Quote (percentual de margem por linha e total), Approval Process que verifica o campo de margem — não apenas o percentual de desconto — e um alerta visual para o vendedor quando a margem está abaixo do threshold aceitável antes mesmo de submeter para aprovação.
Com que frequência deve ser feita uma auditoria de precificação no CPQ?
Toda vez que há mudança significativa na política comercial, adição de novos produtos ou segmentos, ou mudança na equipe responsável pela configuração do CPQ. Como manutenção preventiva, anualmente é uma boa cadência para orgs com lógica de precificação moderadamente complexa.
É possível ter precificação dinâmica no CPQ sem usar o QCP?
Sim — Price Rules e Price Actions cobrem a maioria dos cenários de Dynamic Pricing. O QCP deve ser reservado para lógica que realmente não é possível expressar de forma declarativa: cálculos matemáticos complexos, chamadas a APIs externas para busca de preço em tempo real, ou manipulação de dados que Price Rules não alcançam.
