Billing Model

When software shipped on discs and installers, there was exactly one way to collect money. You sold a copy, the customer paid once, and the relationship was over. Setting the number was the whole job. Nobody on the selling side knew how many people opened the program, and nobody needed to know.

Moving products onto the web broke that arrangement. The service stays switched on, so money can be collected every month instead of once. Every login, every file, every export leaves a record, so there are now dozens of things a company could count. The moment more than one answer became possible, two questions that used to be a single question pulled apart: how much to charge, and what to charge for.

Teams that skip the second question hold meetings that sound settled and aren't. One product team walked out of a pricing session agreeing on twenty dollars a month. Engineering built the invoice calculation around twenty dollars per account. Sales went out with proposals quoting twenty dollars per company. For a customer with thirty employees, one reading produces a six-hundred-dollar invoice and the other produces a twenty-dollar one. The same sentence, off by a factor of thirty.

The choice of unit does more than set how much money arrives. It changes how customers use the product. Count accounts and an administrator starts rationing logins, handing them out only to people who clearly need one. Count consumption and the same person hesitates before uploading one more file. Neither behaviour is what the seller wanted, and both follow directly from the unit. So the question to ask about a candidate model is not only how much revenue it produces but what it teaches customers to economise on, because that lesson shows up in the usage data long before it shows up in a renewal conversation.

A billing model is the decision that closes that gap. It names the unit — the account, the gigabyte, the export, the month — before anyone attaches a number to it. Once the unit is fixed, everything downstream sits on top of it: the formula that produces the invoice, the wording on the signup page, the questions sales asks a prospect on the first call, and the revenue forecast for next quarter. That stack is also why changing a billing model later is hard. You aren't editing a number, you are lifting out everything built on top of it.

The eight terms under billing model all belong to one group: types. Three questions separate them. What gets counted, how much is open before anyone pays, and what gets sold on top of the base plan.

Counting comes first, because it produces the number on the invoice. Four types split along this line.

1. Subscription — a fixed amount on a fixed cycle. Ninety-nine dollars on the first of every month, the same figure whether the customer used the product daily or never opened it. Customers know next month's bill today, and the seller can calculate next quarter's revenue today. Most of the other types on this list sit on top of a subscription and vary it, which makes this the widest term of the eight.
2. Seat-based pricing — the count is the number of accounts. Ten dollars a seat means a thirty-person company pays three hundred dollars. The appeal is that revenue grows when the customer's own company grows, without the seller doing anything. The cost is that customers have a reason to share one login among several people, so products on this model usually add something that makes sharing awkward, like blocking simultaneous sessions or attributing every edit to a named account.
3. Usage-based pricing — the count is how much of the product was actually consumed. A rate per gigabyte stored or per thousand exports, multiplied by whatever the meter read that month. It works the way an electricity meter works, so a quiet month costs close to nothing. Customers tend to find it fair, but neither side knows the amount until the bill arrives, and the seller's revenue forecast gets noisier along with it.
4. Credit model — the customer buys a balance up front and spends it down. A hundred dollars of credit, a hundred units deducted per export. The counting works like usage-based pricing, but the cash arrives first. The seller collects earlier, and the customer gets a ceiling they set themselves.

How much is open before payment is the second question. It sorts three more types by where the line between free and paid falls.

5. Tiered pricing — features bundled into named levels. The entry level caps documents at a hundred, the top level removes the cap and adds permission controls. Two tiers keep the choice simple but leave the middle of the market unserved; five tiers leave people staring at a comparison table and picking nothing. Three or four is the usual landing spot.
6. Freemium — the base product stays free with no end date, and only the advanced features cost money. Somewhere around three or four paying customers per hundred free users is a common result, so the model only holds up when the company can carry the server bill for everyone who never pays.
7. Free trial — the whole product opens for fourteen or thirty days and then closes. The line against freemium is what does the cutting. Freemium cuts by feature; a free trial cuts by time. That difference is also the risk: if the customer doesn't feel the product's value inside the window, the trial ends with nothing to show for it.

What sits on top of the base plan is the last question.

8. Add-on — an optional item sold separately from the plan. An extra hundred gigabytes of storage, a dedicated support contact. It exists for the customer who needs one more thing but not a whole tier upgrade, which makes it the patch over the gaps in tiered pricing.

Real products rarely pick one of the eight. A collaborative document tool might count seats, stack three tiers on top of that count, leave the lowest tier free forever, and sell storage separately — four of these types running at once. So choosing a billing model is not choosing one item from a list. It is settling three things at once: the unit you count, the boundary you open, and the extras you attach.

The three questions can't be answered in isolation, because settling one narrows the options on the other two. Count seats and then draw the free boundary at a seat limit, and customers simply open several free workspaces to stay under it. Count consumption and then reserve bulk processing for the top tier, and the heaviest users — the ones generating the most revenue per month — hit a tier wall and leave. Teams that answer one question and defer the rest usually discover the conflict after the pricing page is already live, which is the expensive moment to find it.

"Should this one be seats or usage?"

The unit hasn't been decided yet, and the speaker wants to look first at whether this customer is headcount-heavy or has consumption that swings month to month.

"The price stays the same. We're only changing the model."

Ten dollars a unit holds, but the unit moves from accounts on the roster to activity actually recorded.

"This account doesn't fit the model, so it goes on a custom contract."

The standard plan's unit can't describe how this customer uses the product, so the deal gets written separately.

Pricing reviews at Pagedeck open with the same question every time. Mia writes "what are we counting?" on the board and lists the candidates underneath. Today the answer is seats, and that answer is starting to leak: companies buy twenty accounts, five people actually use them, and renewal conversations keep turning into cancellation conversations.

Sofia brings what she hears from accounts. Administrators ask why they pay for chairs nobody sits in, and then postpone the decision anyway, because cutting seats now means taking away a seat someone might need in two months. Theo points at the plumbing. Charging only the people who opened a document means aggregating access logs every month and freezing the count before the invoice runs, and the current system needs two months of work before that is possible. Grace asks about revenue. Seats let her calculate next quarter today; metered usage makes that forecast move.

The meeting ended with one line of policy. Seats stay as the unit, but any account with no activity for ninety days drops off the next invoice automatically. Instead of replacing the unit, they narrowed its definition, which cost Theo two weeks of work rather than two months and left the revenue forecast intact.

The most common mistake is reading the billing model as the pricing page. Customers see tier names and dollar figures, so that screen looks like the whole thing. The screen is only the output. The model lives in the rules that produce those figures. Behind "ten dollars per seat" sit questions like when a seat counts as occupied, what a customer pays when someone joins mid-cycle, and whether removing a seat refunds the rest of the period. Leave those unwritten and the page stays clean while the invoices disagree with each other, and every support ticket gets answered by whoever invents a rule on the spot. Once enough of those answers pile up, nobody can tell which rules were decided and which were one-off concessions, and the next person to touch the billing code has to reverse-engineer the policy from the invoices.

Assuming the model can be swapped later goes wrong just as often. It looks like editing one field, so it feels reversible. In practice, changing the unit moves everything stacked above it. The invoice calculation and the payment integration get rewritten, signed contracts describe a unit that no longer exists, and two years of revenue history stops lining up with the new basis, so nobody can read the growth trend across the change. Every existing customer needs an explanation of why this month's bill differs from last month's. A model change usually consumes a full quarter, and other development stops while it runs. That quarter is the bill for deciding the unit casually at the start.