Run incidents without leaving Slack
Tailored to your organization for smarter incident management
Confident, autonomous teams guided by automations
Learn from insights to improve your resilience
Build customer trust even during downtime
Connect everything in your organization
Streamlined incident management for complex companies
Run incidents without leaving Slack
Tailored to your organization for smarter incident management
Confident, autonomous teams guided by automations
Learn from insights to improve your resilience
Build customer trust even during downtime
Connect everything in your organization
Streamlined incident management for complex companies
Getting your pricing right is critical to the success of any SaaS company, but finding a model that works can be tough. Price too high, you won’t close enough deals - your business will fail. Price too low, your business model will be unsustainable - your business will fail.
To add to the complication, when you’re a new startup your goals are evolving. You’re optimising for different outcomes at different stages of the journey, which changes how much you can and should charge for your product.
In short: there’s a lot to think about, and you’ve got a pretty slim chance of nailing this first time around.
We’ve just changed our pricing model for the third time in the space of year. We’re pretty excited about it - we hope we’ve landed our Goldilocks pricing mechanism. It’s taken us a few iterations to get here, but we’ve learned something at every stage of the pricing journey which has helped us to get to where we are today.
Like almost every startup, when we first launched incident.io we needed one thing: to get customers through the door. Relatively speaking, incident management was an untapped category when we entered the market, so this wasn’t just about testing our product but also understanding if there was appetite for the concept full stop (spoiler alert: there was).
At this stage, we needed folks to test our product, give us feedback and spread the word. We optimised our pricing for getting deals over the line.
At this stage, our pricing was (unsurprisingly) not particularly scientific but we tried to make some sensible decisions by:
✅ We succeeded in getting customers through the door, which allowed us to learn. Our model may not have been perfect, but it achieved what we needed it to. We had customers to speak to and provide us with the feedback we needed to improve.
❌ Structure and consistency in pricing is important. We lacked a structured model and clear narrative on where our pricing had come from. This made it challenging for us to explain and even harder for customers to understand.
❌ We were significantly underselling ourselves. We were still in MVP stage and (having very high expectations of ourselves) considered our product a bit too scrappy to charge too much. But when your customers are telling you your pricing is too low, you know your pricing is too low...
Enter pricing iteration two...
By this point, we know we’re onto something. Our concept is solid, people want to buy our product and getting customers through the door at any price starts to make less sense. We’re also more mature as a company. We have a growing team and importantly, a much clearer vision for the future our business - we’re an incident management tool for your whole organization. It’s this vision that drives the next iteration of our pricing model.
Building on the research and learning we gained through our first attempt, this time we created a pricing model which would charge based on the size of the customer. The bigger your company, the greater the potential value of the tool, the more you pay. Being a Slack native tool we used total number of Slack users as a sensible proxy.
Following some number crunching based on our existing customers, we landed on a four tier pricing model, which offered a different price for customers with 0-24, 25-99, 100-249 and +250 Slack users.
✅ Aim for a simple model which is easy to explain. We had a clear, consistent structure which was easy for potential customers to understand.
❌ Finding a model that resonates with your customers is important. And ours didn’t. Being charged based on the size of your entire organization doesn’t sit well if you only want to buy the product for a small number of teams. On paper, this didn’t look like a fair value exchange.
❌ A “one size fits all” approach to product pricing doesn’t always work. Increasingly, we found we were serving variety of customers of different sizes, industries, geographies and so on. Their needs were different but our customers lacked choice in this model, and we wanted to resolve that.
We go again...
And so we arrive at our newest pricing model.
Although we’re comfortable with the idea of changing our pricing, from a customer and process perspective, frankly it can be a bit of a pain. It isn’t something you want to do on a regular basis. So this time, we really took our time to really think through what a great pricing mechanism would look like for our product.
To define our new pricing mode, we focussed on understanding the value we offer to customers and used data to dig into how different types of customers were engaging with our product features.
In short, we found our greatest value comes from supporting those who are actively involved in trying to “fix the thing” to do it better and stop incidents occurring again in the future. This formed the basis of our new user-based pricing model.
Instead of charging based on organization size, we decided to charge for users who are active incident “responders”, offering three pricing tiers with different levels of feature and service access. This model empowers our customers to choose a package that meets their specific needs and charges based on the value they gain.
We’ll let you know, but we’re getting positive early indications from customers.
It may not be easy, and it will probably bring a fair amount of complexity your way to shift between models and bring your existing customers with you on the journey. But in the long term it will be worth it to find a mechanism that works for you and your customers.
It can be easy to get caught up in the actual dollar amount that you’re charging in your pricing model, but actually this is the part that is easiest to change. Focus your energy on defining the mechanism that you’re using instead - this is where the complexity (and the value) lies.
Ok the mechanism might be key, but you still need to make sure your numbers make sense. You have revenue targets, you need to make sure your new model won’t take you wildly off base.
Work out what value are you adding to your customers, and then find the closest proxy you can to measuring this. Use that as the basis for your pricing model. It will help you to develop a clear narrative that your customers can engage with.
Particularly when you’re first starting out, you’re going to need to test and experiment with pricing. Make sure you’re listening to the feedback you’re hearing from your customers and respond to it.
Image credit: Ibrahim Rifath
Enter your details to receive our monthly newsletter, filled with incident related insights to help you in your day-to-day!
The balancing act of reliability and availability
To prevent issues like downtime, you have to focus on the reliability and availability of your product. But there's a balance to be struck here.
incident.io
The connection between incident management and problem management
While problem management and incident management may seem different, they're two sides of the same coin.
Luis Gonzalez
incident.io: A scalable incident management solution built for enterprises
With incident.io, enterprise businesses have an incident management solution that can navigate their complex needs and improve their response processes.
Luis Gonzalez