Though service level agreements (SLAs) have proved their importance for business reputation and project success, many IT vendors still doubt that SLAs have any relevance for them. Meanwhile, IT consultants believe that SLAs are an absolute necessity for delivering impeccable service. In this post, we will discuss why SLAs are necessary and review the basic dos of drawing them up.

Why do you need an SLA?

SLAs can gage service efficiency in an objective way. Without the agreement, companies would rely on extremely subjective criteria, such as client satisfaction, training quality, quantity of completed tasks, and so on.

SLAs act as conflict-prevention tools; they help soften disputes or avoid them altogether by regulating each party’s needs and interests. As a result, conflicts are resolved in a more professional manner and are not taken personally.

It works like this. Both parties utilize the same terms for communication and the same criteria for analysis and evaluation of the service quality as per the SLA stipulations. As a result, each party saves a lot of time and effort that would be otherwise wasted on figuring out what was wrong, who is to blame, and what to do about it. The very process of writing an SLA makes a vendor think of a project’s aspects never considered before. It’s a guarantee against unexpected legal actions, unlawful complaints and lawsuits.

To cut it short, SLAs facilitate efficient management of expectations, foster open communication, and keep up a solid relationship throughout the project.

Basic criteria to include in an SLA

The most basic criteria to include in an SLA are reaction speed, feedback frequency, the deadline for delivering an intermediate solution, and the expected time to final resolution of arising problems, if any. Although a lot of requirements vary from project to project, you can also consider including the following issues:

• Page loading speed
• Critical application failures
• The number of software crashes over a period of time
• Major and critical bugs percentage
• Issue resolution time

If something is omitted in the initial agreement, it will usually come up during the development stage anyway and may require subsequent revisions of the SLA.

SLA is part of non-functional requirements that may define project’s architecture. Thus, changing these requirements on the ago may be a bad idea as it may require significant rework, therefore affecting budget and delivery, and potentially quality. Instead, a rule of thumb is to have these defined as early as possible and adjust only post-launch or in case some critical change happens.

Note that some criteria in the SLA will heavily depend on the budget. For example, when paying less for the service, one may expect more server failures.

The basic dos of writing a solid SLA

These are a few major recommendations for drawing up an efficient SLA that will be a key component of your project success and customer satisfaction.

Navigate toward structure and transparency

When writing an SLA, try to avoid ambiguity and make sure all the agreement terms are discussed and understood correctly by both parties. For example, legibly state what services are exactly covered and what services should not be expected. Consider mentioning availability limits and resolution times as clients should understand when they can reach you for communication and issue resolution.

Welcome changes

As the project develops, requirements and budgets may change, making SLAs evolve with them. Every SLA should be approached as a dynamic document that is regularly reviewed and amended respectively, with negotiations and adjustments viewed as natural and healthy. However, basic non-functional things should remain the same, otherwise one might have to deal with the consequences, and it’s better to know that beforehand.

If necessary, go through several iterations of the initial agreement. Writing a living and breathing SLA should take a while, so do invest your time into doing it properly instead of wasting your time later on conflicts and disputes. Additionally, don’t forget to prepare an SLA for those cases when responsibility is given to another supplier, like in the outsourcing or SaaS use situations.

Don’t use templates and cookie-cutter forms. You can use online SLA templates only as a basis for your own document. Each SLA should be a reflection of the unique needs of every project and its goals. In case you’re not sure if you get the specifics right, seek legal help. When you enter a long-term business relationship with a substantial budget, you will definitely need a lawyer on your side to oversee every clause and sentence and keep you out of trouble.

Include clients in the process

Make sure to update clients on the SLA writing progress as often as possible. The sooner iterations are discussed and approved, the faster you can move on to the next stage without leaving anything out of the loop. At the same time, don’t try to over-promise and over-impress. Even though you want to sound reliable and capable of keeping your promises, you cannot give any guarantees unless you know you can deliver on your promises in full.

Treat an SLA as a bilateral agreement

SLAs should serve both parties equally. As a vendor, you may think it’s natural to please your clients and agree to disadvantageous terms. However, the SLA should be a mutually beneficial agreement that clearly states criteria for both parties. At the same time, don’t treat an SLA as a substitute for communication. When you get a complaint, don’t wave your SLA in front of the complainer. Try to discuss the issue and resolve it informally, and only go to the SLA as a last resort.

Each company needs an SLA

SLAs are extremely important in the IT sphere, but in reality, any business can benefit from a document of a similar kind, even though it may have a different name. If you want to maximize your financial potential and minimize risks, start writing an SLA right now.