CPQ Salesforce: quando escolher nativo, integrado ou customizado?

Escolher um CPQ — Configure, Price, Quote, ou configurar, precificar e cotar — é decidir onde ficam as regras que transformam uma oportunidade em uma proposta executável. Considere a oferta atual da Salesforce quando centralizar catálogo, regras comerciais e canais for prioridade, desde que seus produtos, volumes e contratos passem por uma prova de conceito. Estar na plataforma, por si só, não comprova aderência.

Um terceiro executado na plataforma Salesforce merece avaliação quando oferece uma capacidade específica que justifica outro fornecedor. Um motor externo faz sentido quando o ERP (sistema de gestão empresarial) ou um configurador especializado precisa continuar como autoridade sobre configuração e preço, inclusive para outros canais. Já a customização delimitada serve para uma regra isolável, com responsável, versão e testes — não como atalho para reconstruir todo o CPQ.

Também é válido continuar temporariamente com o Salesforce CPQ legado quando ele atende à operação, permanece coberto pelo contrato e uma troca imediata traria mais risco que benefício. A Salesforce informa que o produto está em end-of-sale, não em end-of-life, e que não há migração forçada (posição oficial sobre o legado). A decisão deve comparar aderência, continuidade e custo, não partir de um desligamento presumido.

Salesforce CPQ, Revenue Cloud e Agentforce: o que cada nome significa

O Salesforce CPQ legado é um pacote gerenciado. A documentação do produto informa que ele continua disponível para clientes existentes, sem desenvolvimento de novas funcionalidades, com possibilidade de renovar assinaturas, adicionar licenças e receber suporte durante o contrato. Isso não constitui promessa de suporte perpétuo. Em 09/09/2026, as fontes oficiais citadas não apresentam uma data pública de encerramento de vida do produto.

Os demais nomes precisam ser separados:

• Revenue Cloud Advanced: é apresentado pela Salesforce como sucessor do Salesforce CPQ e integrante da suíte Agentforce Revenue Management. Sua arquitetura é distinta da do pacote legado; portanto, a transição não deve ser orçada como uma simples atualização de versão (explicação oficial).
• Revenue Cloud e Agentforce Revenue Management: o Trailhead informa que Revenue Cloud passou a se chamar Agentforce Revenue Management. Referências ao nome anterior ainda podem aparecer na aplicação e na documentação. A suíte abrange catálogo, CPQ, contratos, ativos, pedidos, cobrança, assinaturas e consumo.
• Agentforce for Revenue: foi o nome usado no anúncio da solução de agentes incorporada ao então Revenue Cloud. Não é sinônimo do pacote Salesforce CPQ legado nem uma maneira precisa de identificar, sozinho, toda a suíte atual.

Na contratação, registre o produto, a edição, os componentes e os direitos de uso. Um nome comercial amplo não determina quais recursos estarão disponíveis no seu ambiente.

CPQ nativo versus integrado: compare quatro arquiteturas

“Nativo” pode significar produto da Salesforce ou produto de terceiro construído para executar na plataforma Salesforce. São situações diferentes: mudam fornecedor, responsabilidade de suporte, modelo de dados e processo de evolução.

A própria Conga apresenta produtos com topologias distintas: Advantage CPQ como Salesforce-native e Smart CPQ como CRM-agnostic. O exemplo mostra por que a avaliação deve ser feita por produto, não apenas pela marca.

Arquitetura	Execução e dados	Consequência para a decisão
Oferta atual da Salesforce	Executa na plataforma, com o modelo dos componentes contratados. A autoridade sobre catálogo e preço precisa ser definida com os sistemas existentes.	Avalie a concentração do ciclo comercial. Elimine se regras essenciais exigirem duplicação estrutural ou adaptações difíceis de sustentar.
Terceiro na plataforma	Executa na plataforma, mas pode usar objetos, regras e ciclos de contrato próprios.	Avalie a capacidade diferenciadora. Elimine se modelo, exportação, limites ou responsabilidade por falhas entre fornecedores não estiverem claros.
Motor externo integrado	Configura ou calcula fora do Salesforce. O Salesforce, como CRM (sistema de relacionamento com clientes), mantém referências e estados sincronizados com a autoridade externa.	Preserva especialização e atendimento a vários canais. Elimine se latência, indisponibilidade ou reconciliação inviabilizarem a venda.
Extensão customizada delimitada	Implementa uma regra específica em Flow, Apex ou serviço externo, sem assumir todo o ciclo do CPQ.	Resolve uma lacuna localizada. Elimine se a extensão se transformar em um segundo catálogo, motor de preço ou gestor de contratos.

