coneblog

There are aspects of SAAS that I hadn’t appreciated, including the need for reliability.

In SaaS, you have the ability to have various dummy organizations right in production for various reasons and situations, everything from Demo to Testing. The reference system is production. If you want to understand how a certain feature works in a special configuration, you can try it out in a test organization.

Of course, this requires a high level of reliability in all aspects of the system. I pleased to say that we have that level of stability in our production environment. That is a result of the hard work of a relatively few people over the last six or seven years making the system rock solid.

We have very sophisticated monitoring systems that detect minute server hiccups, or even the lack of positive information. The new guy was on call this last weekend, and at one point was getting texted every five minutes when a web server didn't post an operating statistic to its log as expected. Sometimes the false positives are more annoying than the real events.

I’ve heard some stories of the early years, when the system was not yet solid. The organization managed stability problems with a sharp focus on high levels of customer service, rare for this market. The high service levels were necessary to manage the customers thru periods of instability. The bonus is that as the system became more and more stable and capable, we kept up our tradition and capability for strong customer service.

Now we have the best of both worlds: a stable system with market-leading features, and a strong customer service organization. It is an unbeatable combination.

Benefits to the Support Organization

The service and support organization benefits from the all-in-one SAAS model in several ways. One obvious way is access – all the configuration and all of the data is right here at the service reps fingertips.

The all-in-one model can be used in debugging, as well. The system is sufficiently complex, with a raft on configuration features, such that one Customer can experience anomalies related to configuration conflicts that are not bugs, and don’t show up in other customers. A useful thing to do is to compare the anomalous customer’s set-up with the set-up in a reference Org, or a similar organization that is not misbehaving. This is easy in the same data base.

The Support Reps have access to all of the customer configuration data, and can bail customers out of problems (often self-inflicted) by running powerful batch reconfiguration tools on the database to reset permissions or parameters. If all else fails, they have access to the developers downstairs who can peek into the data directly and diagnose.

Another overlooked benefit is the control that we have over the application, hardware and network environment. The application runs on a (relatively) small number of servers over which we have complete control and access. In my former Big Box on Site model, any number of things, from local network latency to the customer refusing to by the recommended hardware could cause unique problems at each site. These were hard to debug and resolve, and to overcome the finger pointing tendency with the customer IT staff.

With the SaaS model, it is really simple – we own, control, and manage everything but the browser. And if the browser don’t work, have the user reboot it, reinstall it, or upgrade it. There is no point to finger pointing, because all the fingers point to us.

Easy to Sell

The other major beneficiary of the SaaS model is the sales team.

First and most obviously, the Sales Team benefits because of the pricing available based on the snared cost structure. With no costly on-site hardware infrastructure, the pricing can be dramatically low for a high function system, and still leave room for profit.

You don’t necessarily want to price way below your value to the customer. Ideally you want to capture that value. But in a situation where new market segments open up at dramatically lower price points, and your incremental cost of servicing the N+1 customer is very small, you can price aggressively to open up these new market segments.

The SaaS model takes lots of cost out for the customer IT team, too. They don’t need to buy, install, configure, support, or provision a hardware/application stack for your application. They don’t need much involvement at all, which is great for market segments without a lot of in-house IT capability, or who have IT staffs that are overloaded. And who isn’t overloaded these days? You have just removed a potential IT nay-sayer from the sales process.

Bottom line – when you can deliver a sophisticated application at a cost two orders of magnitude (100x) lower per seat than Box on Site models, you can address lots of nitches that couldn’t be economically addressed before.