Your freemium product is growing. Users love it. But when they hit your pricing page, they pause.
"$15 per user per month" doesn't align with how they use your product. Small teams with heavy usage feel overcharged. Large teams with light usage look at seat-based pricing and decide they can't afford to expand.
This is the fundamental problem with seat-based pricing in product-led growth: it charges for access, not value. The customer who uses your product daily pays the same as the customer who logs in monthly.
Usage-based pricing flips this model. Instead of paying for seats, customers pay for consumption. Use more? Pay more. Use less? Pay less. Price scales with value delivered.
When implemented correctly, usage-based pricing removes friction from expansion, aligns revenue with customer success, and creates product-led monetization that feels fair to customers.
Here's how to design usage-based pricing that works for PLG.
Why Seat-Based Pricing Breaks in PLG
Traditional seat-based pricing made sense for enterprise software sold through sales. IT departments bought licenses for defined user counts. Sales negotiated volume discounts. Annual contracts locked in commitments.
In product-led growth, this model creates friction at every stage:
Problem 1: Expansion requires adding seats Customer wants to add teammates → Hits paywall → Must contact billing → Upgrade friction → Delayed expansion
Problem 2: Customers manage seats instead of using product Teams share logins to avoid adding seats. Admins remove inactive users to manage costs. Everyone focuses on seat management instead of product value.
Problem 3: Pricing doesn't reflect actual value Power user generating 10x value pays same as casual user. Team using product 2 hours/month pays same as team using it 40 hours/week.
Problem 4: Free-to-paid conversion feels sudden User invites 6th teammate → Forced to paid plan → Sticker shock → Abandonment
Usage-based pricing solves these problems by tying cost directly to product consumption.
The Usage Metric Framework
Choosing the right usage metric is critical. Your pricing metric should:
Align with customer value delivery - What metric best represents the value customers get from your product?
Grow as customer succeeds - As customers get more value, does metric naturally increase?
Be easy to understand - Can customers predict their costs and understand what they're paying for?
Be hard to game - Can customers artificially manipulate the metric to reduce costs?
Common usage metrics by product type:
Communication tools: Messages sent, minutes of video calls (Slack uses message history, Zoom uses meeting minutes)
Infrastructure products: API calls, compute hours, storage GB (AWS, Stripe, Twilio)
Analytics platforms: Events tracked, data rows processed (Mixpanel, Segment)
Content tools: Files stored, exports generated (Canva uses downloads)
Automation tools: Tasks run, workflows executed (Zapier uses tasks/month)
Bad usage metrics:
Logins: Doesn't reflect value, easy to game by staying logged in
Time spent in product: Penalizes efficient users, hard to track accurately
Features used: Too complex to price, doesn't correlate with value
Generic "usage": Too vague, customers can't predict costs
The Hybrid Pricing Models
Pure usage-based pricing (pay for exactly what you use) works for infrastructure products but can be scary for SaaS buyers who want cost predictability.
Most successful PLG companies use hybrid models:
Model 1: Base + Usage Overage
Structure: Fixed base subscription + pay for usage over included amount
Example: Mailchimp's model
- $20/month base includes 10,000 email sends
- $0.002 per email over 10,000
Pros: Predictable baseline cost, scales with heavy usage
Cons: Customers fear overage charges, requires usage monitoring
Model 2: Tiered Usage Bands
Structure: Tiers based on usage levels, price per tier includes usage range
Example: Intercom's model
- Starter: 500-1,000 people reached, $79/month
- Growth: 1,000-5,000 people reached, $249/month
- Scale: 5,000-10,000 people reached, $499/month
Pros: Predictable pricing tiers, easy to understand
Cons: Customers near tier boundaries hesitate to expand, cliff pricing can hurt
Model 3: Pure Consumption
Structure: Pay only for what you consume, no base fee
Example: AWS model
- EC2: $0.10 per compute hour
- S3: $0.023 per GB stored
- Lambda: $0.20 per 1M requests
Pros: Perfect alignment with value, zero waste
Cons: Unpredictable costs scare some customers, requires sophisticated billing
Model 4: Credits System
Structure: Buy credits, spend them on usage
Example: AI tools like OpenAI
- Buy 1,000 credits for $100
- Different actions cost different credit amounts
- Top up when running low
Pros: Prepayment reduces billing complexity, flexible usage across features
Cons: Credits complicate pricing transparency, can feel like gamification
Designing Your Usage-Based Model
Step 1: Identify your value metric
What do customers get from your product? Map usage to outcomes:
- If your product saves time → measure time-related actions
- If it generates leads → measure leads or conversations
- If it processes data → measure volume or complexity
Step 2: Analyze usage distribution
Pull data on current customer usage:
- What's the median usage? 75th percentile? 95th percentile?
- How much variation exists between customers?
- Do usage patterns differ by customer segment?
This tells you where to set tier boundaries.
Step 3: Model revenue impact
Compare revenue under different pricing models:
- Current seat-based revenue
- Projected usage-based revenue at different price points
- Impact on small vs. large customers
Watch for: Does usage-based pricing help or hurt your best customers?
Step 4: Set tier boundaries
Based on usage distribution, create 3-5 tiers:
- Tier 1: Covers 50% of customers (self-serve)
- Tier 2: Covers next 30% (sweet spot for growth)
- Tier 3: Covers next 15% (premium tier)
- Enterprise: Top 5% (custom pricing)
Leave headroom in each tier so customers don't immediately hit limits.
Step 5: Build usage visibility
Customers need to see their consumption:
- Real-time usage dashboard
- Projected costs based on current usage
- Alerts when approaching tier limits
- Historical usage trends
Without visibility, customers fear bill shock and avoid using product.
Communicating Usage-Based Pricing
Customers trained on seat-based pricing need help understanding usage-based models:
On pricing page:
Bad: "$0.002 per email sent" (Customers can't calculate what they'd pay)
Good: "Most customers send 50,000 emails/month and pay $100/month. See pricing calculator ↓" (Anchors cost to typical usage)
In-product:
Bad: Hidden usage meter customers don't see until billing Good: Prominent usage widget showing consumption and tier status
During onboarding:
Bad: No mention of how pricing works Good: "You're on our Starter tier with 10,000 emails/month included. Here's how to track usage."
At tier boundaries:
Bad: "You've exceeded your limit. Upgrade now!" Good: "Great news—you're getting more value from [Product]! You've used 9,500/10,000 emails this month. Ready to upgrade to Growth tier for unlimited sending?"
Frame expansion as success, not punishment.
Handling Free Tiers with Usage-Based Pricing
Free tiers are trickier with usage-based models:
Approach 1: Generous free tier with hard limits
- Free: 1,000 actions/month
- Hit limit → Product stops working
- Must upgrade to continue
Pros: Clear free tier, strong conversion trigger
Cons: Hard stops frustrate users, may lose customers who hit limits unexpectedly
Approach 2: Free tier with soft limits + feature gates
- Free: Basic features, 500 actions/month
- Paid: Advanced features, 10,000 actions/month
Pros: Free users can keep using basic product, feature differentiation drives upgrades
Cons: Complex packaging (usage + features)
Approach 3: Time-based free trial of full usage
- Free: 14-day trial, unlimited usage
- After trial: Must pay based on usage
Pros: Users experience full value, clear upgrade moment
Cons: Shorter free evaluation period
Most PLG companies use Approach 2: combine usage limits with feature differentiation.
Common Usage-Based Pricing Mistakes
Mistake 1: Choosing a metric customers can't predict
If customers can't estimate their usage, they won't sign up. Make the metric predictable and visible.
Mistake 2: Creating too many tiers
Seven pricing tiers confuse customers. Stick to 3-4 clear tiers plus enterprise.
Mistake 3: Cliff pricing between tiers
If jumping from Tier 2 ($99) to Tier 3 ($499) offers little incremental value, customers won't upgrade. Make tier jumps proportional to value increase.
Mistake 4: No usage visibility
Customers need dashboards showing current consumption, projected costs, and usage trends. Without this, usage-based pricing creates anxiety.
Mistake 5: Penalties for scaling
If using your product more makes customers worry about costs, you're penalizing success. Frame increased usage as positive growth.
Measuring Usage-Based Pricing Success
Revenue per customer: Are customers paying more as they use product more?
Expansion revenue: What % of revenue comes from customers expanding usage vs. new customers?
Free-to-paid conversion rate: Does usage-based pricing convert better than seat-based?
Churn at tier boundaries: Do customers churn when approaching usage limits?
Product usage: Do customers use product more freely with usage-based pricing vs. rationing seats?
The Reality
Usage-based pricing aligns cost with value better than seat-based models, but it requires sophisticated billing infrastructure, clear usage tracking, and customer education.
Done well, it removes expansion friction, scales revenue with customer success, and makes pricing feel fair.
Done poorly, it creates billing anxiety, unpredictable costs, and customer hesitation.
The decision isn't whether usage-based pricing is "better" than seat-based. It's whether it better reflects how your customers derive value from your product.
If your customers would pay more as they use more, and that usage is measurable and predictable, usage-based pricing unlocks PLG growth that seat-based pricing constrains.