ONE COMMERCIAL MODEL
Do not let product and pricing logic drift across systems.
If Salesforce, ERP, billing and surrounding systems all maintain their own interpretation of products, prices or eligibility, quote-to-cash becomes harder to explain and even harder to change.
The goal is not to force every rule into one platform. It is to define which system owns each commercial decision and make the handoffs explicit.
PROCESS BEFORE PRODUCT MODEL
Define how the deal should work before modeling the product catalog.
Before building bundles, pricing rules or approval logic, map how a deal moves from opportunity to quote, contract, order and downstream execution.
- What can sales configure themselves?
- Which commercial exceptions require approval?
- What becomes binding in the contract?
- Which information must reach ERP, billing or fulfillment?
- How are amendments, renewals or corrections handled later?
The product model should support the commercial process — not become a separate technical universe.
OWNERSHIP
Give every commercial rule one obvious owner.
Product availability, list price, discount logic, bundle dependencies and approval thresholds should not be maintained independently in several places without a reason.
Choose the owning system deliberately, then let other systems consume the result or apply only the logic they genuinely need.
- Product structure: Where are products, variants and bundle relationships mastered?
- Pricing: Which system owns list price, validity and commercial conditions?
- Approvals: Which exceptions require a person to decide rather than another rule?
- Contract / order: Which quote decisions must survive into downstream execution?
EXAMPLE
Example: Quote several product variants without losing approval control.
A more advanced quoting setup becomes useful when sales needs to compare or configure several valid commercial options while approvals remain tied to specific exceptions.
The value is not more quote functionality. It is fewer invalid combinations and fewer manual decisions after the quote is created.
- Offer only product combinations the business is prepared to sell
- Keep variant and dependency rules visible during configuration
- Apply pricing logic from the agreed source instead of recreating it manually
- Trigger approval only when the quote crosses a meaningful commercial boundary
Further steps (1)
- Preserve the selected variant and approved commercial terms into contract and order
- Product
- Price & discount
- Quote
- Approval
- Contract/order
- Billing/change.
CHOOSE THE RIGHT SCOPE
Which scope fits your process?
Do not choose the platform by feature count. Compare the level of commercial complexity the process actually needs to represent.
Salesforce standard or custom? A practical decision framework explores how to assess standard features, low-code and custom extensions over their lifecycle.
Choose the smallest revenue scope that represents the commercial model without pushing complexity into hidden workarounds.
BEFORE PRODUCT SELECTION
Clarify the rules and system boundaries before choosing the Salesforce product.
Product selection becomes much easier once the team can say which rules belong in Salesforce, which belong elsewhere and which decisions genuinely need a person.
Architecture first. Product SKU second.
- Which product and bundle rules must sales see while quoting?
- Which pricing decisions come from another system?
- Which discounts or commercial exceptions require approval?
- Which information must remain consistent across quote, contract and order?
Further steps (1)
- Which lifecycle events — amendments, renewals, cancellations — must the solution support?
DECISION CHECKLIST
Questions to answer before product selection
These questions reveal whether the real complexity is product configuration, pricing, approvals, contracts, downstream integration — or a combination of them.
How many meaningful product variants or bundles must sales configure?
Are pricing rules simple, or do they depend on customer, product, term or other conditions?
Which exceptions should trigger approval rather than another pricing rule?
What must remain consistent from quote into contract and order?
More criteria (2)
How often are quotes amended, renewed or corrected after signature?
Which system should own product, price and commercial state over time?
If these answers are still vague, product selection is probably premature.
FROM PRODUCT TO CASH
Organize the product-to-cash flow around the decisions that matter.
The commercial model becomes easier to operate when each step has a clear purpose, owner and handoff.
01
Understand the products
Define what sales can offer, which variants exist and which combinations are valid.
02
Unify the rules
Make product, pricing and eligibility rules consistent enough that the quote has one commercial meaning.
03
Expose the options
Let sales compare or configure only the commercial options that are genuinely valid.
04
Test from start to finish
Validate quote, approval, contract, order and downstream handoffs with real deal scenarios.
05
Hand over operations
Document ownership, exception handling, support and how commercial-rule changes will be introduced later.
The quote is only one step. The architecture has to survive the full commercial lifecycle.
Common questions about revenue processes
Do we need CPQ or Revenue functionality for every quoting process?
No. Simple quoting can often stay close to standard Salesforce. More advanced revenue capabilities become valuable when product configuration, pricing, approvals or lifecycle scenarios create complexity that would otherwise be rebuilt through custom logic.
Where should Salesforce product and pricing rules live?
Wherever the business can own them most consistently. Salesforce may own some rules while ERP, billing or another platform owns others. The important part is avoiding duplicate ownership and making the handoff explicit.
When should custom logic be introduced?
When the requirement is genuinely business-specific and cannot be represented cleanly through the chosen standard or revenue model. The lifecycle and support responsibility should be explicit before the custom logic is approved.
Sources and further information
Primary Salesforce documentation and reference material for quoting, revenue management, product configuration and related architecture decisions.
- Salesforce — Agentforce Revenue ManagementChecked on
Supports revenue management, CPQ, billing and sales fundamentals; naming, licensing, packaging and migration statements are volatile and must be rechecked before publication.
- Salesforce — Revenue Cloud BillingChecked on
Supports revenue management, CPQ, billing and sales fundamentals; naming, licensing, packaging and migration statements are volatile and must be rechecked before publication.
- Salesforce — Agentforce SalesChecked on
Supports revenue management, CPQ, billing and sales fundamentals; naming, licensing, packaging and migration statements are volatile and must be rechecked before publication.
Topics in this article
THREE WORKING VIEWS
Three views that make revenue decisions traceable.
Configured working examples with fictional records. Each view exposes a specific decision, handoff or review state.
Keep bundle dependencies visible
The required onboarding component remains linked to its base product. Fictional configured Salesforce-style editorial workspace. Not a live product screenshot.
Swipe with your finger or drag with the mouse button held down. You can also select an image or use the arrow keys.
Image 1 of 3: Keep bundle dependencies visible
Continue reading
Salesforce Standard or Custom? Choose for Fit, Not Ideology.
“Standard first” is useful guidance — until it becomes a rule that forces the business into the wrong process. Custom development can solve real problems — until every exception creates another lifecycle burden. The better decision is the simplest option that fits the requirement and that the team can still test, operate and change later.
Read article
Salesforce Integration: Build Interfaces You Can Operate
A working integration does more than move data between systems. Teams need to know what each side promises, who owns the flow, how failures are handled and what happens when one system changes. That is what turns an interface from a technical connection into something operations can actually support.
Read article
Marketing Cloud Next: Move Now, Extend First — or Wait?
A new platform does not automatically create a reason to migrate. Start with the capability that needs to improve, the operating model behind it and the business value the change is expected to create. The right answer may be to improve the current setup, add selected new capabilities or move in stages.
Read article