The Complexity of Monetizing SaaS Application Usage

Apr 4, 2007 by

I’ve been following a series of blog posts by Lars Fløe Nielsen, Michel Baladi and some other folks from Microsoft, Sitecore and other firms. The posts follow a proof-of-concept project established by the firms to investigate how a “SaaS Hosting Platform”, or SHP, ought to look like. I appreciate the effort that has gone into this, and it really hones in on what is important to what parties in a SaaS ecosystem (ISV, hoster, end user, etc.) One particular post that caught my eye was this one. In it, Nielsen describes metering and billing constructs that would be handled by the SHP, as coordinated by the ISV during the definition phase of monetizing the application.

This post is interesting simply because it shows how complicated SaaS monetization, metering and billing can be. Some applications will have “simplistic” scenarios of a flat monthly rate with little variability. Others will need transactional charge capabilities such as a per e-mail or per help ticket opened, or the ability to fluctuate periodic recurring rates based on feature packages. Even still, some applications may need to cut “non-standard” plan agreements with certain customers to close a large sale. Even still – marketing may have the need to institute temporary discounting or model changes, while preserving the original monetization base. All of this and we’ve only discussed defining monetization – metering and billing is a whole other ball game. Metering will generally follow the complexity level defined by the monetization definitions. Obviously, if a SaaS provider is building an app from the ground up. This is where we see plenty of immediate value from the SHP concept – if this can be provided as a part of an out of box experience by a SaaS platform, an ISV can build revenue models that are very unique and specific to their needs. Nielsen’s SHP metering and billing revolves around a standardized definition language of sorts, which is exactly the way to go.

Good SaaS platforms will give the flexibility required to achieve unique and complicated monetization definitions and match that with efficient metering capabilities. Have you built or are you building a SaaS application with a very unique way to charge that you wouldn’t mind commenting about? Have you as an end user or consultant encountered any awkward yet impressively tuned usage models? I’d love to hear about them!

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=""> <strike> <strong>