A decade-plus of business later, the verdict is in…
The unscalable maintenance of our Soft Limit Policy counterintuitively allowed QuotaGuard to grow for a decade and gain a faithful customer following.
I doubt Paul Graham was thinking about pricing plan limits when he penned his famous “Do Things That Don’t Scale” essay, but here we are regardless…
When QuotaGuard started back in 2012, we started with the idea of “soft limits” on customer usage. The idea was, if customer usage went over what they’ve pre-paid for, we manually intervened and delayed pausing their subscription. This gave them time to upgrade.
But let me tell ya, manual intervention is not f***ing scalable.
What is the Soft Limit Policy, Exactly?
QuotaGuard is a mission critical service for many of our customers. Cutting them off never felt like the best way to telegraph that QuotaGuard was moving towards the same goal as they were.
Now…if a business isn’t that critical, then this is not a big deal, and there’d be no need for soft limits.
In those companies, when a customer uses up their 200 credits, they need to upgrade their plan. It’s that simple.
But because so many customers use QuotaGuard as a critical service, I didn’t want to operate that type of model.
So we started the Soft Limit Policy. Customers would have a grace period of a few days to upgrade before their service would be suspended. We would email them multiple times, contact them via any means available (X, Facebook, their own support channels, etc) to notify them how to upgrade in time.
For the first few years, the soft limit plan worked great. When you have a few hundred customers, only 2 or 3 are going to exceed their limit each month and it’s easy to manually step in and intervene any upcoming suspensions.
Unscalable is Great, When You’re Small and Have Time. But….
Fast forward 13 years -> Now Quotaguard has thousands and thousands of customers. A small subset of them blow through limits on a daily basis. We now have the challenge of doing something that’s completely unscalable at a really high repetitive cadence.
Soft Limits became an unscalable task and a huge burden on the smooth operation of the business.
A few years ago, I considered dropping the soft limit promise. We could have switched to programmatically suspending customers any time their subscription usage exceeded their plan.
Fortunately, I re-read Paul’s article and took a little inspiration from it. I opted to continue intervening and allow the soft limits policy to stay.
Trust me – even after re-considering – there are still times where I’ve dreamed of just making it a hard limit. When customers hit that limit, the service would stop running until they upgraded.
But the business owner in me just wouldn’t allow me to do that. Not because I’m some virtuous business leader. But because I’ve seen how many customers have gone over their limits and simply needed a few days for an authorization to upgrade their plan.
Many times we’re all so busy we don’t even know we’re in the red on our service limits.
It’s rarely malicious or a case of customers trying to “pull one over on us“.
By keeping the lights on, their sites and services never failed. We gained considerable trust and favorable reputation with each of those customers.
Why We Choose to Do the Unscalable and Why It Matters
Had we pragmatically suspended each customer – even if they immediately upgraded – their site still could have been down for hours.
Instead of going that direction, the back-and-forth communication cemented many of our best customer relationships.
I believe our Soft Limit policy helps our customers see we’re real human beings behind the scenes. Real people trying to operate a real company to help them accomplish their business goals.
I can attest to hundreds of thousands of extra income based solely on the goodwill created by the soft limit policy.
This unscalable process in the short term, earned us a lot more money in the long term.
That’s why this is important to write about and I’m fortunate to have taken Paul’s advice so many years ago and run with it…
Photo by Pavan Trikutam on Unsplash