Promoções nativas: o fim do desconto improvisado na cotação
Elegibilidade, canais, empilhamento e objetos próprios, promoção agora tem identidade no modelo de dados.
Winter '27 traz promoções manuais e automáticas para produtos e categorias, com regras de elegibilidade, canais de venda e política de stackability. É uma capacidade poderosa que, sem governança, recria o mesmo risco de margem que existia com desconto manual.
Conteúdo de pré-release: as funcionalidades ainda podem mudar antes da disponibilidade geral, e licenças, permissões e etapas de ativação variam por edição. Separo sempre o que a Salesforce anunciou do que eu consegui observar direto na org.
Todo projeto de CPQ que eu peguei tinha a mesma cicatriz: o desconto que ninguém sabe de onde veio. Alguém digitou 12% numa linha de cotação em 2023, aquilo virou precedente, e três anos depois a margem está corroída sem que exista um único registro explicando a decisão.
Winter '27 ataca isso dando identidade à promoção.
O que mudou
Pricing designers podem criar promoções manuais ou automáticas para produtos e categorias. A elegibilidade pode considerar regras e canais de venda. A política de stackability controla como múltiplas promoções são avaliadas quando incidem sobre a mesma linha. E existem objetos e APIs para administrar promoções dentro das transações.
Por que isso muda o jogo
Promoção deixa de ser um número digitado e passa a ter público, alvo, qualificador, segmento e tier. Três consequências práticas:
- Auditoria. Existe registro do porquê, não só do quanto.
- Reutilização. A mesma promoção atende venda assistida, canal digital e order capture.
- Integração. Com API e objetos próprios, o desconto atravessa o fluxo sem gambiarra.
A decisão de arquitetura que você não pode adiar
RevOps precisa definir desde o início a política de compatibilidade e empilhamento. Essa é a parte que costuma ficar para depois, e é exatamente a que determina se a capacidade vai proteger ou destruir margem. As perguntas que eu faria antes de ligar qualquer promoção em produção:
- Duas promoções elegíveis na mesma linha: somam, a maior vence, ou é erro de configuração?
- Qual a ordem de avaliação quando há promoção de produto e de categoria?
- O que acontece com a promoção num amendment? Ela sobrevive à renovação?
- Existe piso de margem que bloqueia o empilhamento?
Se você não tem resposta para as quatro, ainda não está pronto para ligar promoções.
Como configurar promoções, passo a passo
Esta funcionalidade está em preview no Winter '27, disponível em Lightning Experience nas edições Enterprise, Unlimited e Developer do Revenue Management com licença Revenue Cloud Advanced. Confirme na org que o Product Catalog Management já tem catálogo, categoria e produtos configurados, pois promoções dependem dessa base existente.
- No app Product Catalog Management, confira se há pelo menos um Product Selling Model e Price Book Entry ativos, porque promoção incide sobre linha de preço já configurada.
- No Object Manager, localize Promotion e os objetos relacionados (PromotionMarketSegment, PromotionQualifier, PromotionSegment, PromotionTarget, PromotionTier) para entender a estrutura antes de criar registros.
- Crie um registro de Promotion definindo se ela é manual ou automática, já que esse campo determina se o desconto aparece sozinho na cotação ou exige aplicação do usuário.
- Associe PromotionTarget ao produto ou categoria que receberá o desconto, porque sem alvo definido a promoção não tem onde incidir.
- Configure PromotionQualifier e PromotionSegment para restringir elegibilidade por regra ou canal de venda, evitando que a promoção vaze para público errado.
- Defina a política de stackability no PromotionTier antes de ativar, respondendo se promoções somam, se a maior vence, ou se é erro de configuração quando coincidem na mesma linha.
- Verifique se
AppliedPromotionDateeCouponCodeaparecem em QuoteLinePriceAdjustment e OrderItemAdjustmentLineItem, pois são os campos novos que rastreiam quando e como o desconto foi aplicado.
Como saber que funcionou: abra uma cotação, adicione o produto alvo e confira se a promoção automática aparece na linha ou se a manual pode ser aplicada por cupom, e depois verifique no price waterfall se o desconto aparece com origem clara na Promotion criada, não como valor solto digitado manualmente.
Objetos, campos e o risco de desconto em dobro
O texto oficial confirma a licença exigida e os pontos de dados que sustentam a rastreabilidade da promoção. Antes de ligar qualquer promoção em produção, verifique estes quatro itens na org.
- Esta capacidade se aplica ao Lightning Experience nas edições Enterprise, Unlimited e Developer do Agentforce Revenue Management com a licença
Revenue Cloud Advanced. Sem essa licença, os objetos novos não aparecem no Object Manager. - O objeto
AssetActionSrcPriceAdjustmenté a junção entre o asset e a promoção aplicada a ele. É esse objeto que responde à pergunta que hoje ninguém consegue responder: qual promoção está ativa em qual ativo, e desde quando. - O campo
AppliedPromotionDatefoi adicionado tanto emQuoteLinePriceAdjustmentquanto emOrderItemAdjustmentLineItem. Ele registra data e hora em que a promoção foi aplicada à linha, seja na cotação, seja na ordem. - O campo
CouponCodefoi adicionado nos mesmos dois objetos,QuoteLinePriceAdjustmenteOrderItemAdjustmentLineItem. Ele existe para aplicar promoção manual via código de cupom, e não substitui a promoção automática avaliada por regra de elegibilidade. - O texto oficial confirma que a promoção acompanha o ativo em amendment e renovação, e que o desconto aplicado fica visível no price waterfall e no próprio asset. Isso muda a auditoria de descontos legados, que hoje vivem só na linha da cotação.
O que o texto oficial não detalha é a mecânica interna de avaliação quando duas promoções incidem sobre a mesma linha, nem a interação entre a nova camada de promoção e pricing procedures ou hooks Apex já existentes na org. Trate isso como risco de configuração a validar em sandbox antes de qualquer rollout, não como comportamento documentado.
Fontes oficiais
Desconto vira dado estruturado, auditável e reutilizável entre canais , em vez de um número solto numa linha de cotação.
Toda vez que alguém me pergunta como resolver desconto na cotação, a resposta que eu dava até pouco tempo era sempre um remendo. Fórmula no CPQ, campo customizado, regra de validação tentando impedir que o vendedor zerasse a margem sozinho. Funcionava, mas era gambiarra travestida de solução, porque promoção nunca teve lugar próprio no modelo de dados. Ela vivia emprestada dentro de price rules e lógica de aprovação.
O que muda agora é estrutural, não cosmético. Promoção virou objeto de primeira classe, com elegibilidade, canal e regra de empilhamento tratados como cidadãos do modelo, não como efeito colateral de configuração. Isso importa porque desconto malfeito não é problema de UX, é problema de governança de receita. Quando a regra de negócio mora espalhada em fórmulas soltas, ninguém consegue auditar por que aquele cliente recebeu 15% e o outro não.
Empilhamento é o ponto que separa quem desenhou o recurso de quem só carimbou feature. Definir o que pode combinar com o quê, e em que ordem, é decisão de pricing, não de configuração de tela. Ver isso nativo no Revenue Cloud tira do arquiteto a obrigação de reinventar essa lógica a cada projeto, o que é ganho real de tempo e de consistência entre implementações.
Minha ressalva de sempre: recurso novo bem desenhado não substitui disciplina de descoberta. Se o time de RevOps não mapear antes quais promoções fazem sentido por canal e segmento, vamos só trocar a gambiarra antiga por uma gambiarra nova, só que agora com nome bonito de objeto padrão.
Antes de criar a primeira promoção, sente com o time de pricing e responda uma pergunta que ninguém quer responder de improviso depois: quais promoções podem empilhar entre si e em que ordem elas são avaliadas. Isso não é detalhe de implementação, é regra de negócio que vira modelo de dados.
- Mapeie a política de stackability antes de configurar qualquer coisa. Liste todas as promoções previstas (ou pelo menos as famílias de promoção) e defina explicitamente quais combinam entre si. Documente isso fora do Salesforce primeiro, em uma planilha ou matriz de decisão, porque a conversa com stakeholders de pricing costuma mudar de ideia três vezes antes de fechar.
- Defina a ordem de avaliação com base em impacto financeiro, não em ordem de criação. Promoção de maior desconto avaliada primeiro pode gerar resultado bem diferente de menor desconto primeiro, especialmente quando há regras percentuais compostas. Rode os cenários numéricos antes de assumir que a ordem padrão do sistema resolve.
- Configure elegibilidade de forma restritiva e vá abrindo aos poucos. É mais fácil ampliar critério de elegibilidade do que descobrir em produção que uma promoção se aplicou a um segmento que não deveria.
- Teste explicitamente o comportamento em amendment. Promoção aplicada na cotação original não necessariamente se comporta igual quando o contrato sofre alteração. Valide se ela deve persistir, recalcular ou expirar nesse fluxo, e não deixe essa resposta para quando o cliente já tiver assinado.
- Teste explicitamente o comportamento em renewal. Renovação é outro momento clássico de promoção fantasma, aquela que some ou reaparece sem ninguém entender o motivo. Simule o ciclo completo, não só a cotação inicial.
- Valide o empilhamento com casos de borda reais, não só o caminho feliz. Combine a promoção mais generosa com a mais restritiva e veja se o resultado bate com o que a área de pricing esperava. É nesse teste que aparece a maioria dos problemas de configuração.
Se você pular a etapa de modelagem e for direto para a tela de configuração, o risco não é a promoção não funcionar. É ela funcionar exatamente como configurada, só que ninguém vai lembrar por que aquela regra existe seis meses depois.
- Empilhamento de promoções sem regra de precedência clara vira desconto composto fora de controle, e ninguém percebe até a margem estourar no fechamento do mês.
- Elegibilidade mal modelada (produto, segmento, canal) abre brecha para aplicar promoção em contexto que não devia, e o objeto nativo não impede isso sozinho, só documenta o erro.
- Definir piso de margem depois do rollout é tarde. Isso é decisão de negócio que precisa estar fechada antes da primeira promoção configurada, não durante a primeira crise.
- Sem ownership explícito da política de promoções, todo squad acha que pode criar a própria regra, e você recria em objeto nativo a mesma bagunça que tinha em campo customizado.
- Migrar desconto improvisado de fluxo ou aprovação manual para o modelo nativo exige reconciliar histórico, e subestimar esse esforço é receita para retrabalho em produção.
- Canal mal configurado na regra de promoção gasta condição em contexto errado e some da vitrine de opções para quem cota, sem gerar erro visível.