The benefits of Service Level Agreements in custom Enterprise software consulting

One of the greatest lies in the history of the modern world is ‘I have read, and understand these terms and conditions’. Tick, Click, Sign. We all do it, because no-one’s got time for that. It would take nearly an hour to read TikTok’s Ts & Cs, and Microsoft’s Bing comes in at an average read-time of 110 minutes!

But Service Level Agreements (SLA) have to be read, agreed and understood, otherwise a whole load of problems will rear up. The difference between Ts & Cs and SLAs is that at least with SLAs there is interaction between the two parties. It describes exactly what the user is paying for, and establishes the measurement of that service.

Service Level Agreements help to build trust between the provider and the end user, and avoid any conflicts. But, if not done properly, they can be seriously damaging to both. Let’s take a look at the different aspects of SLAs, from what they are, to the benefits, the parameters and finally what to consider in negotiating one.

What is a Service Level Agreement?

An SLA is a written contract between two parties, one being a service provider and the other an end-user. So, for example, a company wishes to outsource to a software developer as it doesn’t have the necessary in-house skills. Or perhaps a bank needs to have an external call centre.

SLAs can be short, perhaps a few sentences, or more commonly, many pages, covering in minute detail everything that the two parties expect of each other in the supply of a service. It takes a great deal of skill to produce an SLA, and will have many service commitments, individual sections of the main SLA that focuses on selective details. These service commitments include:

  • Service — specifically, the service or action that the provider supplies, for example, a mobile phone carrier provides telephony services.
  • Measurement — the metrics that quantify the service. For the mobile phone carrier, it might be the ‘five nines of uptime’, 99.999% service.
  • Performance Standards — dictating the expected quality of the services as decided by the end-user, with benchmarks built in to measure the actual delivery.
  • Terms and Conditions — yes, they pop up here as well. Things like the length of the service provided, and the minimum and maximum response times to a ticket or issue.
  • Service Violations — What if the provider fails at some part of the service? There are safeguards in the SLA that will protect the client, perhaps with a reduction in monthly costs, special discounts, or free service.

All of the above serve to protect both ends of the deal, and they help to define the expectations needed for the business relationship. Also, they help the provider to focus on the user’s needs and requirements.

Without an SLA, there is no way to accurately gauge the service provided, and there are no means of protection for both parties. It can be legally binding when used by public sector bodies, but most business SLAs are set up under more informal lines of contract.

The benefits of a Service Level Agreement

Primarily, it establishes a strong business relationship. A transparent document that is mutually agreed upon by both parties is a reference tool for any confusing issues.

It helps to avoid conflicts, which will likely happen in any business arrangement. For example, if a service provider is near-shore, in another country but within close time zones, public holidays may be very different to those of the client. These must be clearly noted in the SLA, unless the service is 24/7 as agreed.

It will improve communication between the two parties, as it will be necessary to maintain open lines for the service. Expectations will be clarified, with no surprises for either party.

Finally, it will allow the service provider team to focus on productivity, since they will be fully aware of their responsibilities, and able to plan their workday and workload accordingly. The team will be able to maintain current knowledge of the system, structure and functions, and will be able to respond to repair tickets as detailed in the SLA. If any changes to the system are needed, the team will be able to provide documentation and training if specified. Testing mechanisms will assist in the implementation of updates.

SLA parameters

One of the biggest challenges is to set the SLA up correctly. This is no easy task, as mentioned before, but if it is incomplete, well, I think you get the picture. The parameters are different for each client, and sometimes a client will have several SLAs depending on the service they are offering to the consumer. For instance, they may have three levels of options, basic, silver and gold membership, and each option will have its own SLA, with respective response times indicated for the service provider.

Then there are types of errors, workarounds, team availability and escalation. Some SLAs are centered around application component uptime and individual infrastructure, which is going to be a problem. They should be focused on business outcomes.

Performance targets should be realistic, and points of view cannot be ignored. Although everything should be included in a strong SLA, it is important to keep it as simple as possible, avoiding technical terms that might confuse a client.

It is also important that each SLA is regularly checked and reassessed, as changes happen that can cause an impact, such as response times dropping because of the pandemic, or changes in tax laws and government regulations.

Negotiating an SLA? What to consider

Taking the role of the client, I would include the following:

  • Clear meetings and interaction with the service provider before anything is written down, so I can outline our wishes and they can clear them with their teams.
  • Ask the provider to supply a copy of a real SLA that is operating at the moment, so we have some idea of what to ask for and what to expect.
  • Decide on operating hours and channels of communication.
  • If our requirements are accepted by the provider, I would ask for a draft document in plain language, without any professional terms, so that my team can study it.
  • Agree on specific timelines for response, ticket resolution and availability.
  • Request a Continual Service Improvement review on a regular agreed basis.
  • A reporting phase that is comfortable to both parties, with monitoring and metrics.
  • Agree key performance indicators.
  • Clear service violation markers for any breach of service provided, agreed between the two parties.
  • Look forward to a long and strong relationship with our new business partners!

iteo is an international technology consultancy & software engineering company, founded in Poland. Visit us on www.iteo.com

Love podcasts or audiobooks? Learn on the go with our new app.

Recommended from Medium

Integration testing in Golang using docker

Creating a Sci Fi lab room

Two Patterns To Secure REST APIs

Flask For Data Scientists : Building a Searchable File Directory

A Practical Guide to Surviving AWS SAM

​​Low-Code Platforms: 5 reasons to use them (and 4 to think again)

4 simple hacks to watch a video lecture effectively!!

What happens when you type ls -l in the shell ?

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
iteo

iteo

iteo is an international technology consultancy & software engineering company, founded in Poland. Visit us on www.iteo.com

More from Medium

Week 2 Rethinking VR: Key Concepts and Concerns

Top 3 Enterprise Collaboration Suite in China: High Level of Competition, Strengths are Weaknesses

Requirement Engineering — for whom and what for?

New Editable Shared Links API