Costs
Part of Pricing architecture: what the experienced already know for 2027
5 details of pricing architecture examples people miss
Five pricing architecture examples named by the companies that run them reveal the approval problem each structure creates on the buyer's desk.
Pricing structures get compared from the seller's side: which one captures the most value, which one grows with the customer. Compare them from the other chair instead. What does this structure look like on the buyer's desk, how many times does it get approved, and what does the buyer's own finance process do to it?
Five pricing architecture examples, named by the companies that run them, answer those questions: Basecamp, Twilio, Mailchimp, Salesforce and Slack, and Snowflake. Each one carries a detail that stays invisible until someone in procurement asks about it. The same lens sorts the common structures into three groups, and the grouping predicts most of what happens after signature.
What to take away
- Salesforce and Slack sell per seat, and both let a customer share a login rather than buy another one. Salesforce's Sales Cloud lists from about $25 to about $330 per user per month by edition; Slack's Pro plan lists at $7.25. Seat pricing is policed by the buyer, not by you.
- AWS bills pure consumption and every enterprise buyer answers it with a committed floor. S3 Standard lists at about $0.023 per GB per month. The structure that cannot be forecast gets capped, not rejected.
- Snowflake separates storage from compute, so the buyer sees your number and a cloud provider's number on the same invoice. Storage lists near $23 per TB per month, and compute credits near $2 each. Whoever can raise that second number owns the argument.
- Basecamp charges a flat fee that stops at $299 a month, so the buyer approves one line and never counts seats again.
- HubSpot's free tier is a pricing decision, not a marketing one. Paid hubs start around $15 a month per seat. The free tier removes the approval step entirely for small buyers and moves the negotiation to the upgrade.
- A structure that needs re-approving is a structure that gets re-examined. Count approvals before you count revenue.
Approved once, then invisible
1. Basecamp: one flat fee, approved once
Flat fee per period. Basecamp charges one price for a workspace and has done so for years. The published plan runs $15 per user per month and stops at $299 a month, so a large team pays the same as a small one.
The detail buyers miss is the cap: the invoice stops at $299 while the user count does not. The buyer sees one line that never moves, approves it once, and does not look again until renewal. It suits teams that want a single approvable line and no seat counting.
Basecamp lists free accounts for teachers and students alongside the paid plan. The invisibility is the advantage and the risk: nothing reminds the customer what they are getting, so renewal starts from a blank page.
A free tier as an approval shortcut. HubSpot gives its CRM away and charges for the paid hubs, which start around $15 a month per seat. The free tier is a pricing decision, not a marketing one. It removes the approval step entirely for small buyers and moves the negotiation to the upgrade.
2. Twilio: a committed minimum with a drawdown balance
Annual prepayment or committed minimum. Twilio sells usage: a US text segment lists around $0.008, and a US phone number around $1.15 a month. Enterprise contracts are drawn as a committed annual spend with a drawdown balance, so the buyer raises one purchase order and the money leaves the operating line for the year.
The detail buyers miss is the drawdown balance. Publish it where the customer can see it, because a buyer who finds unused balance in December feels billed for nothing, whatever the contract says.
Buyers on an annual budget cycle often prefer this to a monthly charge, which is one of the quieter advantages subscription models hold over per-use ones. It suits buyers whose usage is steady enough to forecast a floor.
3. Mailchimp: tiered bands with published boundaries
Tiered blocks with a stated band. Mailchimp prices by contact count in published bands. The free plan covers 500 contacts, and paid plans have started near $13 a month at that level, with Standard around $20 and Premium around $350. The buyer sees a price for their band and can read what happens if they move up.
The detail buyers miss sits at the boundary. Procurement teams object to this banded shape least of the volume-linked structures, but an account sitting just above a threshold gets a jump it did not cause and asks for the previous band's price.
Approved again later, which means examined again later
4. Salesforce and Slack: per seat, with additions during the term
Per seat, with additions during the term. Salesforce and Slack both bill this way, and both let additions happen without a fresh approval each time. Salesforce's Sales Cloud lists from about $25 to about $330 per user per month by edition; Slack's Pro plan lists at $7.25 per user per month billed annually, and Business+ at $12.50.
Convenient, until someone reviews the total. What buyers miss is that a customer can share a login instead of buying another one, which is a policing problem you did not want and cannot win.
It fails when the people using the product are not the people paying. The account grows in value while the seat count stays flat, and your revenue stays flat with it.
Base fee plus metered overage. Twilio and Stripe both run this shape: a predictable line plus a surprise. Stripe's standard US rate is 2.9% plus 30 cents per successful card charge. The base gets approved once and the overage gets questioned every time it appears. Where overage is small and rare, this is fair and works.
Where it is regular, you have made the customer's finance team review your invoice monthly. They will eventually ask for a cap, and they will get it.
Pure consumption, no commitment. AWS S3 lists at about $0.023 per GB per month, with no minimum. It is the structure most likely to be blocked by an approval process rather than a price objection, because many organizations cannot raise a purchase order without a maximum.
The usual accommodation is a cap or a committed floor, which converts it into one of the structures above. It fails for the seller when the customer's own volumes fall, because your revenue is now tied to their fortunes.
Which of these a buyer can sign at all is a question about the capture event as much as the number, and those are compared in the revenue models overview.
Structures containing someone else's number
5. Snowflake: storage, compute, and the cloud provider's line
A fee plus costs passed through at cost. Snowflake separates storage from compute, so the buyer sees Snowflake's charge and the cloud provider's charge on the same document. Storage lists near $23 per TB per month on demand, and compute runs on credits that list at about $2 each in the Standard edition.
Approval is straightforward. The detail buyers miss is the pass-through, which does not stay fixed. Two things make this survivable: state in the agreement who bears an increase, and pass costs through visibly rather than folding them into your own line.
Anything you fold in is a margin exposure you underwrote on someone else's behalf. The arithmetic sits in unit economics.
A success fee with a floor. The buyer sees a small certain amount and a large contingent one. Approval often needs two people, because the contingent part may sit in a different budget from the retainer.
It fails on measurement. If the trigger is not defined in writing, including who produces the number and what happens when the parties disagree, you have signed up for an argument with a delay on it.
Define the trigger before the amount. A pre-agreed remedy for a defined shortfall is a normal contract term rather than an admission, and it is judged under the rules on liquidated damages.
What the grouping tells you
| Example | Approvals | The buyer's real objection | The seller's real risk |
|---|---|---|---|
| Basecamp, flat fee with a cap | One | Renewal feels like a fresh decision | Heavy users subsidized by light ones |
| Twilio, committed minimum | One | Unused balance at year end | Revenue moves with the customer's volumes |
| Mailchimp, tiered bands | One per band | The jump at the boundary | Accounts clustering below a threshold |
| Salesforce and Slack, per seat | Repeated | Cannot forecast the total | Logins shared instead of seats bought |
| AWS S3, pure consumption | Blocked without a cap | No maximum for the purchase order | Revenue falls with the customer's usage |
| Snowflake, pass-through | Once, then disputes | Exposure to a cost you both watch | Absorbing an increase you cannot pass on |
| HubSpot, free tier | None until the upgrade | The upgrade arrives mid-year | Free users who never convert |
Read down the second column before choosing. A structure that is theoretically superior and cannot clear the buyer's approval process is not superior. It is unsellable to that buyer, which is a different conversation from a price objection and gets mistaken for one constantly.
Choosing between them
Two questions decide most cases. Can this buyer sign for an amount that is not known in advance? And is what you meter something they can see and predict themselves?
If the first answer is no, a cap or commitment must attach to everything in the middle group before it will be signed. If the second is no, expect every variable line to be questioned, and that questioning slows collections.
Neither answer makes a structure wrong. They show what must be added before it works. List prices move, so check each vendor's current page before you quote one in a proposal.
The layers underneath all of these, and how to tell which one is causing a symptom, are set out in the pricing architecture overview.
Common questions
Can we offer more than one of these?
Yes, and two is usually the limit before quoting becomes unreliable. Offer choices that differ in commitment rather than in metric, since two metrics means two billing configurations and two sets of disputes.
Which structure suits a new company?
The one your first buyers can approve without a procurement exercise, which is usually a fixed fee for a stated period. Optimizing the structure before you have a book of customers to observe is work done twice. Structure and level are separate problems, which MIT's pricing course shows well enough to explain why the order matters.
How do we move a customer between structures?
At renewal, with the comparison shown honestly, including the cases where the new structure costs them more. Mid-term migrations produce a surprise invoice, and a surprise invoice goes into dispute before it gets paid. That is one of the business model types mistakes in its pricing form.
