Salesforce CPQ Pricing Methods: Choosing the Right One per Line

A real product portfolio has different kinds of products. A fixed-fee subscription. A volume-discounted hardware line. An add-on that prices as a percentage of the bundle it attaches to. A build-to-order custom solution. A telecom service whose price depends on geography, tier, and bandwidth.

Each of these needs a different pricing method, and Salesforce CPQ supports five out of the box. The trouble is that most implementations pick one method (usually List Price) and apply it everywhere. Quotes come out technically correct and commercially wrong. The sales rep manually overrides the price. Discounts get applied inconsistently. The pricing engine becomes ornamental.

The fix is to match the method to the product. The choice is determined by how the price is actually decided, not by what is easiest to configure.

Method 1: List Price

The simplest case. The product has a price in the price book. CPQ looks it up by (Product, Price Book, Currency). That price (after discount schedules) is what appears on the quote.

When it works:

• Standard catalog items with stable published prices.
• Subscription products with a fixed monthly or annual fee.
• Hardware with a published unit price.

When it does not work:

• Volume-sensitive items where the unit price should drop at quantity thresholds.
• Items whose price varies based on configuration attributes.
• Add-ons that price as a function of the parent product.

List Price is the default and the right answer for the majority of standard catalog items. It becomes the wrong answer when the underlying pricing logic is more sophisticated than a static lookup.

Method 2: Block Price

Volume discounts in tiers. The quote line price changes based on the quantity ordered. Buy 100 units at $50 each, buy 500 units at $42 each, buy 1000 units at $38 each.

CPQ stores the tiers as Block Price records linked to the product. The pricing engine picks the right tier based on the quantity on the quote line.

When it works:

• Hardware sold in batches with published volume discounts.
• License bundles with tier-based pricing.
• Services priced by volume of work (hours, transactions, seats).

When it does not work:

• Volume discounts that depend on the customer (e.g., enterprise vs SMB tiers). Block Price is per product, not per customer. Use Discount Schedules layered on top of List Price for customer-specific tiers.
• Discounts that depend on total deal value rather than per-line quantity. Block Price reads single-line quantity, not deal total.

Block Price is the right tool when the volume tier is a property of the product itself. Customer-specific or deal-total logic belongs in a different layer.

Method 3: Percent of Total

The price of the line is a percentage of the price of another line (usually a parent product). Used for add-ons that price as a fraction of what they attach to.

Common scenarios:

• Premium support that costs 20 percent of the underlying software license.
• Insurance or warranty as a percentage of the hardware it covers.
• Implementation fees as a percentage of the contract value.

The mechanics: the add-on product has Pricing Method set to Percent of Total, with a percentage configured (or read from a custom field). The parent product on the same quote determines the base. The add-on's price recalculates whenever the parent's price changes.

When it does not work:

• Add-ons priced as a flat fee regardless of parent. Use List Price.
• Add-ons whose percentage varies based on tier or customer. Use Price Rules to compute the percentage dynamically.

Percent of Total is the right answer for genuinely proportional add-ons. Make the relationship explicit so the sales rep understands the math.

Method 4: Cost Plus Markup

The price is computed from cost data plus a markup percentage. Used when the underlying cost varies (custom builds, project work, services with variable inputs) but the margin is policy-controlled.

The mechanics: the product has fields for Cost and Markup. The pricing engine computes Price = Cost x (1 + Markup / 100). The quote line shows the result; the inputs are visible to authorized users.

When it works:

• Build-to-order solutions where the cost depends on the configuration.
• Professional services priced on actual hours and rates plus markup.
• Hardware bundles with custom component combinations.

When it does not work:

• Standard catalog items where cost is not the right pricing input (market-based pricing, value-based pricing). Use List Price.
• Cases where the customer should not see the markup math. Cost Plus exposes the underlying structure; if commercial pressure requires hiding it, use List Price with a different governance layer.

Cost Plus Markup is the right answer when pricing is genuinely cost-driven. It requires that cost data be maintained reliably, which is its own integration challenge.

Method 5: Attribute-Based

The price depends on multiple input dimensions: region, tier, bandwidth, configuration option. The combination of attributes drives the price.

The mechanics: the product has Pricing Method set to List Price (as a baseline), and Price Rules layer on top. Each rule has criteria based on attribute values and an action that modifies the price.

When it works:

• Telecom services where price depends on geography, speed tier, and contract length.
• SaaS pricing where seats, modules, and tier combine to determine price.
• Industrial products with configuration-driven pricing matrices.

When it does not work:

• Simple cases where a single attribute drives price. Use List Price with multiple SKUs.
• Cases with three or four attributes but few combinations. A small product list with explicit SKUs per combination is simpler to maintain than complex Price Rules.

Attribute-Based pricing is the most powerful and the most expensive to configure. The flexibility comes with maintenance cost. Use only when the combinatorial pricing space genuinely requires it.

A decision framework

For each product or product line, run through five questions:

1. Is the price a static number from a catalog? Use List Price.
2. Does the price depend on quantity per line? Add Block Price tiers.
3. Is this product an add-on whose price is a fraction of another? Use Percent of Total.
4. Is the price computed from cost data? Use Cost Plus Markup.
5. Does the price depend on multiple input attributes? Use Attribute-Based with Price Rules.

Most product portfolios end up with two to four methods in use across different lines. A telecom company might use Attribute-Based for connectivity services, Block Price for equipment bundles, and Percent of Total for support add-ons. A B2B SaaS company might use List Price for subscriptions and Percent of Total for implementation services. The mix reflects the underlying commercial reality.

Common implementation mistakes

Five patterns Sapota's Salesforce team sees in CPQ audits:

• List Price for everything. Sales reps manually override prices on most quotes. CPQ adds friction without value. Diagnose by counting the percentage of quote lines with manual overrides. Above 20 percent suggests pricing methods are mismatched.
• Block Price used for customer tiers. Block Price is per product, not per customer. Customer tiers belong in Discount Schedules layered on List Price. Block Price misused for customer tiers fragments the product catalog.
• Percent of Total without governance. Add-on percentages set inconsistently across products. 20 percent here, 25 percent there, with no documented policy. Audit and document the rules.
• Cost Plus Markup with stale cost data. The integration that updates Cost from the upstream system breaks. Cost stays at last-known value. Markups stay correct but margins erode. Monitor the freshness of cost feeds.
• Attribute-Based pricing with 50 Price Rules and no documentation. The combinatorial complexity becomes invisible. Changes break things unpredictably. Reduce Price Rules to the minimum needed and document the matrix.

The right pricing methods make CPQ produce quotes that match commercial intent without manual intervention. The wrong methods produce a tool that sales reps work around. Sapota's Salesforce team designs the pricing method strategy as a deliberate workstream on every Revenue Cloud engagement.

---

Designing or auditing pricing methods in Salesforce CPQ? Sapota's Salesforce team holds the Revenue Cloud Consultant credential and handles pricing engine strategy on production engagements. Get in touch ->

See our full platform services for the stack we cover.