Nobody churns over a price they agreed to. They churn over the invoice they didn't see coming. Usage-based pricing earned its reputation for surprises one hidden meter at a time, and every one of those surprises was a design decision somebody made upstream.
The meter must be visible before the invoice
If a feature is metered, the meter is part of the product. Customers should see current usage in the dashboard and over the API, at the same granularity you bill on, updated close enough to real time to act on. A number that only materializes at month end is not a meter, it is a trap with a thirty-day fuse.
This goes double for meters customers don't directly control. Recording hours accumulate because meetings happened, not because someone clicked an upgrade button. The person who scheduled the meeting and the person who pays the invoice are usually different people, and the pricing model has to survive that gap.
Caps first, overage second
Every meter needs an answer to "what happens when I hit the limit," and the answer cannot be "we keep charging." Two options hold up: a hard cap that pauses the feature, or an overage rate that was printed on the pricing page long before anyone hit it. Either works. Discovering the rate on the invoice does not. A cap is also a courtesy to your own support team, because a paused feature starts a conversation and a quadrupled invoice starts a refund demand.
Overage rules should fit in one sentence. If explaining what an extra hour costs requires a table with footnotes, customers will assume the worst, and they will be right often enough to keep assuming it.
Per active account beats per seat
Seats measure who could use the product. Active accounts measure who did. For platform features, where your customer's own end users generate the usage, seats punish growth in exactly the wrong place: the customer pays for provisioned users who never connected anything.
Billing on active accounts lines the invoice up with delivered value. An account that connected email or calendar this month cost you infrastructure and earned your customer something. A dormant account did neither, and charging for it teaches customers to fear their own signup funnel.
Say what does not increase the bill
A pricing page should be as explicit about what is free as about what is metered, because silence reads as risk. If an account can connect more than one provider, does that count once or twice? Whatever the answer, write it down. Every customer doing capacity planning will otherwise assume the expensive interpretation, and size their budget, or their shortlist of alternatives, around it.
Every metered unit also needs a definition a customer can check their own usage against. "Account" and "active" and "hour" all sound obvious until two people read them differently, and the person who reads them differently is always the one holding the invoice.
A worked example
Concrete numbers beat principles, so here is how Horato prices this pattern. The free tier includes 3 development accounts, enough to build against without a card on file. Pro is $10 per month with 10 accounts and 10 shared recording hours. Past those, additional accounts are $1 each, and recording overage is $0.70 per hour managed or $0.30 per hour when you bring your own transcription key. Provider connections do not increase the account count, so one account connected to both Google and Microsoft bills as one.
A customer on that plan can compute next month's invoice on a napkin, which is the entire test. If your customers need a spreadsheet and a support ticket to predict their bill, the model has failed, whatever the rates are.