When creating a product or service there’s a point in time, usually pretty early in the process, when you start to form your pricing model. If you haven’t gone through it before it’s something that you very easily can get wrong. The first thing to get right is the price and the value proposition but that’s not what were going to talk about today, today it’s everything else and the presentation of your model.
Before we dive in here’s a little background. This is from my experiences with Resgrid which is a cloud service company providing logistics and management tools to first responder organizations like volunteer fire, career fire, EMS, search and rescue, public safety, disaster relief organizations, etc. It was founded in 2012 by myself and Jason Jarrett (staxmanade).
So my experiences are more related to SaaS subscription pricing models and starting from the ground up, making plenty mistakes along the way. Jason and myself are both experienced developers, but this is our first real foray into starting a complete company around a service.
When we started developing Resgrid we decided on a price we believed would have a great value proposition and provide a public service (proving a free plan to small first responder organizations). Next we started designing our tiers and limiters for each tier. This is where it’s easy to add confusion and thus paralyze your potential buyers into inaction.
Here’s a scenario; you’re a volunteer fire department with 15 Personnel, 2 Stations and 2 Units. Which of the following Resgrid plans is for you? Can you figure it out at just a glance?
Don’t feel bad, I built the system and it still takes me a solid second to decode the leftmost option. When we launched our paid service at the beginning of the year and the feedback started trickling in. First, WTF are roles, and then what are groups. We heard those questions a lot. If your having to explain your pricing model, either the model is failing or the presentation is.
For Resgrid the Roles just wasn’t a good limiter, it’s was confusing and fuzzy when a department would need to push that and get an upgrade. Your limiters needs to be easy to understand and have well known and easy to identify trigger points; “I hired a new person”, “I added a new station”, “I got a new Unit” are all good, easy to understand limitations on the tiers. If it’s some arbitrary or fuzzy value, then chances are it was just added to try and more reasons to upgrade and not as a real value on a tier.
The other change we made was to rename Groups to Stations. We all know that naming and terminology is important, but when someone is using it to make a purchasing decision it’s vital. The names and terminology your using should be, or easily equate to, what your customers use. We weren’t doing that with Groups, as their primary use is to map to stations but the name was our term, not a standard industry term and thus had to explain it to our potential customers.
Below is my list for creating a pricing model, I’m sure it will evolve over time, but take these into considerations when designing your own.
- Get Your Price and Value Proposition right
- Keep your tier limiters small (no more then 5)
- Present them well (side by side/easy comparison)
- Limiters equate easily to customer trigger points
- Terminology used equates to what your customers use
Good luck on creating your pricing model, and if you feel it’s not working for you don’t be afraid to change and alter it. The worst thing you could do is leave a pricing model that driving potential customers away in place.