appsignal

How We Handle Upgrades at AppSignal

Roy Tomeij

Roy Tomeij on

How We Handle Upgrades at AppSignal

At AppSignal, our pricing revolves around the number of requests we process for a customer and the number of buckets of logging data we store. After their free trial, customers are offered the most fitting plan for them based on their usage in the previous 30 days. About nine years ago, we noticed that many customers were slowly growing their number of requests, but we kept charging them for the plan they started on. We had been focusing exclusively on new customers but noticed we left about €10K of MRR on the table. That had to change, so I wrote our "Relaxed Upgrade Policy."

No one likes surprises, especially when it comes to spending money, so I wanted to come up with the most customer-friendly approach to upgrades in SaaS. I don't know exactly how everyone else handles upgrades, but nine years in, our policy might be the most fair and straightforward of all application performance monitoring and logging providers.

The Ingredients in Our Relaxed Upgrade Policy

There are a few key components in our upgrade policy, based on how we'd like to be treated as a customer:

  • Not being bothered about upgrading because of a one-time spike in requests.
  • Preventing debates about "we're only over quota a little".
  • Knowing beforehand what you're about to spend.
  • Having time to take measures to prevent upgrading.
  • Receiving a reward when proactively agreeing to be upgraded.
  • Not making this a monthly occurrence.

Not Being Bothered about a One-Time Spike

We check every customer's usage at the start of a monthly billing cycle (or the day of the month they signed up when on a yearly billing cycle). We'll only reach out if they have exceeded their plan's limits in two out of the past three months. Looking back over a more extended period significantly reduces discussions about the overages being a one-time occurrence – we can establish they aren't – and we don't "penalize" customers for being the top submission on HackerNews for a day.

Preventing Debates

In addition to the above, we'll let customers go up to 10% over their allocated requests. For instance, you will never hear from us about upgrades if you stay below 275K on the 250K plan, below 55M on the 50M plan, or below 22GB when subscribed to two 10GB logging buckets. Combining this with the two-out-of-three approach, we seldom have a discussion about the proposed upgrade being unfair.

Knowing Exactly What's Coming

When we automatically send a customer an email about a pending upgrade, it includes what they will pay for AppSignal APM and/or AppSignal Logging. It links to our upgrade policy, some more in-depth information in our documentation, and a page in the app with a breakdown of the old and the new plan information. That last one is updated continuously so customers can see if their measures to decrease usage have worked.

Time for Taking Measures

Customers are automatically upgraded after 28 days unless they decrease their usage. We link to documentation about how to decrease usage, e.g., by ignoring endpoints with low business value, such as the regularly requested endpoints for uptime checks. On day 28, we take the averages of the seven days prior to calculate expected usage, so customers have 21 days to deploy changes to limit their requests or logging data, and they can always check in our app to see if they're on track. If they need more time, we can manually snooze upgrades until whatever date we agree on.

Rewarding Customers for Early Upgrades

After 28 days, we automatically upgrade customers to the best-fitting plan based on last week's usage. However, if they proactively click the "upgrade me now" button before then, they qualify for a box of stroopwafels and AppSignal swag. Most customers are happy with being upgraded, and this way, they get something more out of it than "just" a great APM and logging solution. We get to charge the customer (pro-rata) when they click the upgrade button in advance instead of having to wait for another few weeks, which makes up for some of the expenses involved with international shipping.

Snoozing Upgrades for Three Months

After effecting the upgrade, we automatically snooze future upgrades for three months. Even if a customer's usage increases again, instead of getting an upgrade notification the next month, we stay silent for another three. We miss out on some MRR for a short while, but that's a trade-off we're willing to make to keep our customers happy.

Customers Love Our Upgrades Policy

Customers often apologize when receiving an upgrade pre-announcement, saying how sorry they are for having been over quota for a few months already. We always tell them there's no need for that: we're the ones who decided to handle upgrades like this. Those are nicer conversations than if a customer is confronted with an upgrade with no prior warning and after already being charged. Others say our take on automatic upgrades is a breath of fresh air and something they wished other SaaS companies also employed.

I firmly believe that what goes around comes around. Looking at our average customer lifetime, I may be right.

Roy Tomeij

Roy Tomeij

Co-founder who single-handedly turned stroopwafels into the Netherlands' main export product. Dutch southerner who loves (and cooks) BBQ. Improv trainer.

All articles by Roy Tomeij

Become our next author!

Find out more

AppSignal monitors your apps

AppSignal provides insights for Ruby, Rails, Elixir, Phoenix, Node.js, Express and many other frameworks and libraries. We are located in beautiful Amsterdam. We love stroopwafels. If you do too, let us know. We might send you some!

Discover AppSignal
AppSignal monitors your apps