The quiet tax on every modern SaaS catalog
Walk into the CPQ of a mature SaaS business and you will usually find the same thing: a product list that nobody trusts. There is a Professional seat, a Professional seat with the analytics add-on, a Professional seat with analytics for customers in Germany, a Professional seat with analytics for customers in Germany who signed a three-year deal. Somewhere in that pile there is a legacy SKU from 2022 that three reps still quote from out of habit.
This is the SKU trap. It rarely arrives as a single bad decision. It accumulates, one pricing experiment at a time, until the catalog is the thing slowing sales down instead of speeding them up.
And it hits usage-based SaaS hardest. The moment you move beyond a flat seat fee, every dimension of value can become a new line item: volume brackets, overage rates, regional multipliers, commitment discounts, bundle variations. Treat each of those as its own SKU and the math of combinations is brutal.
What the catalog is actually trying to model
A SKU is a good abstraction for a thing you pick off a shelf. It is a poor abstraction for a pricing agreement that changes continuously based on how a customer uses your product.
What a usage-based contract actually contains is closer to three independent things:
- What is being measured — API calls, seats, GB processed, documents signed
- How the price behaves — a flat fee, a per-unit rate, a tiered curve, a commitment with overage
- What is being agreed — the specific plan, commitment, and discount structure on this deal
Collapse all three into one identifier and you lose the ability to reason about any of them separately. Change a tier and you need a new SKU. Run a pricing experiment and you need fifteen. Launch in a new currency and you need the whole grid again.
If the answer to every new pricing idea is "add a SKU", the answer to every old pricing idea is "nobody remembers why".
How Plock separates the three axes
Plock was built around the observation that pricing is not a product — it is a relationship between a meter, a plan, and a subscription. Each is modelled independently, and the catalog stays small.
Meters, not line items
A metric in Plock is just a named, timestamped stream of usage values — sourced directly from your product database through a connector. A metric is defined once. Whether you are measuring processed documents, active agents, or GB egressed, the metric exists on its own with no price attached, and feeds into any plan that references it. Metrics live on their own page in the product, where you can inspect the raw usage stream and edit the definition independently of any pricing.
Plans carry the pricing logic
Charging happens through a plan, which attaches a price model to a metric. A plan knows whether it is a fixed recurring quantity or consumption-based metered usage, whether its billing scheme is a flat per-unit rate or tiered, and if tiered, whether the tiers are graduated, volume, or bulk. Tiers themselves are expressed as a simple list of thresholds, flat fees, and unit rates. The product detail view shows every plan attached to a product, including plans scoped to a specific customer.
Because the plan owns the price and the metric owns the measurement, swapping or versioning a price model does not disturb the rest of the catalog. A plan with five tiers is still one plan. A plan in EUR and the same plan in USD are still one pricing intent, not two SKUs in a spreadsheet that have to be kept in sync.
Products group the story, not the maths
A product in Plock exists mostly to give humans something to name and group. Products can be collected into groups, carry tags, and are managed through the product editor. They are the narrative wrapper the CRM and the customer see. They are not where pricing complexity lives, which is the point — nothing about adding a new plan forces a new product, and nothing about launching a regional variant forces a new catalog entry.
What disappears when the catalog stops bloating
Once pricing is expressed as meters and plans, a long list of CPQ problems quietly stop being problems.
- Sales reps stop guessing. Every quote line item references a real plan, not a frozen SKU someone typed out last quarter. The maths is the same maths as billing.
- Discounting stays inside guardrails. Rebates and discount limits are expressed as configuration rather than as shadow SKUs. The rebate configuration lets you describe the discounting framework once, and approval rules route anything outside the framework for review instead of silently landing in the contract.
- Pricing experiments are cheap. A new tier curve is a new plan, not a fork of the catalog. You can try it, measure it, and retire it without polluting the list of things a rep can quote.
- Billing and quoting agree by construction. Because the quote and the subscription consume the same plans and the same metric streams, there is no separate translation layer where a SKU-to-meter mapping can drift.
The test for catalog health
A useful question to ask your own business: if you wanted to change the overage rate on your mid-market plan tomorrow, how many places would you need to edit? If the answer is "one plan", the catalog is doing its job. If the answer involves a migration script, a CPQ rebuild, and a conversation with finance about legacy SKUs that nobody will let you deprecate, something earlier in the stack has quietly become load-bearing that should not have been.
Usage-based pricing is a good idea. It only breaks when the catalog that represents it cannot keep up with the speed of the pricing decisions behind it. Meters and plans, kept separate, keep that speed available.
If your CPQ has started to feel like an archive rather than a tool, it is probably worth a conversation. We have written more about how this plays out in day-to-day selling on the quoting solution page, and the team is always happy to walk through a specific catalog on a call.