Explain a Product's Pricing Model Without Recreating the Rate Card
Explain a Product’s Pricing Model Without Recreating the Rate Card
A slide that says "from $600 a month" has told the buyer a number. It has not told them what makes their bill different from that number, and that is the question they are actually holding. Reproducing the rate card does not fix it either. A longer list of prices is still a list of prices, and the buyer leaves with more digits to remember and no better grip on the mechanism.
The mechanism is four things. What gets bought, and what gets counted as a unit. Whether the charge applies once or keeps applying, and what the base amount already covers. One representative customer worked all the way through, so the arithmetic is visible. And the nearby condition that changes the result — the allowance running out, another unit being counted, the pricing step the customer crosses.
Get those four into the deck and the buyer can predict their own invoice instead of admiring yours. Miss any one of them and the most confident slide in the deck becomes the source of the awkward call in six weeks.
Name what is bought and what is counted
The offering and the charging unit are different sentences, and pricing slides tend to collapse them.
The offering is the thing being sold: a workspace, a support retainer, a monthly processing account, a compliance review. The charging unit is what the meter counts: an account, a seat, a completed transaction, a volume of usage, a bounded piece of work with an end date. A single clear line can carry both — "a processing account, billed per completed job, monthly" — but only if you say it deliberately rather than letting the noun from the product page do the work.
"Per user" is the standard warning case, because it means at least three different things in practice. Sometimes it counts everyone who has been invited into the workspace. Sometimes it counts only people holding a billable seat, and invitations are free. Sometimes it counts people who actually logged in during the month. The words on the slide are identical in all three; the invoices are not, and a buyer who assumes the wrong one will build a budget on it.
The rule that keeps you honest here is unglamorous: use the owner's definitions, not a tidier version you prefer. If the terms charge per connected store, writing "per store" is not a simplification, it is a different model, and the buyer will discover the gap at the worst possible moment. If the counted event has a completion rule — a job counts when it finishes, a reservation counts when it is held rather than confirmed — that rule belongs in the explanation, because it is part of what the unit is.
Make interval and inclusion part of the explanation
Once the unit is clear, two questions follow immediately. How often does the charge apply, and what does the base amount already buy?
On interval, "monthly" is usually not the whole answer. Is the fee invoiced at the start of the period while usage is invoiced after it closes? Is there an annual commitment billed in twelve pieces? Does the allowance reset each month, or does unused capacity carry forward? Each of these changes what the customer sees and when, and each is a one-line addition. A buyer who is told only "monthly" and then receives two documents a month has been told the truth and still been surprised.
On inclusion, the sentence that goes missing most often is the scope sentence: "includes 100 completed jobs." That is not a footnote. It is the boundary that determines whether the customer's usage sits inside the flat fee or pushes against it, and without it the price has no shape.
The other half of inclusion is the feature boundary. A product demonstration is not a plan description. If the walkthrough shows single sign-on and audit trails and the entry offer excludes both, the buyer has been shown the product and told a price, and has been invited to connect them. Keep the demo and the plan separate, and be explicit about what the base tier does and does not reach.
Where a recurring access fee and a usage charge both exist, say so as two parts rather than one blended number. "A monthly account fee plus a per-job charge above the allowance" is a sentence a buyer can reason with. A single figure that quietly contains both is not.
Walk through a representative case
One worked example, fully specified, beats a table of possibilities. Here is an authored teaching model, not any vendor's terms, not a quotation, and not a savings comparison:
Hypothetical model — illustrative only
- Offering: a processing account.
- Charging unit: one completed processing job. A submission that fails validation and is resubmitted counts once, when it completes; the failed attempt does not count separately. In the cases below, assume every submitted job completes.
- Interval: monthly. The account fee is invoiced at the start of the month; jobs above the allowance are invoiced after the month closes. The allowance does not carry over.
- Base: $600 per account per month, including 100 completed jobs.
- Above the allowance: $3.00 per additional completed job.
Now trace two customers.
Customer A runs 80 jobs. Eighty is under the allowance, so every job is inside the base fee. $600 plus $0. The month totals $600.
Customer B runs 120 jobs. The first 100 are covered. Twenty jobs sit above the allowance at $3.00 each, which is $60. The month totals $660 — $600 invoiced at the start, $60 invoiced once the period closed.
The interesting number is not $660. It is the distance between A and B. Forty more jobs cost $60, not $120, and twenty of those forty cost nothing at all, because A was already below the line. A buyer who understands that sentence understands the model. A buyer who has memorised $660 understands one invoice they will never receive exactly.
This is also where the "starting at" panel does its damage. A slide reading "From $3 a job" invites the buyer to multiply. At 80 jobs they compute $240; the actual charge is $600. At 120 they compute $360; the actual charge is $660. Two errors stack: the base fee has vanished, and a marginal rate has been presented as if it were a total price. The mirror-image failure is a panel reading "Starting at $600 a month" with no mention of the allowance. That figure is exactly right for Customer A and stops being the whole price the moment the hundredth job is done — and the slide offers the buyer no way to know where that moment is.
Keep the example clearly fictional when you have not been given the real terms, and keep it clearly sourced when you have. Real terms need the owner's name and the date you retrieved them, on the slide or immediately beside it. And do not put the illustrative result next to a competitor's plan you have not priced against the same volumes. That comparison looks rigorous and is usually two guesses in a suit.
Show where the model changes behavior
A pricing model is most useful to the buyer at the point where it bends, so the deck should show the bend rather than a tidy average.
In the model above, the charge against job count is flat at $600 from zero to 100 jobs, then climbs at $3.00 per job. Draw that, because a smooth line misleads in a way the reader can check. A straight line from the origin to (120 jobs, $660) implies that 60 jobs cost $330; the actual charge at 60 jobs is $600. A straight line drawn instead from (0, $600) to (120, $660) implies 60 jobs cost $630, which is also wrong. The true shape is a flat segment and then a slope, and the flat segment is where most of the customer's money actually goes. Smooth curves over step changes are not a stylistic choice; they are a different claim.
The next bend to show is a second counted unit. The same terms apply per account, and the allowance is per account — it does not pool across accounts. Three accounts therefore carry $1,800 in base fees and three separate allowances of 100 jobs each. A customer running 100, 100 and 140 jobs pays $600, $600 and $720, for $1,920. Move the same 340 jobs around — 60, 140, 140 — and the bill becomes $600, $720 and $720, or $2,040. Identical total volume, $120 apart, entirely because of the counting boundary. That is not a rounding curiosity. It is the kind of condition that decides whether a customer consolidates onto one account or spreads across three, and it belongs on the slide rather than in a footnote.
The third bend is a naming trap. "Tiered" does not settle anything by itself, because two tiered plans with the same bands can charge differently. Take a second, unrelated hypothetical model with a first band of 100 units at $7.00 and a second band from 101 to 500 units at $5.00. Under a graduated reading, a customer at 120 units pays $700 for the first hundred and $100 for the next twenty: $800. Under a volume reading, the rate for the band the total falls into applies to everything, so 120 units falls in the second band and the whole quantity is priced at $5.00: $600. Same bands, same description, $200 apart. Neither answer is more sophisticated than the other; they are different mechanisms, and only the actual terms say which one you are explaining.
Stripe's product documentation separates a product from its price and describes several recurring pricing models, including flat-rate, per-seat, tiered and usage-based arrangements (Stripe product documentation, inspected 8 September 2026). That vocabulary is genuinely useful for naming what you are looking at. It is not a definition of your product's terms, it is not an exhaustive list of the models in the world, and it does not tell you whether a particular tiered plan reprices the whole quantity or only the units in the band. The owner's current terms do that. Do not reverse-engineer a company's rates from someone else's API taxonomy.
Keep detailed terms available without hiding consequential ones
The full rate card still has a job. It handles the branches that do not touch your example: the enterprise add-on, the regional currency, the committed-use discount your buyer is not eligible for. Link it, date it, and put it where a diligent reader can find it in one click.
What the rate card must not become is a hiding place. Any condition that changes the representative case belongs on the slide or immediately beside it — the allowance, the per-unit rate above it, the interval, the counting boundary, and whatever happens at the bend the customer is closest to. Everything else can live one link away. Simplification is allowed to drop branches that do not affect the person reading. It is not allowed to change the arithmetic. If removing a detail changes the answer, the detail was doing real work and the simplification was a misstatement.
There is a practical test that catches most of this. Cover the figures on the slide and ask a reader to say what would make the bill rise. If they can name the counted unit, the interval and the condition, the slide works and the numbers underneath it are decoration. If they can only recite the smallest figure, you have built a price list and called it an explanation.
A buyer who has finished this deck should be able to say something like: we pay per completed job, monthly, the first hundred are included, it is three dollars each after that, and the bill does not move until we cross a hundred — and if we open a second account, we get a second hundred and a second base fee. That sentence is the deliverable. The rate card stays linked behind it, available for the details and no longer required to correct anything the simpler version got wrong.
Frequently asked questions
What four parts make a pricing model understandable?
What gets bought and what is counted as a unit; whether the charge applies once or keeps applying and what the base amount covers; one representative customer worked all the way through; and the nearby condition that changes the result, such as an allowance running out or a pricing step being crossed.
Why is per user a warning case in pricing explanations?
It can mean everyone invited into a workspace, only people holding a billable seat, or people who logged in during the month. The words can be identical while the invoices differ. Use the owner's definitions rather than a tidier version, and include any completion rule that defines the unit.
How should a recurring fee and usage charge be described?
Say them as two parts rather than one blended number. A sentence like a monthly account fee plus a per-job charge above the allowance lets the buyer reason. State the allowance, the rate above it, the interval, and what the base tier does and does not include.
Why can a smooth cost line mislead?
If the true model is flat to an allowance and then rises per unit, a smooth line is a different claim. In the example, a straight line from zero to 120 jobs and $660 implies 60 jobs cost $330, but the actual charge at 60 jobs is $600; a line from $600 at zero to $660 at 120 implies $630 at 60 jobs, also wrong. The flat segment is where much of the customer's money goes.
What is the difference between graduated and volume tiering?
With bands of 100 units at $7 and 101 to 500 units at $5, a customer at 120 units pays $800 under a graduated reading: $700 for the first hundred plus $100 for the next twenty. Under a volume reading, the whole quantity is priced at $5, so the charge is $600. The same bands can be $200 apart depending on the mechanism.