I recently had the opportunity to consult with a local startup around their plans for pricing their cloud-based home health monitoring application.  They have an amazing product and great early traction with beta customers, and are now at the point of thinking about pricing as they sell direct and through partners, adding two dimensions to their pricing equation.  Adding another dimension is their incorporation of add-on services, and how to pass along those fees while also adding a markup – for both themselves and their partners.

70's Kmart Pricing by Roadsidepictures (via Flickr CC)

As is usually the case, once they started thinking about their pricing strategy and all of the associated touchpoints, the problem quickly expanded beyond “what do we charge the customer?” to “wow, there’s a lot we didn’t consider!”

Who’s Important? The Customer!

There are a few ways to go about pricing for a cloud-based app, but generally it’s about getting down to the perceived value and making the pricing model match your customers’ or partners’ mindset.  If you try to price based on your needs or benefit, you might end up confusing the customers.  If they match, that’s rare but fantastic.  Always remember that your customers will evaluate your pricing based upon their perspective, not yours.

It’s also important to understand what your customers are using for their perceived model when evaluating your pricing.  If you’re selling cars, they expect to see a sticker price and to pay much less than the number they see.  If you’re selling mobile apps, they expect it to either be free or close to 99 cents, and they further expect updates to occur frequently.  Why?  Because that’s how mobile apps are generally offered, and that has become the accepted “model.”

Consider the typical legacy pricing model of days gone by, where you paid a large, up-front fee for the software and any required hardware, then paid additional fees based on number of locations or users.  There may even have been recurring fees for add-on services.  This model was mostly in favor of the seller, but became the de facto pricing model for both consumer and enterprise software applications.

Enter “the cloud,” where hardware fees disappear and the service becomes more akin to a utility than a product, and where the SaaS trailblazers, like Salesforce.com, set the stage for per-user and ala carte functionality-based subscription pricing.  For better or worse, this is now the standard model for pricing cloud-based applications, either enterprise or consumer.  It’s not a product, it’s a service.  And, it’s not an outright purchase, it’s a recurring utility where I pay for what I use and can turn it off when I no longer need it. Furthermore, especially on the consumer side, people are becoming more and more comfortable with subscription pricing for apps like cloud-based backup, photo storage services, VoIP, and others.

Bottom Line

The greatest area where the cloud has turned software pricing on its head is transparency.  SkypeSalesforce.com, GoToMeeting, Mozy and other sites tell you up front exactly what their services cost.  There’s no dickering, no slimy negotiations with tacky sales reps, and no queasy feeling after you commit that you’ve somehow paid more than the next person. If there’s anything to take away, it’s that your pricing should be front and center on your website!  Tell everyone what they get, why it’s amazing, and how much it will cost.  Add a few tiers to make it easier to understand.

So what’s the bottom line here?  I’m not sure.  I know that I want software and apps to be priced based on my perception of value, and that I’m willing to pay a fair price. I naively assume that most people think the same way.  I’m willing to pay a subscription for something that I use on a regular basis, but I’m also willing to accept less usability for a lower price (or better yet, free).  In the end, I just want a good product at a fair price.  Is that too much to ask? 😉

What do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>