Executar na mesma plataforma não garante compartilhar automaticamente objetos, ciclo de vida ou fonte da verdade. Para qualquer produto, exija documentação do modelo de dados, interfaces de integração, limites, atualizações, exportação e suporte.

Em uma extensão, a escolha entre Flow, Apex e serviço externo depende de complexidade, volume, transação e capacidade de manutenção. A equipe precisa conseguir alterar a regra sem redescobrir, a cada mudança, como todo o processo funciona.

A governança também atravessa as quatro opções: quem publica preços não deveria ganhar, por consequência, liberdade irrestrita para aprovar descontos. Quem sustenta a integração precisa enxergar a falha sem receber acesso desnecessário a dados comerciais.

Desenhe o caminho da cotação até o ERP

Antes da demonstração, desenhe uma operação completa:

Catálogo → configuração → preço → aprovação → contrato → pedido → ERP → cobrança e documento fiscal.

Para cada etapa, nomeie o sistema que pode criar ou alterar a informação. Essa é a fonte da verdade: a autoridade definida para aquele dado, não necessariamente um único sistema para a empresa inteira.

O catálogo pode ter atributos técnicos mantidos em um sistema de informações de produto e condições comerciais mantidas no CPQ. Nesse caso, identificadores, versões e vigências precisam conectar os dois. Copiar tudo sem definir precedência cria divergências difíceis de diagnosticar.

Na precificação, registre quantidade, moeda, vigência, recorrência e condições negociadas. A aprovação deve ficar associada à versão da proposta. Se um vendedor alterar itens ou condições depois do aceite interno, o desenho deve determinar quando recalcular e solicitar nova aprovação.

Contrato, pedido e ativo contratado também precisam de vínculos claros. Uma renovação não pode depender apenas do catálogo atual: ela precisa considerar o que o cliente efetivamente contratou e quais mudanças foram aceitas.

A oferta atual da Salesforce anuncia catálogo, precificação, contratos, ativos, pedidos e cobrança, mas também contempla integrações com ERP e sistemas de produto. Portanto, não há fundamento para prometer ausência de integração ou um modelo único em toda a arquitetura.

Onde o Agentforce entra

A página atual de CPQ anuncia configuração por regras e restrições, aprovações configuráveis e cotação assistida com permissões baseadas em função. São capacidades anunciadas para a oferta atual, não documentação funcional do pacote legado.

O agente pode auxiliar a preparar ou atualizar uma cotação, mas não substitui política de preço, aprovação nem segregação de funções. A existência de um recurso no material comercial não comprova que ele funcionará com seu catálogo, suas permissões e seu licenciamento. Isso precisa ser demonstrado. Para entender melhor o que esses agentes fazem e onde ficam seus limites, veja o guia de Agentforce: o que é e como funcionam os agentes de IA no Salesforce — use-o como contexto de navegação, não como prova de aderência para CPQ.

Nas integrações, vale adotar identificadores rastreáveis, tratamento de reenvio sem duplicação — a chamada idempotência — e monitoramento de erros. Esses padrões são aprofundados no guia de integrações no Salesforce.

Exemplo hipotético: uma proposta e uma escolha arquitetural

Imagine uma empresa que vende equipamentos com assinatura de monitoramento. Seu configurador especializado já atende vendedores e distribuidores, e o ERP mantém a configuração técnica aceita para produção.

Uma proposta hipotética contém:

• 30 equipamentos a R$ 2.000: R$ 60.000;
• 30 assinaturas a R$ 100 mensais, por 24 meses: R$ 72.000;
• instalação: R$ 10.000.

O compromisso comercial soma R$ 142.000, antes de consumo variável e sem simulação tributária. Isso não significa uma cobrança única desse valor.

O vendedor solicita 8% de desconto somente nos equipamentos. O desconto é de R$ 4.800, e o compromisso passa a R$ 137.200. Neste cenário, a política exige aprovação gerencial acima de 5%. Um agente pode preparar a proposta, mas a nova versão não deve seguir como aprovada antes dessa autorização.

Suponha ainda que um acessório seja incompatível com o equipamento selecionado. O configurador deve impedir a combinação antes que ela chegue à produção.

A escolha inicial seria manter o motor especializado externo, se a prova de conceito demonstrar resposta adequada, bloqueio da combinação inválida e recuperação de falhas. O Salesforce concentraria a interação comercial e as referências da proposta, sem duplicar o cálculo autoritativo.

