Product packaging · Business models · Customer value
When should a capability be bundled or sold separately?
Compare an included capability, a paid add-on and an offer funded by another revenue stream. Test who benefits, who pays and how the packaging changes adoption, delivery effort and the value of the whole relationship.
Trace the value and the payment separately
Identify who uses the capability, who benefits from its use and who can authorize payment. These may be different people or organizations. Describe the work it changes and the alternative the buyer would otherwise choose before deciding whether it deserves a separate price.
A capability may help the business through a direct fee, a stronger combined offer or another transaction it enables. Name the proposed route explicitly. For a free adjacent service, identify which activity is expected to fund delivery and what evidence would connect use of the service with that activity.
Keep repeated demand distinct from an occasional need. A customer who values a one-time setup may have little reason to buy a recurring package. Conversely, separating a capability needed on every use may add purchasing friction. Examine the frequency and context of the customer's actual task.
Compare a few offers with different boundaries
Describe the included version, the optional paid version and any standalone offer using the same customer situation. Specify the usable result, service obligations and limits in each. Include the cost of provisioning, integration, support and corrections, especially when expert work accompanies software access.
Bakos and Brynjolfsson's research on information-goods bundling examines how buyer valuations and marginal costs affect the model's results. Its assumptions are important: findings about large collections of low-marginal-cost information goods do not establish the best package for a service requiring substantial work on each delivery.
Stripe's recurring-pricing documentation distinguishes flat-rate, per-seat, tiered and usage-based models. Those mechanisms describe ways to charge once the offer is defined. Select a unit customers can understand and that the team can administer, while separately checking whether customers value the proposed boundary enough to buy it.
Evaluate the complete customer relationship
Test a clearly described offer with a defined customer group. Record which option customers choose, the work needed to adopt it and what they give up or replace. Keep interest in a capability separate from acceptance of its price and the practical ability to implement it.
Review the effect on the combined offer. An add-on can earn its own fee while changing purchases elsewhere in the relationship. An included feature can be valuable even when no invoice line names it. Avoid allocating revenue to individual features simply in proportion to their usage.
Compare delivery effort and customer behavior over a period appropriate to the task's cadence. Check whether the package creates unexpected support obligations or discourages the activity that was supposed to support another revenue stream. Revisit the choice when a capability becomes standard, its operating cost changes or customer needs diverge.