SKU-based products
SKU-based products are the foundation of most catalogs: a fixed sellable unit with a defined price structure. One SKU, one thing the customer buys.
Anatomy of a SKU
Each SKU defines:
- Identity — name, display name, and the category it lives in.
- Pricing model — how the line prices: consumption, seats, flat fee, and so on. See Pricing models.
- List pricing — per pricebook and per currency. The same SKU can list at different prices for different segments, regions, or channels, and the right price book is applied automatically based on the deal.
- Price structure — flat per-unit, tiered, or with an included free quantity.
- Billing behavior — billed monthly, annually, or on a fixed schedule; full-month or day-prorated partial periods.
- Selling rules — visibility, editability, price floors, and renewal behavior.
Examples
| SKU | Pricing model | Structure |
|---|---|---|
| Enterprise Platform | Flat Fee Recurring | $5,000/month, annual billing |
| API Events | Consumption + Overage | Tiered: $0.05 → $0.035 → $0.02 per event |
| Additional Workspace | Seats | $200/workspace/month |
| Implementation | Flat Fee One Time | $25,000, year one only |
When to use SKUs
Use plain SKUs when the thing being sold doesn't vary by configuration — a plan, a metered usage type, a support tier, a service fee. When one product comes in many configurations (regions, editions, deployment types), model it once as an attribute-based product instead of multiplying near-identical SKUs.
SKUs over time
Catalogs evolve, and SKUs carry their lifecycle rules with them:
- Versioning — price or structure changes create a new catalog version; in-flight quotes keep the version they started on.
- Renewal mapping — when a SKU is retired or repackaged, its renewal rule (substitute to a successor, or drop) keeps old contracts renewing cleanly onto the current catalog. See Renewals.
- Deal-type visibility — SKUs can be limited to specific motions, like renewal-only loyalty pricing or new-logo promotions.