Once you have an idea of the services that will probably require an SLA and the levels that should be expected, you can work with your Product Development and Information Technology departments to determine how much these SLA’s will cost to support.  Using these costs, you can design a multi-tiered pricing package for the SLA’s based on each customer response time and availability’s needs.

For example, every transaction may cost $8 if you take the basic SLA package, which is 95% uptime and a 20 second response time, or it can cost $10 if you want the premium SLA package, which is comprised of 98% uptime and 10 second response time. Some users need 24/7 availability, while others are good with 22/6.

You can design your software to put high SLA customers into faster moving queues and process them on more powerful machines and many companies do.  However, that is not the true point of the exercise.  The exercise has both planning and negotiation benefits.

First, by planning and understanding the SLA requirements, you can ensure that the hardware and infrastructure will be hearty enough to support the application without worrying about hidden costs popping up for unexpected support requirements.  Second, the sales people will not be as tempted to throw in the SLA for free to get a customer to sign a deal.  They will have a framework of “gives and gets” that they can use to quantify the customers desired level of service.  If the customer has to pay more for a higher level of service, they are going to think twice about buying it. (Note:  In order to get the sales team to use the tiered SLA system, their incentives must align with it properly.)

Further, even if you don’t design your software to manage different service levels – which means you really design it at the highest expected level of service – this tiered approach gives you a quality of price discrimination.  You can charge customers that place a higher value on service a higher price than those that do not highly value it.

However, there are some pitfalls with the SLA process, even if you have designed everything properly.  A problem that I have seen is that the fees incurred when the SLA is not met can be assumed to be the total value of the lack of service to the client, which is not necessarily the case.  In the SLA, customers don’t usually ask to be reimbursed for their total lack of productivity while the system was down, they just ask for a penalty amount for the downtime.  The downtime causes more damage to brand, product perception and customer satisfaction and that is not covered by the penalties specified in the SLA.

In 1998, Uri Gneezy and Aldo Rustichini conducted an interesting study at several daycares in Israel*.  They noticed that parents were coming late to pick up their children from the daycare, so they decided to institute a monetary fine for those parents who showed up late.  While they expected to see a downturn in the amount of late parents, they actually saw a dramatic increase in the experimental group.  The fine became the “price” of the being late and it was an amount that parents were more than willing to pay.

The same thing can happen with your IT Management.  They can decide that the SLA’s penalties are the actual value of the SLA breach, when that is only a fraction of the true cost to the company.  For example, if the penalties imposed by the SLA total $5000 per month then that amount will be used to make decisions.  If the cost of the hardware required to beef up the infrastructure exceeds $5000 a month, your requests for upgrade will be denied.

In this case, the soft cost of dissatisfied customers and brand damage will be ignored in favor of the hard cost of the SLA.   While I don’t advocate the hiding of information from your IT department, I would recommend never publishing an SLA penalty without including a number (even if it is debatable) that represents the damage to brand and customer satisfaction.

* Gneezy and Rustichini, “A Fine is a Price”, http://rady.ucsd.edu/faculty/directory/gneezy/docs/fine.pdf, 2000