A consequência é aceitar dependência operacional da integração. Se o motor ficar indisponível, a proposta não pode ser apresentada como validada: o fluxo precisa preservar o rascunho e indicar o estado pendente. Em contrapartida, a empresa evita manter duas versões da mesma regra técnica.

A oferta Salesforce passaria a ser preferível se demonstrasse a mesma aderência e permitisse retirar o motor existente com benefício econômico. Sem essa evidência, substituir a especialização apenas para reduzir o número aparente de sistemas seria uma aposta.

Brasil: preço comercial não é cálculo tributário nem emissão fiscal

Uma arquitetura de CPQ para o Brasil precisa separar quatro responsabilidades. Essa separação é uma recomendação técnica, não uma exigência de que existam quatro fornecedores:

• CPQ: define configuração, preço comercial, descontos e condições negociadas.
• ERP ou motor tributário: determina o tratamento fiscal conforme operação, cadastros e regras aplicáveis.
• Cobrança (billing): organiza valores a cobrar, competências, vencimentos e ajustes.
• Emissor fiscal: gera e transmite o documento e acompanha os retornos e eventos aplicáveis, como autorização, rejeição e cancelamento.

A Nota Fiscal eletrônica (NF-e) e a Nota Fiscal de Serviços eletrônica (NFS-e) têm regras e leiautes distintos. A escolha do documento depende do enquadramento da operação e da legislação aplicável; não deve nascer de uma classificação comercial simplificada dentro do CPQ.

As orientações da Receita Federal para 2026 tratam do destaque individualizado do Imposto sobre Bens e Serviços (IBS) e da Contribuição sobre Bens e Serviços (CBS), conforme regras e leiautes de cada documento. A dispensa de recolhimento mencionada para 2026 é condicionada ao cumprimento das normas vigentes: não equivale a dispensa de adequação documental.

Obrigação, leiaute e rejeição são coisas diferentes

Recorte em 09/09/2026: o Ato Conjunto RFB/CGIBS nº 4 fixa marcos por documento e categoria de operação — não uma data universal. Para a NF-e modelo 55, o marco geral tratado pelo ato é 03/08/2026, mas o próprio art. 1º, §§1º a 4º, prevê exceções: optantes do Simples Nacional, operações sujeitas à monofasia e operações de importação têm marcos próprios em 2027, enquanto o não contribuinte do ICMS que realizar as operações abrangidas entra em 01/12/2026. Para a NFS-e, 01/10/2026 aplica-se aos serviços também sujeitos ao ISS fora das alíneas “a” a “c”; as categorias enumeradas nas demais alíneas entram em 01/12/2026, e o Simples Nacional segue o tratamento do art. 1º, §1º. Nenhuma dessas datas deve ser lida como um prazo único de preenchimento de qualquer campo, em qualquer operação ou regime.

Na NF-e/NFC-e, a Nota Técnica 2025.002-RTC, versão 1.51 documenta campos e regras para IBS, CBS e Imposto Seletivo. Seu cronograma distingue homologação, produção, obrigatoriedade legal e ativação de validações. A presença de um campo no leiaute não basta para determinar sua exigibilidade em qualquer operação.

Na NFS-e de padrão nacional, a orientação oficial sobre os prazos de IBS/CBS informa que a omissão desses tributos até 31/12/2026 não provoca rejeição pelo sistema nacional, mas pode deixar o documento em desconformidade conforme o enquadramento. Ausência de rejeição não comprova conformidade fiscal.

Além disso, a Nota Técnica 009 da NFS-e prevê cronograma de implantação separado. Sua publicação não significa disponibilidade integral em produção, distinção também presente na documentação técnica oficial da NFS-e.

Para o projeto, a entrega concreta da área fiscal deve ser um mapeamento aprovado de operação, regime, documento, classificação tributária e regra aplicável. A arquitetura deve preservar esses identificadores e a versão do cálculo entre cotação, pedido e emissão. Nenhuma das páginas comerciais de CPQ citadas comprova, sozinha, localização fiscal brasileira completa.

Uma prova de conceito curta, com evidências eliminatórias

A prova de conceito (PoC) deve usar dados representativos e resultados esperados definidos antes da execução. Não basta acompanhar um caminho ideal preparado pelo fornecedor.

Selecione os casos aplicáveis abaixo e registre versão do produto, configuração, entradas, saídas e falhas:

