Tiered Pricing

One price is the wrong price for everybody. It's expensive for a small team and cheap for a large company. One side pays while leaving half the features untouched, and the other side pays the same amount while asking for capabilities only it needs.

Pagedeck started with a single price: $10 per person per month. A three-person team paid $30 a month, created a handful of documents, and often left saying it cost too much. A 200-person company, meanwhile, asked for permissions by department and an access log, and building those changed nothing about what came in. Sofia was handling two kinds of customer from one price sheet, with no grounds to discount for the small team and no grounds to charge the large one more.

Tiered pricing splits that single row into levels. Each level carries different features and limits at a different price. A small team picks a lower level and pays for what it needs; a large company picks an upper level that contains what it asked for. It's a way to hold groups with very different willingness to pay inside one price sheet, without negotiating per customer.

You choose one axis for dividing the levels, bundle features and limits along that axis, and attach a price to each level. Five steps.

1. Choose exactly one axis. Divide by team size, or divide by which capabilities are needed. Mix two axes and customers can't tell which row is theirs, and the ones who can't tell tend not to choose at all.
2. Bundle the features per level. An upper level has to contain everything in the levels below it. Break that and a customer who moves up loses something they were using, and from then on the price sheet takes explaining.
3. Set the limits. Cut them numerically: up to 100 documents, up to 5 gigabytes. A limit is what lets a customer see for themselves which level they're on, so build the remaining-amount display along with it. A limit nobody can see does no work.
4. Attach prices. Keep the multiples between levels simple. Pagedeck opened the base level free, priced the team level at $10 per person per month, and doubled to $20 for business. Complicated multiples take time to work out, and when the arithmetic takes too long people close the tab instead of choosing.
5. Land on three or four levels. Two loses the customers caught in the middle; five raises the number of people who choose nothing at all. Three is the common landing spot.

What goes into the upper level decides whether this works. Anything that only becomes necessary at scale moves up — permissions by department, access logs, signing in once with a company account. Put something genuinely required to use the product up there instead and the lower level becomes useless, so nobody starts on it.

Levels usually sit on top of a subscription, the arrangement where a fixed amount is charged every period. Combined with seat-based pricing, which charges in proportion to account count, the invoice comes to the level's per-seat rate times the number of people.

The first place is the pricing page. Levels go up as columns, with what each one includes listed under it. One column usually carries a recommended marker, which is where a default gets handed to anyone having trouble deciding.

Three other places.

1. Sales conversations — Sofia settles which level a customer is on before anything else. Once that's fixed, the conversation is about what's in that level rather than about the price.
2. Expansion revenue — an existing customer moving up adds revenue without a new customer arriving, so alerts get wired up as customers approach a limit. A team that has created 90 documents hears that ten remain.
3. The boundary with add-ons — some customers find moving up a whole level heavy when they need exactly one more thing. An add-on, an optional item sold on top of a plan, sells that one thing by itself. An extra 100 gigabytes of storage is the usual example. Add-ons are also how the gaps between levels get patched after the fact.

Some products don't suit it. Ones where every customer needs something different won't group into levels. Where consumption decides most of the bill, usage-based pricing — charging for what was actually used — fits better; layer levels onto that kind of product and the heaviest users hit a ceiling and leave.

"This customer has eight people and needs department permissions. Which level do I point them at?"

Two axes have gotten mixed together, so the price sheet has no answer.

"Cut the document limit at 100 and you'll see which teams move up at that line."

Using a limit as the trigger for upgrading.

"Put that feature in business. If it's in team, nobody has a reason to move up."

A decision about what creates the difference between levels.

Pagedeck turned its single price into three levels. Base is free with up to 100 documents, team is $10 per person per month with unlimited documents, and business is $20 with permissions by department and access logs. Grace wanted a fourth level and Mia held it at three.

Over the next three months, churn among small teams dropped, and the 200-person company moved to business and doubled what it paid. What the sheet still couldn't answer was which level an eight-person team needing permissions belonged to, and that gap got filled with an add-on.

The most common belief is that more levels sell more. It seems as though a row for every customer means nobody gets missed. But choosing is itself a cost to the customer. In a table of five columns, working out which column is yours takes time, and when it gets hard people postpone rather than pick. Leave it alone and the count of visitors who chose no level at all goes up.

The other common reading is that the upper level should simply hold all the good features. Selling the upper level is the goal, so it follows naturally. But a customer who found no use in the lower level won't buy the upper one either. The lower level is where the product gets started, and something has to work there before an upper level becomes worth looking at. What moves up is not the better feature but the one that only matters at scale.