Rev-Con-201 study materials
Rev-Con-201 study resources

A configurable bundle whose price collapses when an option is removed

Rev-Con-201 · Put your knowledge to work in context.

All case studies

A configurable bundle whose price collapses when an option is removed

Vertex Robotics sells a base inspection scanner plus add-on modules. Sales must be able to attach any two of five calibration modules to a scanner and apply a 15 percent bundle-level discount that may not stack with module-level promotions. Two attribute families, throughput and enclosure rating, drive scanner price, but only 6 of the 12 possible combinations are actually buildable. Reps average a 22 percent discount against a 12 percent policy ceiling, and approvals happen over email. Last month a rep quoted a non-buildable unit; order entry rejected it two weeks later. Separately, when a rep deselects all optional modules, the scanner line prices at zero. There are 40 such configurable products in scope.

1. Recommend a bundle structure and say where the any-two-of-five rule and the 15 percent discount should live.

Read the worked answer

Because the child products are real, separately orderable SKUs with their own prices and their own revenue, a static bundle is the better default: the composition is defined at design time and each child carries a price that can be allocated to on an order line. Use a configurable bundle only where the selection itself must happen at quote time.

The any-two-of-five rule belongs on the bundle group, not on the individual modules. The constraint is about the group cardinality - minimum two, maximum two of the calibration group - and expressing it on individual products cannot represent a cardinality limit. Putting it on the bundle gives the rep an immediate message at configuration time.

The 15 percent discount belongs at the bundle header, applied to the bundle total, with the rule that the bundle discount and any module promotion consume the same discount ceiling. Compute a combined effective discount and route to approval when it exceeds 12 percent. Approval by email is the actual root cause of the 22 percent average, so the fix is a threshold in the system that blocks submission, not a stricter memo.

2. Diagnose the zero-price symptom. What would you inspect, and what is the likely fix?

Read the worked answer

A price that disappears when options are removed usually means the base product's price is not carried independently. Three plausible causes, in order of likelihood:

  1. The scanner is priced as a derived total of selected children, so removing all children yields zero. This happens when the base is modeled as a container rather than a priced line.
  2. The price book entry for the scanner exists only for a specific configuration or effective date, so the pricing call fails to resolve a price and defaults to zero rather than erroring.
  3. The configuration payload omits the base product when the optional group is empty.

Inspection order: confirm whether the scanner is a parent line or a child; check the price book entry for the base SKU by currency and effective date; run the configuration with an empty optional group and watch whether the base product is passed to pricing.

The fix is to price the base SKU explicitly and make add-ons strictly additive, then add a guard so that an unresolved price raises an error instead of returning zero. Silent zero-pricing is more dangerous than a hard failure on a quote.

3. How should the 6-of-12 buildable attribute combinations be enforced, and why not in pricing?

Read the worked answer

Split the two concerns.

Buildability is a constraint: a product rule that evaluates throughput against enclosure rating and blocks the combination at configuration time. The rep sees the message while quoting, which is the point - the failure must surface where the rep can respond, not at order entry two weeks later. That delayed rejection is itself a symptom that validation sits too far downstream.

Price is a separate concern: an attribute-based price table with six valid rows keyed on the throughput and enclosure values. The table should error on an unrecognized combination rather than fall through to a default.

The reason not to encode buildability in a pricing rule is that pricing rules are silent - they set a number, they do not explain themselves - and they run at a point where the rep may not be looking. A quote that is priced but unbuildable is worse than a quote that cannot be configured, because it looks legitimate and gets sent to the customer. Constraints for legality, pricing for money.