What Is a Service Level Agreement?

We often write about how complex custom software projects can be, as they need clearly outlined requirements, carefully drafted roadmaps, and the flexibility to make adjustments when the developers encounter obstacles or the client requests a change. With all those moving pieces, it can be difficult to keep track of the scope—and cost—of the work. So, how can a software vendor and a client be sure they’re on the same page? The key is the service level agreement (SLA), which is a contract between vendor and client that specifies the details of the service expected during the engagement.

An SLA could be an addition to a commercial contract, or it could be published on the service provider’s website. Either way, it should contain the information both parties need to fully understand the offering.

Why is this important?

When a client is ordering a service such as software maintenance or support, it is critical to clarify the parameters of that service in order to plan both business operations and budget effectively. It is important to base this agreement on objective parameters, as well—for example, the more urgency is required, the more the service will cost. These parameters may be different in different industries and domains, but regardless, they must be defined for both parties’ protection. After all, if the agreement isn’t clear and measurable, it becomes nearly impossible to prove whether it’s been satisfied or breached.
Let’s take a look at the components of a typical SLA.

Recitals, or Definitions

It is best to begin the service level agreement with a glossary of terms as well as a short description of the system and the roles of the participants. This is to ensure that both parties are operating on the same understanding of various key terms and ideas. The name of the system, as well as the technologies and any readymade third-party solutions used to build it, are all included in the recitals. Usually, this section will also list typical users, defining terms such as “regular users,” “key users,” and “help desk staff.” It could also list the company departments that are involved in the process and clarify the role each one plays.

Next, the recitals include definitions of the “limits of applicability”—of how, where, and when the agreement in the SLA is applicable. These limits may be based on territory, time, and/or function, and they’re used to define where the service will be provided (remotely or on-site) and when (timeframe, work schedule, time zone, days off, and bank holidays). The functional applicability might describe the system’s versions and modules, its interactions with other systems, etc. If your SLA covers any environment other than production (such as testing), this should be stated clearly in the document, as well.

Main Agreement

After the recitals and definitions, the main part of the agreement should describe what should and should not be done under this SLA. This includes the type of work, rules regarding deliverables and communication, guidelines for revisions, and any other details that govern the process of fulfilling the agreement.

If any ambiguity remains, you should work on the SLA until all parts are clear to all parties concerned. Ideally, an outsider (for example, an employee of a field-specific consulting company) should be able read the agreement and say, “Yes, it’s all clear!”

Additional Content

SLAs may be further supplemented by references to other documents describing the development process, such as operating procedures or anything else applicable to the client’s domain. It would also be useful to mention (and include links to) the procedures and software used for tracking requests.

Choosing the Metrics for the SLA

The metrics guiding the SLA are what make it possible for both parties to determine whether the work is being done in an effective and timely manner. This could include time boundaries—such as reaction timing or target resolution time—or quality markers. But whatever the metrics, they should possess five main characteristics:

• They should reflect the quality of the service provided.
• They should be easily measured.
• They should follow both common sense and industry best practices.
• They should be limited in number. Whenever there is more than one guiding metric, the SLA should clearly define the order of priority to ensure the vendor can address critical issues quickly and keep the project moving forward.
• They should depend purely on the work of the vendor or party tasked with the job. If there is weak or no correlation between the metric and the responsible party, the control will be lost and the SLA would not work.

Let’s take a look at an example of a bad metric: Imagine that the time of availability of a given IT system is set at 99.99 percent—in other words, it has almost no downtime—and the metric’s success or failure is attributed to the work of the help desk. The employees running the help desk do not have any influence over the system’s downtime; the only thing they can do if the system is down is to inform the responsible administrator or department in a timely manner. The amount of time it takes the administrator or relevant department to fix the issue does not depend on the help desk. Hence, it would be unfair to blame the help desk for someone else’s work should something go haywire.

Beware of Excessive Requirements

While the metrics and requirements outlined in an SLA are designed to keep a project moving forward in a timely manner, it’s important to ensure they’re not so strict that they put the vendor (and, therefore, the project) in a bind. It might sound like a cliché, but it’s true: the tougher the metrics, the dearer the cost. Here are a few examples of excessively tough metrics:

Example #1. Let’s suppose that a certain type of service request takes on average four hours to resolve, though a senior developer could fix the issue within two. What would happen if, for this type of request, we were to require a two-hour fix instead of allowing for four (or even five)? This would mean that the project would require a senior developer, which would automatically increase the cost to account for the senior developer’s expertise—not to mention their overqualification for the job.

Example #2. What if the SLA promised the same issue would be fixed within one hour? It may be tempting to write steep requirements into an SLA in order to impress the client, but when the requirements are unrealistic, they render the SLA useless and set the vendor up for trouble (and the client for frustration).

Example #3. Assuming the standard support time is 8/5 (eight hours a day, five days a week), if a client requests 24/7 support instead, the price tag will increase sharply, by at least five times. Why? Because this scenario would require three shifts per day, plus weekends and bank holidays, plus substitution for vacation and sick leave. The clients should ask themselves: do I really need 24/7 support?

From our experience with successful SLAs, we advise both vendors and clients to really think carefully about what is a “must” and what is a “nice to have” in an SLA. If users insist on unreasonable metrics, the vendor will ask them if they are prepared to pay for it.

Ultimately, the job of the SLA is to allow the stakeholders to control the custom software development process. The higher the level of control, the better the SLA, and the happier both parties will be in the long run.