The last thing most people want to consider while starting a relationship is what happens if the deal goes south. As a result, areas of the contract having to do with breach, termination and service levels or performance guaranties tend to lack the same depth as others.
Specifically with respects to service levels, the goal is to create a measurable set of steady-state obligations that are able to be met by the product. The first two steps are then to list the obligations themselves and their associated performance level. This could be as simple as saying that the product will operate uninterrupted to a certain percentage of the day, or as complex as 30 or 40 individual operational features that have to perform to a certain degree or quality (such as providing a report generated in a specific time period).
After you know what obligation(s) to watch and the required operational level, the next step is to make sure that the obligation actually can be observed. Many SLAs are good in theory, but don’t provide practical metrics simply because there’s no way to know whether they have been met. For example, many parents want to know that their newly-driver-licensed children can’t or don’t exceed the speed limit… but until there was a device that could watch maximum speed, reliance was upon the integrity of the driver.
Next is determining WHO is responsible for tracking the SLA. This entirely depends upon the product – I’ve seen the responsibility equally distributed between both licensors and licensees… just make sure the party who is tasked with the job knows that it’s their responsibility. But, especially with services-related tasks (or ASP/SaaS products), the job normally falls to the vendor/licensor, as they’re in a better position to watch performance.
The “watcher” should then also be in charge of reporting the metrics to the other party on a regular/consistent basis. If the obligation is that a service will be available 24x7x365 with 90% uptime, then it’s reasonable that each month a report will be created showing any downtime and how that compares to the 90% requirement.
Lastly, and usually of primary importance to the licensee/buyer, is the issue of what happens if the metric is “blown” and the SLA is missed. Contractually-based remedies are my preferred method for handling this what-if – but unless the true damage of missing an SLA is calculable prior to the missed service level, there’s the chance that any contractual remedy will fall short of actually fixing the issue. So rather than focusing on penalties, which is often what happens in the negotiation, focus attention on how much effort will be used to solve the current problem and prevent future problems.
If a vendor is then unable to prevent the problem from recurring, or in the event that the SLAs continue to be missed, financial penalties can be included as a last resort to return some of the fees paid for the lack of 100% guaranteed service.
So, when creating SLAs, take the time to discuss the needs behind the SLAs with each other. As with other sections of the agreement I’ve discussed in the last few weeks, a little open, honest communication at the beginning of the relationship can avoid lots of future problems.