The SaaS Bus! Get on Board! Stopping All Cash Pots!

  • Article

First time I saw a presentation on SaaS (or to the uninitiated, Software As A Service) I thought, this sounds really familiar. In fact, it wasn't until I saw a few different SaaS presentations (like Nigel Watson's unreal TechEd SaaS presentation) that it clicked that the best way to think of SaaS from a business point of view is very similar to the old bureau model of the 70's. See, back then, everyone who wanted to have some form of payment service, had to setup complex infrastructures (not as in IT infrastructure, but card machines, processing offices, etc) to facilitate it. It became onerous, and distracted people from the core job of selling petrol, clothes, food, whatever. Then companies came along and said, hey, don't worry about all the bother, we'll take care of the credit/transaction processing, and you worry about selling business. Now, they weren't saying give us your existing processes and systems and will water and feed them, they were saying, we will bear the cost and risk of offering the service full stop, you just become a "service customer". The service was whatever they were selling and wanted to offer credit/transaction services for, and customer because now they were paying someone else to enable them to do it.

So extending on that concept, I've taken the current idea in my head around SaaS, and have been thinking, what would the business model look like now? See, to me, what's needed is the concept of a SaaS Bus or Network! There are three players in this model:

1. The core service provider: This is the organization that has the goodies the rest of the world wants, hidden in their internal systems, represented on the balance sheet as a liability or cost center. Sure people use the service allot, but from the business point of view, it's just part of the Cost of Business, not a Revenue Source. Think of something like the institutional banking systems for example. They manage customer account info and such, but purely from a business operations point of view.

2. Introducing the SaaS Publisher (SaaS-P)! This is the company that has a substantial network infrastructure (public in my example) and some software nouse. They set up a directory of services that they manage and maintain, that are consistent and follow industry standards, that have Service Level Agreements, and are secure, stable and scaleable. Where do these services come from? Well, they approach the Core Service Provider (CSP), and arrange a business relationship where the SaaS-P invests in plumbing a connection into the CSP's internal system, builds a pluggable web service front end from the CSP's internal system through to their external, public, managed SaaS-P network, and then setup a whole bunch of management, accounting, operations and control systems to support any service on that network. They then offer access to these services to the public.

3. The WebVAR! The WebVAR is like an ISV, only they don't build any particular service, instead, they are masters of composition. They take the banking service interface, the mapping service interface, and the route optimization interface, and mash it up into an awesome "show me a map of banks in this location that have a 24hr ATM and get me there from where I currently am in the fastest possible way!". The release the software to the world and sit back. (Btw, WebVAR's could also be SaaS-P's, because they may have a great piece of logic or software capable of being used in composed application)

4. The SaaS Customer! OK, so this is where the money trail starts. Saas Customer downloads the WebVAR's application for free and signs up for their online transaction service. They execute the search, and immediately the search function hits three SaaS-P service points, and in turn, 3 CSP systems. The SaaS-P clips the ticket by charging the WebVar a service use free for each service. The WebVAR also clips the customer's ticket for using their WebVAR service app. The customer pays for the use of the high-value service. In turn, the Saas-P aggregates the use of a CSP's service, and rebates an amount to the SaaS-P each month by way of reduced service fee. So in theory, the money trail would look like:

Customer pays WebVAR $1.00 to use service each time (as a hypothetical). The WebVAR in turn, is charged by the SaaS-P 10c for each service point hit (so 30c) for that transaction. And finally, the SaaS-P returns to each of the three CSP's, 5c for each hit (15c to three parties). So the profit chain is: WebVAR = 70c revenue, SaaS-P = 15c revenue, CSP = 5c. Now, this may not look like much, but as the paths fan out, and more WebVAR's are using SaaS-P services in different ways, the SaaS-P's revenue streams increase. And for the CSP, they are able to move their internal system from the liability/cost side of the P/L to the revenue side.

It's just a concept at the moment, but I'm liking the model each day. What do people think?