Service Level Agreements in a Software as a Service World (1/2)

In my last posting, I mentioned that I would elaborate on Service Level Agreements and how they affect the Product Manager.  Product Managers have to be proactively engaged in the definition of the SLAs.  If the SLA is not managed properly, you may put your own company at risk. We have been at a customer site during a product outage – watching hundreds of your customer’s employees suddenly standing up in their cubicle and stretching because your product becomes unavailable is not a pretty sight

Let’s start out with a definition of the term, although it is basically what it sounds like it is.  A Service Level Agreement, or SLA, is a formal rider to a contract that details the performance and availability that the customer expects from the service provider, along with the fees and penalties that will be assessed if these expectations are not met.  The SLA will also usually specify the hours of operation when these service requirements will be in place.

Service Level Agreements can be set up to guarantee any level of service for any portion of a service that your company provides to the customer.  Some typical SLA’s include:

  • Response Time – A limit to the amount of time on average that it takes for a website or program to respond after a user has submitted a request.
  • Transaction Processing Time – The maximum allowable time for a vendor’s system to process a file or set of files containing customer transactions.  This usually comes into place with Electronic Data Interchange (EDI) and batch based systems.
  • Uptime Requirements – The percentage of allowable unplanned downtime that the vendor is allowed to have during the hours of operation.  This is usually in the range of 97.5% – 99.999% of the time although there are no hard and fast rules.
  • Outage Notification – A maximum amount of time from when an outage has been discovered on a vendor’s system until a vendor notifies the client, along with an escalation contact list, to ensure management on each side is notified of an outage appropriately at the right level.

In my experience, Service Level Agreements are usually first discussed during contract negotiations.  The customer asks the sales rep for an SLA, the sales rep goes to the product manager (if we’re lucky) and the product manager works with IT to determine if he can support the SLA.  This is the exact wrong way to go about the SLA process.  The product manager should write the non-functional requirements with the SLA possibilities in mind and understand the relationships between the SLA and the costs to run the system.

As we all know, nothing is free.  If the IT department has to provide more horsepower to an application, there is a cost to it.  You, as the product manager, must understand those costs and plan for them ahead of time, as you would for any product feature.  If these costs appear to be out of control compared with your business case or MRD, your new product’s existence may be in jeopardy, which is why you need to be specific about the market needs upfront.

Start by meeting with the customer and internal sales staff so that you can understand their business well enough to know how to write your SLA requirements. You may also try to estimate the cost of an outage for your customer so you can ask for realistic penalties. Your customer may not immediately react to an unplanned outage, but you can be sure that they will use that outage to either dispute the next bill and/or ask for a discount during contract renegotiations.

That is not to say that you are going to be able to predict the exact response time that all of your customers are going to need, but you should have an approximate idea of what services they value, how much they value them and how fast they expect the services to work.

When it comes to SaaS, manage your SLA before it manages you.