This is the personal blog of Tasos Christidis. Evolved from a general technology blog to a cloud- and XaaS-focused resource. Special references to Software as a Service.
You can also reach me at LinkedIn: http://gr.linkedin.com/in/anastasioschristidis
Subscribe to this blog
Follow by Email
What does “Quality” mean for SaaS products?
anything sold, quality is the first and most important factor for its success
on the market (price is the second most important thing, but we will not deal
with it, in this post). During my engagement with the Software as a Service
business I have found out that Quality is an issue that needs to be redefined
in that context. I started thinking about this, driven by the fact that “traditional”
software “virtues” are not enough to build a sustainable SaaS income. By the
term “traditional” I mean all the usual quality elements or performance
indicators that the buyer expects from any kind of software (SaaS or not-SaaS):
be fast and reliable
be adequately supported by its vendor
provide insight to the data that it keeps (and not just to… keep them)
point in this post is that SaaS is a space where additional “quality elements”
must be in place. I will enumerate what I have come across (and what my
customers are usually challenge me on) and explain why they are considered so
much more important than traditional in-premise offerings.
Extensive parameterization: A SaaS product must offer
extensive parameterization options since it is by definition a piece of
software that the end-customer cannot be endlessly customizing and at the same
time not respecting physical or logical constraints that its creator has set.
Consider one of my favorite silly examples: In a customized in-premise
software, if accounting dept wishes, it can revert the debits and credits on
the General Ledger module so that the debits are on the right and the credits
on the left hand side (!). Imagine this requirement being served by a generic
SaaS Accounting software. Either the software vendor will say “not possible, sorry”
or they will create a new customer setting like this: “debits on the right: [YES]/[NO]”.
The point is that in order to serve
diverse customer requirements from a unique codebase (and database) the logical
architecture of the system must be extensively based on parameters and
User support: By definition, any SaaS business
shows meaningful profit margin for the supplier only if the number of customers
is high. A large number of customers increases the workload of the Support
department (call center, web support, telephone hot-line etc.). The vendor needs to build mechanisms that
are capable of supporting multiple users, simultaneously. This is not
necessarily the case with traditional in-premise software where an on-site
technician visit is probably the best (or only?) way to identify and resolve
the issue. In such cases, there is a mechanism to pipeline, schedule and
execute the visit. And no one expect the visit to take place instantly!
Frequency of new releases: All software vendors offer
frequent upgrades and new releases for their software. In-premise software
suppliers do so only if the customer has bought a Maintenance Contract, but in
the SaaS business new releases are not something that could be charged for an
extra fee; it is simply expected to be included in the monthly (or whatever)
recurring fee. To put in different words, there is no SaaS product without a
release upgrade “package” attached to it. But that’s not the main point here.
The main point is that in order to be constantly on the edge, to be ahead of
the competition (remember: SaaS is the tool that enables users to easily switch
from one product to another, since they never “bought” anything) and to follow
versions, mobile environments etc.) a
SaaS “factory” must constantly produce new and better releases of the software.
The urgency of new releases in in-premise software is not that big, since what
“used to work a few years ago” will still work unless a major PC switch is done
(not a frequent case!)
Performance issues: The workload of an in-premise
software & database is generally stable with slow rate of increase.
Performance bottlenecks or degradation manifest themselves slowly, gradually
and always give enough time to IT dept. to react. This is not the case in SaaS
where the hunt for new customers (=users) in that existing infrastructure in
endless. Sure, modern architectures provide all the necessary tools for scalability,
high availability and fast upgrades. But in any case this means that the SaaS vendors must have the mechanism to
be on top of these issues; and they are rated by their customers on this
Security: Much has been said about the
security of SaaS. We shall not go into details here, but just remind the usual
concern of the customers: “my data is in the cloud and therefore out of my
physical reach and protection”. SaaS
vendors must demonstrate impeccable positive records in terms of security.
As simple as that.
Customer engagement: Because SaaS does not require any
capital investment, it is a perfect tool for customers to test and adopt, if
they finally get convinced that it suits their purpose. On the opposite case,
they are free to abandon the service and search elsewhere. This creates a high
velocity of customer transfer in and out of the service, or “churn”. In order
to minimize the rate of customer movement out of your service you must be in
constant contact with them. Listening to criticism, to their problems, trying
to find work-arounds for problems that they see as system inefficiencies,
keeping them up to speed with new releases and versions (that must come very
frequently, as stated before), etc. Therefore, there is a quantity of customer
engagement work that did not exist with traditional in-premise software sales.
Back in the day – and for large accounts only – it was enough for the account
manager to visit the customer every once in a while, discuss issues and find
solutions to new problems. In SaaS it is
not enough. Most SaaS vendors are employing social media and other techniques
to keep a high degree of customer engagement.
successful SaaS business implies the existence of additional (new to the
market) product virtues. Ultimately, these will separate the “men from the
boys” of the SaaS space, because as competition rises, buyers become more aware
of these additional virtues and start demanding them instead of just seeking
them. The pressure in SaaS suppliers is building up and each vendor will select
some (or all?) fields to build expertise and trust.
Through this channel I
have been talking about the advantages of cloud and SaaS products for a long
time. In this post I’d like to focus on a more specific area. An area that
contains a large pool of potential customers, who at the same time are still
facing basic problems in their journey towards a “computerized enterprise”. That of small business ERP and especially the
Financial ERP. By the term “Financial
ERP” we define the software that performs the basic functions of book-keeping,
sales and purchases, stock keeping customer/vendor order management and perhaps
some more like basic workflows and some kind of business intelligence. These
are requirements that small and medium-sized businesses are seeking to approach
first, or they have already done so with not much success. Also, they are the
kind of requirement that start-ups are trying to cover, since they touch the
back-bone of the business function.
between customers and providers in the cloud business are generally governed by
the Service Level Agreement or SLA. In a previous post I made the point that a
really “tough” SLA is probably not the “holy grail” of the cloud business,
which every customer should be looking for. In this post I will continue the
same line of thought, focusing this time in the impact that a strict SLA has on
the customer organization itself. For this purpose, I will use the term “Reverse
In this post I will
dive into the waters of Customer Ranking techniques and how they can be supported
by the existing Small Business ERP that is in use. By the term “supported” I
not only mean extracting valuable info as per the customer’s behavior (and thus
be able to make decisions about their credit situation) but perhaps also the
software being able run the entire process. Of course, such processes do not
apply to all kinds of businesses. In this
discussion, we assume the business model of a company selling B2B and in credit.
Obviously, for a B2C sales model that is being served by, say, an e-shop where
all sales are cash, there is no reason to examine low-volume, private