Modification date: December 14, 2020

What Is a Service Level Agreement?

What Is a Service Level Agreement?

We often write about the complexity of custom software projects — the need for clearly outlined requirements, the carefully drafted roadmaps, and the flexibility to make adjustments when the developers encounter obstacles or the client requests a change. So with all those moving pieces, how can a software vendor and a client be sure they understand the scope and cost of the work? The key is the service level agreement (SLA), which is a contract between vendor and specifies the level of service expected during the engagement.

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

Why? When one is ordering a service such as software maintenance or support, it is important to clarify certain parameters in order to have the certainty needed to plan both business operations and budget. (The more urgency is required, the more the service will cost.) It is important to base this agreement on objective parameters. 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 file a claim if the agreement is breached.

Let’s now take a look at the components of a typical SLA.

Recitals, or Definitions

It is best to start with a glossary 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 is stated along with the technologies and any readymade third-party solutions that were used while building the system. Usually, this section would also list typical users such as regular users, key users, and help desk staff. It could also list company departments that are involved in the process and state their roles.

Then, the document defines limits of applicability, including territorial, timed, and functional. Here, we 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 systems 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.

Finally, the SLA’s recitals section should clearly define the process that is regulated by the main part of the document.

Main Agreement

After the recitals and definitions, the main part of the agreement should describe what should be done under this SLA and what should not be done. This includes 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!”

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 these main characteristics:

  1. Metrics should reflect the quality of the service provided.
  2. Metrics should be easily measured.
  3. Metrics should follow both common sense and industry best practices.
  4. The number of metrics should be limited. Should there be more than one metric, the SLA should clearly define the priorities in order to ensure the vendor can address critical issues quickly to keep the project moving forward.
  5. Metrics should depend purely on the work of the vendor or party tasked with the job. Should the correlation between the metric and the responsible party be poor, the control would 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%, and the metric is attributed to the work of the help desk. The employees running the help desk do not have an influence on the down time of a system. Should the system be down, the only thing they can do 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 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 write two hours instead of four (or even five)? This would mean that the project would require a senior developer, which would automatically bring the cost up. The senior developer’s expertise — not to mention their overqualification for many jobs and the volume of offers coming their way — would mean cost of such service would be much higher than normal.

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 the 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 set the client up 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, at least 5X. Why? Because in this scenario, three shifts per day would be employed, plus weekends and bank holidays, plus substitution for annual leaves and sick leaves. 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 some unreasonable metrics, the vendor will ask them if they are prepared to pay for it.

Additional Suggestions

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

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

Publication date: December 14, 2020

Explore More Resources:

What our customers say about us

Syberry has provided satisfactory services thus far, and they are very responsive to any issues that arise. The team also possesses strong communication skills. They delivered a functional piece of software at a reasonable price, and they've managed the project very well.

Richard Harkness


Elk Grove, CA

How we help ADEPT Driver Company

We developed a web-based driving simulator for teens and another for adults. The products run on Chromebooks, and the team added features that enable them to measure a driver's ability to avoid a crash.

Technologies used

I don't think you could find a better company to manage and build your project. I get so many compliments on my application, and it has a lot of unique and complex development.

Todd Surber


Charleston, South Carolina

How we help PIXRIT Company

A photographer approached us to build a web-based software platform that combines the fastest social media manager with state-of-the-art galleries and provides the ultimate tool for photographers to upload, store, back up, and share their photos and manage their SMM activities.

Technologies used

The user-friendly software hasn’t encountered any issues or bugs in more than three years. It’s high quality has helped grow the clientele. Straightforward and consistent in communication, Syberry met every deadline and ensured a hassle-free development process.

Vince Hughes

Owner, Steel Estimating Solutions

Knoxville, TN

How we help Steel Estimating Solutions Company

Our client was inspired to create a product that helps steel erection companies perform faster, more efficient estimations and bids. We developed original proprietary software from the initial concept.

Technologies used

