The "Success Penalty": The Hidden Risk of Usage-Based Pricing
"Pay only for what you use" sounds fair—until a product launch goes viral, and your support bill bankrupts your margin.
The pitch is seductive: "Stop paying for idle seats. Only pay when we actually resolve a ticket."
This model, popularized by modern AI helpdesks and consumption-based SaaS tools, promises perfect alignment between value and cost. In theory, if you have fewer tickets, you pay less.
But in practice, this model introduces a dangerous financial dynamic we call the Success Penalty.
The Decoupling of Cost and Control
In a traditional Seat-Based Model, your costs are predictable. If you have 10 agents at $100/month, your bill is $1,000. If traffic spikes, your agents work harder (or queue times increase), but your software bill stays flat. You have cost certainty.
In a Usage-Based Model (e.g., $0.99 per resolution or per conversation), your bill is theoretically uncapped.
Consider these scenarios:
- The "Bad Deploy" Spike: Your engineering team pushes a bug that breaks the login page. 5,000 users flood support asking "Is the site down?" The AI bot "resolves" these by saying "Yes, we are working on it." You just paid $5,000 for a bug your own team created.
- The DDoS Attack: A malicious actor floods your chat widget with spam. If the vendor's bot engages with them, you are billed for every interaction.
- The Viral Launch: Your product goes viral. Traffic increases 10x. Your revenue might double, but your support volume might triple (new users have more questions). Your margins suddenly collapse because support costs grew faster than revenue.
The "AI Resolution" Trap
The risk is compounded by how vendors define "Resolution."
Many AI tools charge per "Automated Resolution." But who decides what counts as resolved? Often, it's the vendor's algorithm.
The Definition of "Resolved"
If a user asks "Do you have an Android app?" and the bot says "No," and the user leaves—is that a resolution? To the vendor, yes (question answered). To you, it's a churned lead. Paying for this "resolution" adds insult to injury.
When to Accept Usage-Based Pricing
Usage-based pricing isn't always bad. It works well for:
- Seasonal Businesses: If you are an e-commerce shop that only needs support in Q4, paying per-ticket is better than paying for 50 idle seats in July.
- Low-Margin, High-Volume Support: If your support is truly transactional (e.g., password resets) and you can strictly control the bot's behavior.
How to Protect Yourself
If you choose a usage-based tool, demand Spend Caps.
Never sign a contract that allows unlimited overages. Negotiate a "Circuit Breaker" clause: "If usage exceeds 120% of the monthly average, billing is capped or paused until manual approval."
Without this, you are handing your checkbook to the internet.
For a deeper dive into how to structure your contracts, read our analysis on Hidden Costs of Per-Agent Pricing.