Users outgrow tiers or never reach them
Charge based on what they use. They grow, you grow. No awkward tier jumps.
When to use
Your product has clear usage units and customers vary widely in consumption.
Hypothesis template
If we switch from fill in: fixed tiers to fill in: usage-based pricing, revenue will increase because customers can grow without friction.
Method
The problem: User is on the $50 tier. They need slightly more. Next tier is $150. That's a 3x jump. They leave instead.
What Twilio, AWS, Stripe do: Pay for what you use. Send 100 messages, pay for 100 messages. Send 10,000, pay for 10,000. Smooth scaling.
Why it works:
- Low barrier to start (pay-as-you-grow)
- No wasted capacity (users only pay for what they need)
- Revenue scales with customer success
- No awkward tier negotiations
- Upsell happens automatically
The models:
- Per-unit pricing (per email, API call, message)
- Tiered usage (first 1000 at $X, next 1000 at $Y)
- Usage + base fee ($10/month + $0.01/unit)
How to do it:
- Identify your value unit (what do customers consume?)
- Set pricing that feels fair at all scales
- Build metering infrastructure
- Show usage clearly in-app
- Alert before big bills (trust-builder)
- Consider spend caps for budget-conscious users
Warning: Unpredictable bills scare some customers. Offer estimates and caps.
Success metrics
- •Revenue per user growth
- •Customer acquisition (lower barrier)
- •Churn at tier boundaries (should drop)
- •Bill shock support tickets
Prerequisites
- Metering infrastructure
- Clear usage unit definition
- Billing system that handles variable charges
- Usage dashboards for customers
Common pitfalls
- •Bill shock from spikes
- •Unclear pricing
- •No spend alerts/caps
- •Metering that's not transparent
Source: Twilio, Stripe pricing models. Read more
Suggested ICE scores
Ready to run this experiment?
Sign up free to use this playbook with step-by-step guidance and track your results.