Os seis objetos centrais do Agentforce Revenue Management

Todo o Agentforce Revenue Management gira em torno de seis objetos, do produto que você vende até a receita reconhecida no balanço. Vale guardar essa sequência: ela é o esqueleto do ciclo inteiro, e cada peça ganha aulas próprias mais adiante. Sem clareza sobre como esses objetos se encadeiam, qualquer implantação começa torta.

Seis objetos, seis etapas

Cada objeto cobre uma etapa do ciclo de receita. Ao lado do nome está o nome de API, que é como você vai encontrá-lo em consulta, flow, Apex e integração.

1. Produto: a fundação

Sem produto não existe receita. O Product2 é o ponto de partida: é ele que você precifica, agrupa em bundles e vende, e é o registro que liga venda, entrega e cobrança.

Um produto pode ser um bem físico, um serviço, uma assinatura ou algo cobrado por consumo. Pode ser vendido sozinho ou como parte de um bundle, e carrega atributos reutilizáveis como plano, tamanho ou faixa de consumo. No catálogo, ele vive numa hierarquia: catálogo, categoria, produto.

Essa hierarquia não é cosmética. Ela define como o vendedor navega no catálogo da cotação e nas experiências de autoatendimento. Modelar mal aqui costuma significar refazer o catálogo inteiro depois.

2. Lista de preços: onde mora o preço

A lista de preços (Pricebook2) é a tabela de preços; na org em português ela aparece como Catálogo de preços, nome que convive mal com o catálogo de produtos, por isso uso lista de preços no guia. Sempre existe a lista padrão, e você cria quantas listas personalizadas precisar. A ponte entre produto e preço é a entrada da lista de preços (PricebookEntry): ela liga um Product2 a um valor dentro de uma lista.

Um produto tem várias entradas, em várias listas. Preço raramente é absoluto; quase sempre depende do contexto comercial:

• Tipo de cliente: varejo, atacado ou parceiro.
• Região e moeda: real, dólar, euro.
• Canal: venda direta ou distribuidor.
• Modelo de venda: no Revenue Management, o mesmo produto tem uma entrada por modelo de venda.

Empurrar tudo para a lista padrão é um dos erros de modelagem mais comuns e mais caros de corrigir. Quando o segundo canal de vendas aparecer, o problema vai estar enterrado no núcleo do modelo de dados.

3. Cotação: a proposta comercial

Antes de fechar, o cliente empresarial costuma pedir uma cotação formal: produtos, preços, descontos, condições e validade. Essa é a Quote, e cada item dela é um QuoteLineItem. Um exemplo com o catálogo da Órbita, usado nos laboratórios do guia:

É na cotação que a complexidade comercial aparece: desconto por volume, aprovação de margem, bundle, cotermo, rampa, produto recorrente, produto único, adicional, renovação. Tratar a cotação como só um PDF de proposta é uma visão limitada. Ela é a fotografia comercial antes de o compromisso virar pedido.

4. Pedido: a compra confirmada

Quando o cliente aceita a cotação, ela vira um pedido (Order), manualmente ou por automação. No caso simples, os produtos do pedido (OrderItem) espelham as linhas da cotação, uma para uma.

Dois estados que vale ter na ponta da língua:

• Rascunho: ainda dá para editar quantidades, preços e descontos, conforme a configuração.
• Ativado: as linhas ficam travadas para alteração direta e o pedido passa a alimentar entrega, ativos, contratos e faturamento.

O caminho entre proposta, confirmação e posse é direto: a cotação aguarda o aceite, o pedido confirma a compra e o ativo (Asset) registra na conta o que o cliente de fato possui.

Cuidado com o um para um. O espelho entre linha da cotação e produto do pedido é o caso simples: primeira venda, sem histórico. Alterações, cancelamentos e renovações sobre uma assinatura geram linhas que não têm correspondência direta com uma linha de cotação existente, como reduções, novo preço e reconfiguração de bundle. Não trate o um para um como regra; a primeira renovação complexa desmente.

5. Contrato: o acordo de longo prazo

Um pedido é um evento único. Serviço recorrente, como SaaS, telecom, mídia, suporte e manutenção, precisa de um contêiner que atravesse vários ciclos de cobrança, renovações e mudanças. Esse contêiner é o contrato (Contract).

Casos típicos:

• Assinatura de SaaS com renovação anual.
• Plano de telecom com linha, dados e adicionais.
• Renovação e alteração ao longo da vigência.
• Acordo plurianual com rampa, ou seja, degraus de crescimento da receita ao longo do contrato.

A recorrência é representada por linhas de assinatura e ativos com período de vigência. É essa estrutura que sustenta as alterações e renovações, e é por isso que o contrato é um dos objetos mais mal compreendidos em implantações apressadas. Quem subestima o contrato no desenho descobre o problema quando o primeiro cliente pede uma renovação parcial, um cancelamento no meio do período ou um upgrade com cotermo.

6. Faturamento e receita: fechar o ciclo

O último elo transforma compromisso comercial em dinheiro e em registro contábil. São três conceitos acionados depois do pedido ativado e, na recorrência, depois de a estrutura contratual estar formada:

• Fatura: a cobrança emitida ao cliente, gerada pelos cronogramas de cobrança.
• Pagamento: o recebimento do valor faturado, conciliado com a fatura.
• Reconhecimento de receita: o registro contábil da receita conforme normas como ASC 606 e IFRS 15.

Faturamento não é só emitir fatura. É onde os erros de modelagem dos objetos anteriores viram problema contábil, com impacto em auditoria, fechamento e previsibilidade. Quanto antes essa dependência ficar clara, menos surpresa no go-live.

Como tudo se encadeia

Juntando as peças, o ciclo de receita é uma corrente contínua: produto, entrada da lista de preços, cotação, pedido, contrato e faturamento.

O ativo nasce quando o pedido é ativado. Ele registra, na conta do cliente, o que o cliente possui, e é o ponto de partida de renovações, alterações e vendas adicionais. Cada elo que você domina é um pedaço dessa corrente. Pule um, e o modelo inteiro perde coerência.

Onde cada objeto aparece no guia

Para fixar

1. Qual objeto liga um produto a um preço dentro de uma lista?
2. Por que o espelho entre linha da cotação e produto do pedido não é regra?
3. Em que momento nasce o ativo?

Na próxima aula, a cascata de preço: como o preço de lista vira preço líquido, degrau por degrau.

Fontes

• Salesforce Developers, PricebookEntry, Quote e Order.
• Trailhead, Revenue Management Foundations.
• Prints e registros da org Winter '27 usada neste guia.