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!

read more

For Your Consumption: Article on Datamation

Mar 16, 2007 by

Just a quick note: Datamation recently invited me to write an article for their website.  The article, entitled Repealing the SaaS Tax, was published a few days ago and it focuses on SaaS enablement, and more specifically, enablement through platforms, so check it out and let me know what you think!

PS: Sorry for the late notice

read more

Does the SaaS Ecosystem Concept Lean Toward Natural Oligopoly?

Mar 2, 2007 by

Rare is the day where using the phrase “SaaS Platform” doesn’t invoke the usage of “SaaS Ecosystem.” Heck, it even found its way to the title of the keynote panel I’m part of at April’s SaaSCon: Understanding SaaS Platforms and Ecosystems. The reason for this “two peas in a pod” syndrome is pretty easy to explain: SaaS platforms aggregate vendors, offerings, and end users in a pseudo-closed system which creates a huge amount of long-term value potential in exercising this network of relationships. This network is what we call an ecosystem and the value that can be created by commanding successful relationships is important to all parties involved.

I was discussing the future ecosystem landscape with someone, and inevitably the question of “How many ecosystems do you think will exist in a few years?” came up. Trying to quantify something like that this early definitely requires painting with broad strokes, but looking at the dynamics my answer is that a handful of ecosystems – a veritable oligopoly – will account for almost all ecosystem participants. In this scenario the oligopoly would not be forced or created through regulation, but would in fact be a natural oligopoly – the result of convergence due to economic factors. Why? Because ecosystems are networks.

A SaaS ecosystem’s value is very much defined by the size of its network, which is composed of three types of members: vendors, applications, and users. Looking at the trivial case, an ecosystem with zero participants of any type is valueless, as is the case of an ecosystem consisting only of suppliers and supply. As a mix of members from the three aforementioned groups start to enter a specific ecosystem, the value of the ecosystem increases. End users have the ability to gain value from relationships defined by participating vendors or deployed applications, vendors themselves can experience synergies by creating relationships with other vendors in the ecosystem. What this does is create a positive feedback loop.

If there are no costly or threatening barriers to joining an ecosystem, non-participants will measure the value of the ecosystem by the number of links it offers – the larger the network, the more valuable (i.e. Metcalfe’s Law). This is the reason why instant messaging, for example, is a natural oligopoly. If you had to choose a messaging service, what would you choose GTalk or AOL Instant Messenger? If you chose GTalk, you probably won’t be chatting with too many people. With AIM, you’re almost guaranteed to be able to chat with anyone you want. Any growth within the instant messaging realm generally gets absorbed by the few players that dominate the market because people want to join the networks that their friends are on. Ecosystems, by nature, are capable of harnessing the same network effect. A largely fragmented system with dozens or hundreds of ecosystems presents very little value to any participant. A few ecosystems that aggregate huge numbers of participants and value, however, benefits most everyone (as long as the oligopoly remains as such, offering market choice and fostering continued competition).

Right now, we’re very early in terms of the SaaS platform and ecosystem space, so I’ll be brave and attempt to be an oracle. In these early stages, value focus will not be on the value of the ecosystem; participants will choose platforms that offer the most immediate value in terms of technical merit, application offerings, etc. As the participant numbers of the early platforms and ecosystems grow, value focus will shift to the network value of each ecosystem. A market shake-out will most likely follow due to the rapid growth of some ecosystems, leaving that golden handful as clear leaders and many, many participants that can benefit from the huge amount of value that these networks can provide them.

Do you agree with this notion, or do you see a situation where many more ecosystems exist? If this was the scenario, do you think the aggregation of value is worth having an oligopoly?

read more