Add-on

A price list built only out of tiers never quite fits anyone. Tiered pricing bundles features into levels, so moving up one level hands the customer ten things at once. If they only wanted one of them, they still pay for ten.

In sales conversations the mismatch always arrived as the same sentence: we need twice the storage we have now, the next tier costs three times as much, and we won't touch anything else in it. The seller had two answers. Recommend the higher tier and lose the deal, or discount it and carry that discount into every renewal that follows. Neither answer scales, and both of them hide the same fact — the price list was built around bundles the buyer never asked for.

Splitting tiers more finely broke something else. Go from three levels to six and a first-time reader can't tell which row is theirs, and when the choice gets hard people choose nothing. Add-ons came out of the gap between those two failures. Keep three or four simple levels, then pull the items that vary company by company out of the levels and sell them on their own.

Each item carries its own price on top of the base fee, and the two amounts arrive on one invoice. Three pieces make that work.

1. The base charge underneath — an existing model such as subscription or seat-based pricing stays exactly as it is. A subscription charges a set amount each period; seat-based pricing charges in proportion to the number of accounts using the product.
2. The unit and its price — decide what counts as one and what one costs. A hundred gigabytes of storage at 50,000 won a month, or a dedicated contact at 800,000 won a month, gives the customer a unit clear enough to work out how many they need.
3. Aligning the cycle — an add-on attached mid-month is prorated across the remaining days on this invoice, then bills in full from the next one. Skip that math and you either undercharge or overcharge by the number of days since it was attached, and the question comes back to you.

Take one Pagedeck customer: 30 accounts at 10,000 won per seat is a base of 300,000 won a month. Two storage add-ons put another 100,000 won on top, so the invoice reads 400,000. The higher tier would have been 900,000, so the customer keeps 500,000 won and the seller collects 100,000 a month it was about to lose.

Step 2 is the hard one. Pick the wrong unit and the customer can't judge how many to buy. "Extra storage" with no amount attached does that, and so does a unit like a thousand exports when nobody knows their own export volume. In those cases a metered approach such as usage-based pricing or a credit model fits better, because the customer no longer has to predict a number before buying.

Add-ons carry whatever one company needs and most companies don't. Those items usually fall into three groups.

1. Capacity and limits — storage, retention windows, monthly processing volume, anything that scales with how much a customer uses. These resist bundling because two companies on the same tier can differ tenfold.
2. Services with people in them — a dedicated contact, migration help, on-site training. The cost here is someone's hours, and folding it into the base fee makes every customer who never asks for it share the bill.
3. Compliance and security requirements — audit logs, external identity integration, a separate storage region. Only large accounts ask, and they usually bring the budget with them, so pricing these items at the level of the work they require rarely stalls a deal.

None of this is limited to the moment of signing. More often an existing customer grows into a limit and attaches the item then, and the increase lands as expansion revenue, meaning revenue collected from current customers rather than new ones. The step is smaller than an upsell to a higher tier, which makes it the first offer to a customer who hesitates at the bigger jump.

"The higher tier is a stretch for you, so let's attach the storage as an add-on instead."

Save the deal by adding one item rather than moving the whole account up.

"Should this ship as an add-on, or does it belong in the base plan?"

Decide whether everyone gets the feature or only the customers who pay for it.

"Add-ons are 18 percent of revenue and they're the first thing cut at renewal."

That money is real but softer than the recurring base.

At Pagedeck, Mia and Sofia go through this list once a quarter. Sofia brings the items customers asked about during the quarter's deals, and Mia decides which of the frequent ones belong in the base of the next pricing revision.

Last quarter audit logs came up in nine of twelve deals. At nine, the item is already standard, and leaving it as an add-on means running the same negotiation nine more times. So it moved into the higher tier and the tier price went up. On-site training appeared twice, so it stayed where it was. Two deals out of twelve is not a pattern, and charging the ten companies that never ask for it would be the worse mistake.

One misread treats add-ons as patches for gaps in the price list, so more of them must be better. Every item added widens the set of combinations, which looks generous. But once features that belonged in a tier get carved out and sold separately, customers don't read flexibility — they read a request for more money. A price list with ten add-on lines looks like it's hiding the real total from anyone trying to compare, and that impression turns into leverage during the deal review.

The other misread treats add-on revenue as a bonus that needs no attention, since the base fee looks like the trunk and the add-ons like branches. In practice add-ons are the first line cut in a renewal negotiation. When a customer has to reduce spend, removing accounts is hard and deleting one storage line is easy. Accounts carrying a lot of add-on revenue look steady by average revenue per user (ARPU) — the average revenue one user brings in — right up until renewal, when several lines disappear at once. The heavier the add-on share, the more worthwhile it is to check ahead of renewal whether those items are actually being used.