Summer '26 do Revenue Cloud: seis features que atacam a fricção, não a arquitetura
Nada de novo modelo de dados ou paradigma. É release de quem ouviu reclamação de rep e de admin e resolveu, um por um, os pontos que travam ciclo de venda
O Summer '26 do Agentforce Revenue Management (ex-Revenue Cloud) não muda como você desenha o produto, mas muda como o rep cota, o aprovador aprova e o admin configura usage-based. Seis melhorias pontuais que, somadas, tiram tempo real do ciclo de deal.
Nem todo release precisa reinventar a roda
Todo release tem que ser revolucionário? Não. E é bom quando alguém na Salesforce entende isso. O Summer '26 do que hoje se chama Agentforce Revenue Management (o Revenue Cloud rebatizado, para quem ainda não se acostumou) não traz nenhuma mudança de modelo de dados, nenhum objeto novo estruturante, nenhuma reformulação de pricing engine. É uma lista de seis ajustes de UX e fluxo que, isoladamente, parecem pequenos. Juntos, resolvem reclamações que eu ouço em praticamente todo projeto de Revenue Cloud desde que a coisa saiu do CPQ clássico.
Vou comentar os seis, com a leitura de quem já apanhou de cada um desses pontos em implementação real.
1. Sales Transaction Line Editor sem container fixo
Quem já tentou montar uma quote com ramp de três anos e quinze linhas de produto dentro daquela caixinha de altura fixa do STLE sabe a dor. Você rola dentro de uma caixa que rola dentro de outra caixa, perde referência visual, erra quantidade de mês. No Summer '26 o editor passa a ocupar a altura da página.
Parece bobagem até você lembrar que Revenue Cloud vive de deal complexo, com ramp, com múltiplas linhas relacionadas. UX de quote nunca foi prioridade histórica do produto e isso sempre gerou fricção com o time comercial, que compara (injustamente, mas compara) com ferramentas de quoting mais simples do mercado.
2. Wizard guiado para Ramp Schedule
Esse é o que mais vai economizar retrabalho. Ramp deal hoje, na prática de projeto, costuma virar clonagem manual de segmento, ajuste de data um por um, e a reza para não desalinhar quantidade e vigência. Já vi analista perder a tarde inteira revisando um ramp de cinco anos porque uma data ficou um dia fora do padrão.
O wizard que define número de períodos, duração e até trial period (tipo três meses com quantidade zero) numa tela só, gerando o schedule automaticamente, é o tipo de coisa que devia ter vindo junto com o lançamento original de ramp deals. Bem-vindo, ainda que atrasado.
3. Browse Catalog com atualização de transação em tempo real
Essa mudança é mais estrutural do que parece. O catálogo passa a ser reativo: você seleciona o produto, ele já entra na quote, regra de qualificação e desqualificação roda na hora, painel de preço mostra o impacto no total sem fechar modal e esperar reload.
Se você já implementou Product Rules e Qualification Rules sabe o quanto o ciclo antigo de "adiciona, fecha modal, espera recalcular, torce para a regra ter disparado certo" gerava desconfiança no rep. Ele parava de confiar no que via na tela e ligava para o time de suporte perguntando se o desconto entrou. Interatividade de verdade no catálogo ataca isso direto.
4. Generate Document como LWC, sem depender de OmniStudio
Esse é o ponto que mais bate no bolso do cliente. Até então, para gerar documento (proposta, contrato, ordem) de forma decente dentro do Revenue Cloud, você quase sempre esbarrava em licença de OmniStudio, mesmo quando o cliente só queria doc gen e nada mais da suíte.
Agora é um componente Lightning que você solta na página de Quote, Order ou Contract, gera DOCX, PPTX ou PDF, sem essa dependência de licenciamento. Para quem monta proposta comercial e vive negociando com o cliente se vale a pena pagar OmniStudio só para gerar um PDF, isso remove uma fricção comercial e técnica ao mesmo tempo.
5. Aprovação de quote direto no Slack
Esse aqui é o que mais gera impacto perceptível para quem está no topo da hierarquia de aprovação. VP e diretor não abrem Salesforce todo dia, mas vivem no Slack. Agora a aprovação chega como mensagem rica, com resumo da quote, permite abrir linha de item e aprovar ou rejeitar sem sair do Slack, no desktop ou no celular.
A decisão sincroniza de volta para o Salesforce em tempo real, mantendo histórico de aprovação e automação de próxima etapa intactos. Isso resolve um gargalo clássico de approval process em Revenue Cloud: aprovador que esquece de entrar no sistema e segura o deal por dias.
Se sua organização já usa Slack como camada de trabalho (e cada vez mais usa, principalmente depois da integração mais profunda pós aquisição), esse recurso paga a conta sozinho.
6. Setup guiado de produto usage-based
Quem já configurou um produto de consumo no Revenue Cloud sabe que Usage Resource, Product Usage Resource, Product Usage Grant, Rate Card e Rate Card Entry formam uma cadeia de objetos relacionados que exige atenção e paciência. Errar a ordem ou esquecer uma relação te obriga a refazer parte da configuração.
O wizard consolida isso numa tela só, cuidando das relações entre os objetos. Não muda a arquitetura de usage-based (o modelo de dados continua o mesmo por baixo), mas reduz a barreira de entrada para quem está configurando o primeiro produto de consumo do catálogo.
Se sua organização vende SaaS com modelo híbrido de assinatura mais consumo, esse ponto especificamente vale a pena testar antes de rodar em produção.
O padrão por trás dos seis pontos
Nenhuma dessas mudanças altera como você desenha Price Rule, Product Rule ou estrutura de Bundle. Isso é decisão consciente da Salesforce: releases recentes de Revenue Cloud têm ido na direção de resolver dor operacional recorrente em vez de empilhar feature nova em cima de uma base que ainda está amadurecendo desde a fusão com CPQ clássico.
É uma leitura que faz sentido do ponto de vista de produto maduro. Você já tem o motor de pricing, o modelo de dados de quoting, o approval engine. Agora é hora de lixar as arestas que o usuário sente todo dia.
Para quem vive projeto de Revenue Cloud, esse tipo de release importa mais do que parece à primeira vista. Não é feature que você vende como diferencial estratégico para o cliente, mas é feature que reduz reclamação recorrente do time comercial e do time de operação de receita. O ganho real está em três frentes: menos tempo perdido montando ramp deal manualmente, menos dependência de licença extra (OmniStudio) só para gerar documento, e ciclo de aprovação mais rápido porque o aprovador não precisa abrir o Salesforce. Em ciclo de vendas B2B com deal complexo, cada um desses pontos historicamente adicionava dias ao fechamento. Somado, isso é tempo de ciclo de venda que volta para o time comercial.
Todo release da Salesforce vem com aquele slide de "revolução" que não revoluciona nada. O Summer '26 do Revenue Cloud é o contrário disso, e é por isso que eu gosto dele.
Não tem redesenho de modelo de dados, não tem paradigma novo pra alguém vender curso caro explicando. Tem seis features que resolvem fricção operacional real: aquele ponto onde o rep trava no meio do quote, onde o admin perde meio dia configurando algo que deveria ser trivial, onde o ciclo de venda emperra por um detalhe bobo que ninguém na Salesforce parecia notar até agora.
Isso é maturidade de produto. CPQ e Billing já passaram da fase de provar conceito, o jogo agora é polimento. E polimento não vende palestra de keynote, mas é o que faz o consultor não precisar escrever workaround em Apex pra cada cliente.
Se você é arquiteto ou admin que vive Revenue Cloud no dia a dia, esse release é pra você. Se você só acompanha por curiosidade, pode até parecer incremental demais. E é mesmo, só que incremental do jeito que resolve backlog de reclamação acumulada há releases.
Se você é arquiteto ou consultor em projeto ativo de Revenue Cloud, o primeiro passo é validar em sandbox se o cliente já usa ramp deal ou produto usage-based com frequência. Se sim, o wizard guiado de ramp e o setup guiado de usage têm ROI imediato em horas de configuração poupadas. Se o cliente usa Slack internamente (principalmente para aprovação de desconto ou deal grande), vale priorizar o teste de aprovação via Slack antes mesmo de outras features, porque o ganho de cycle time costuma ser visível já no primeiro mês. Para quem paga OmniStudio só por causa do Document Builder, é hora de revisar o contrato de licenciamento: o novo Generate Document LWC pode eliminar essa dependência e gerar economia direta, sem trade-off funcional relevante para casos simples de geração de documento. Antes de rodar em produção, teste o Browse Catalog reativo com as regras de qualificação e desqualificação já existentes no catálogo do cliente. Regra antiga, desenhada para o fluxo assíncrono anterior, pode se comportar de forma diferente com atualização em tempo real.