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’s team was highly responsive and communicative, managing our project smoothly, responding immediately to any issues that arose, and delivering great software at a reasonable price.

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 high-quality, user-friendly software Syberry created for us has helped grow our clientele, and we were very pleased with their partnership. Syberry was straightforward and consistent in their communication, 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

Syberry delivered world-class service for a cost-efficient price. They communicated well with our team throughout the process, breaking down steps and utilizing a streamlined management system to keep everyone in the loop at all times. The resulting new platform far outperforms its predecessor and has received rave reviews.

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, Velikom

Austin, TX

How we help Velikom 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 significantly improved our existing platform, and they continue demonstrate their dedication to our business goals and needs by making thoughtful suggestions for enhancements. The Syberry team is communicative and reliable, mitigating all our concerns about outsourcing software development.

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

Syberry has been an invaluable partner in development. Their impressive team was more than able to fulfill our project needs, and their expertise and dedication led to smooth collaboration every step of the way. The result was a successfully launched product that has received lots of positive feedback.

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

The database Syberry developed has empowered 40 organizations to help in the fight against COVID-19. A communicative partner, the Syberry team worked quickly and efficiently to launch the website, and they continue to invest their time and efforts into the project.

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

Syberry was a patient partner, making this engagement feel like a true collaboration. The system they created for us will save our team significant time and frustration.

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

The Syberry team is skilled at juggling multiple projects. Though they are in high demand, we were confident that they had the resources and the expertise needed to focus on our partnership. Their constant dedication led to a truly successful engagement, and the final product exceeded all our expectations.

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.
This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.
Submit loading...

Was this page helpful?