Pattern · Pricing
Included allowances and overage
Express “the first N hours are included, beyond that you pay” natively — and find out why only one of your allowances applies.
The problem
Several bundles each include an allowance — so many hours of training, so many months of a service — with anything beyond charged at a real rate. Five allowances were configured. Exactly one worked.
Context
A product catalog where the included quantity differs per bundle, and the overage price differs per service.
Recommended architecture
Model the allowance as a price adjustment schedule with tiers — included quantity at zero, overage at the real price — rather than as a bundle pricing flag. Tiers express the shape directly and stay readable to whoever maintains the catalog.
The failure had nothing to do with the tiers. The default pricing procedure applies schedules through hardcoded constants, not dynamically: one constant pointed at one schedule, so only that schedule was ever read. The fix is a single global schedule holding every allowance, with the constant pointed at it.
Implementation
- Build one global schedule carrying the tiers of every allowance, rather than one schedule per offer.
- Point the procedure's constant at it and reactivate the procedure — editing it deactivates it.
- Verify on a real quote by repricing and reading the line totals.
Trade-offs
One global schedule is less tidy than one per offer, but it is what the procedure actually reads. Per-offer schedules can stay in place, inert, as documentation — or be deactivated to avoid confusing the next person.
Watch out
- Tiers carry a currency. Tiers written in one currency do not match a transaction in another, and the allowance silently fails — a trap when an offer is extended to a new region.
- Editing a pricing procedure deactivates it. Reactivate it, or nothing prices.
- Ramp segment dates are locked on a yearly segment and editable on a custom one. What looks like a date bug is a segment type.