1. Combinação inválida de produtos: tentar um conjunto incompatível. Evidência: bloqueio explicável, sem depender de correção manual posterior.
2. Recorrência e consumo: combinar cobrança única, mensalidade e consumo variável. Evidência: memória de cálculo reproduzível, com vigências e arredondamentos acordados.
3. Desconto fora da alçada: solicitar uma exceção e alterar a proposta após aprovação. Evidência: histórico da versão e bloqueio ou reaprovação conforme a política, inclusive por agente ou integração.
4. Renovação de contrato existente: renovar ou alterar um ativo com condições diferentes das do catálogo atual. Evidência: preservação dos direitos e valores esperados.
5. Volume representativo: executar propostas grandes e acessos simultâneos. Evidência: tempos e erros medidos contra limites definidos pelo negócio, sem aceitar promessas genéricas de escala.
6. Falha e reenvio de integração: interromper a comunicação após o processamento no destino. Evidência: recuperação sem criar pedido ou cobrança duplicados.
7. Conciliação comercial: acompanhar a mesma operação da proposta à cobrança. Evidência: quantidades, versões e valores conciliáveis, com justificativa para diferenças legítimas.
8. Documento fiscal aplicável: percorrer a integração até o ambiente de homologação correspondente. Evidência: conteúdo conforme o leiaute e o enquadramento aprovados, além do tratamento dos retornos.

Se um caso obrigatório falhar, registre a correção proposta, seu responsável e o custo de sustentação antes de manter a alternativa na comparação. Distinguir “funcionou”, “está documentado” e “depende de desenvolvimento” evita contratar uma hipótese como se fosse capacidade entregue.

Compare o custo total em 36 meses

O custo total de propriedade, ou TCO, precisa de um horizonte comum. Aqui, 36 meses a partir da decisão é um critério de comparação, não uma média de mercado nem uma previsão empírica de duração de projetos.

A conta deve incluir:

• Contratação: licenças, módulos adicionais, ambientes e consumo de inteligência artificial, quando aplicável.
• Transição: implantação, saneamento e migração de dados, integrações, testes e treinamento.
• Operação: administração, monitoramento, suporte, manutenção de regras e regressão após atualizações.
• Saída: exportação, substituição de extensões, encerramento de contratos e eventual operação paralela.

Use o mesmo escopo funcional e os mesmos volumes nas alternativas. Uma proposta que exclui renovação, fiscal ou suporte de integração não é necessariamente mais barata: pode estar incompleta.

Também estime o trabalho interno. A extensão sem licença adicional pode consumir horas de desenvolvimento, testes e atendimento de incidentes. O terceiro na plataforma pode exigir coordenação entre fornecedores. O motor externo pode preservar um investimento, mas acrescentar custo de observabilidade e recuperação.

Para continuar no legado, inclua sustentação e o custo de adiar requisitos relevantes. Se houver migração prevista dentro do horizonte, ela entra na conta. Custos relevantes posteriores aos 36 meses devem ficar explícitos, não desaparecer por conveniência.

Compare ainda cenários de crescimento de usuários, volume de cotações, consumo e mudanças contratuais. Valores dependentes de premissas devem aparecer como estimativas, não como economia garantida. O guia de custos do Salesforce complementa a discussão sobre composição do investimento.

Decida com um plano de continuidade

A alternativa escolhida deve passar pelos requisitos eliminatórios e apresentar o melhor equilíbrio entre custo, risco e capacidade de evolução. O menor TCO entre soluções que não atendem à operação não resolve o problema.

Se a decisão for migrar, comece por um recorte controlado de produtos ou canal. Reconcilie contratos, ativos e propostas abertas antes da mudança. Defina como concluir transações iniciadas no sistema anterior e em quais condições interromper ou reverter a transição. O prazo decorre dessas dependências, não de uma faixa genérica de mercado.

Se a decisão for permanecer temporariamente no legado, registre os gatilhos de reavaliação: requisito novo não atendido, deterioração do suporte, custo crescente ou mudança contratual relevante. Permanecer pode ser uma decisão consciente; permanecer sem critérios é apenas adiar a escolha.

O resultado esperado não é “ter o CPQ mais novo”. É conseguir explicar quem controla cada regra, demonstrar que a operação funciona e conhecer o custo de mantê-la e alterá-la.

Precisa comparar essas alternativas no seu cenário? Converse com a WeeNow sobre um diagnóstico de arquitetura CPQ.