The new platform received positive feedback and performs better than its predecessor. Syberry communicated the project’s progress to their partners well by breaking down their steps and utilizing a management system. Most importantly, they delivered world-class service for a cost-efficient price.

Bill Fahy

Owner, FDI Creative Services

Houston, TX

How we help FDI Creative Services Company

Following strict regulations and requirements, we used AWS to develop a custom e-commerce web app that includes shipping integration. Since the site’s launch, the team has continued to make updates.

Technologies used

The application was delivered on time and within budget. Syberry explained their process thoroughly and accommodated to scope changes effortlessly. Their stellar project management, highly responsive communication, and proactive attitude set them apart.

Ricardo Casas

CEO, Fahrenheit Marketing

Austin, TX

How we help Fahrenheit Marketing Company

We developed a large, complex .NET application with various third-party integrations. The team built the software from scratch based on existing wireframes.

Technologies used

The end solution exceeded the client’s expectations. Syberry delivered high-quality products on time and at outstanding value. They provided frequent updates and repeatedly sought feedback at each stage. Customers can expect a highly experienced team that easily translates concepts into solutions.

Rudy Milkovic

Executive Director, Velicom

Austin, TX

How we help Velicom Company

Our team built video streaming software as a web and desktop app for a third-party client. We completed end-to-end development—from scoping to feedback cycles to QA—using PHP and Wowza Streaming Engine.

Technologies used

Syberry has successfully improved the frontend performance of the platform and continues to make thoughtful suggestions for enhancements. They have proven to be communicative and reliable, mitigating the common concerns of outsourced teams. Syberry remains mindful of business goals and client needs.

Cory Kowal

VP of Products, THG Energy Solutions

Tulsa, OK

How we help THG Energy Solutions Company

Taking over for another vendor, we served as the ongoing software engineering partner for an energy company’s cloud-based platform. The company provided scoping, development, testing, and deployment services.

Technologies used

The added team members sufficiently fulfilled the needs of the project. The product was successfully launched and has received positive feedback. Syberry continues to be a supportive partner in development. They provide an impressive team and their expertise fosters a smooth collaboration.

Chris Cox

CTO, MyMelo

Louisville, Kentucky

How we help MyMelo Company

We provided staff augmentation resources for a development project. The team contributed engineers to follow an established roadmap to perform updates and add features.

Technologies used

Syberry delivered a solid website that has become a database of close to 40 organizations. The team worked quickly and efficiently to get the website up and running, and they continue to invest their time into the project. Additionally, they have been a communicative partner.

David Snyder

Product Director, Covid Resource Network

West Orange, New Jersey

How we help Covid Resource Network Company

The company developed a website that serves as a database where organizations can find and donate to other organizations. Currently, the team is working on enhancing the website and fixing bugs.

Technologies used

When the system is up and running, it will save time for the internal team. Syberry was a patient partner, and they performed well throughout the collaboration.

Joyce Cubio

VP of Operations, Ernie's Mobile Home Transport

Yuba, California

How we help Ernie's Mobile Home Transport Company

The team built an information hub for a mobile home transport and permit service. After discussing the existing system and processes, we delivered a new structure for forms and data.

Technologies used

All deliverables have exceeded expectations and function properly once launched. The Syberry team is skilled in juggling multiple projects, and provide strong expertise in software development. Their dedication to the project has fostered continual success in the engagement.

John Fox

Executive VP, Fox Business Automation Solutions

Lakeland, Florida

How we help Fox Business Automation Solutions Company

Brought on as a third party, we supplied ongoing development services. The team work on multiple projects and deliver according to predetermined design specifications.

Technologies used

Contact us to learn more about how Syberry can help your business achieve its every goal!

0 / 2500

Sign a mutual NDA before a conversation.

When to sign an NDA?

A non-disclosure agreement (NDA) is a legal contract between parties, such as the software developer (or a software development firm) and yourself, outlining information to be shared and requiring that information be kept confidential.
Submit loading...

Was this page helpful?