Schedule Blocks

Service levels

This guide explains the different parts that make up a service levels block.


Service levels

Time and time again, WCC data shows Service Levels rank within the top 5 most important and disputed terms.

However, when looking at where Service Levels rank when it comes to Most Negotiated Terms, Service Levels are not even within the top 10 of ranked terms.

The WCC Contracting Principles provide sound guidance when dealing with Service Levels and recommend:

  1. While suppliers intend to provide high quality services, SLA Failures can occur over time given the complex nature of technology services. SLA Failures should not be deemed to rise to the level of a breach of contract.
  2. SLAs are intended to underscore supplier’s efforts to maintain the service, proactively identify potential problems, and quickly resolve any SLA Failures.
  3. SLA targets and SLA Credits should be set at levels that drive high performance but do not create financial windfalls for customers or unreasonable financial exposure for suppliers.
  4. SLA performance targets should be measurable and verifiable and should reflect minimum acceptable levels of supplier performance, focusing on critical service elements that are essential to the value of the service being provided.

What are user support service levels

User support service levels can vary significantly from one provider to another. These service levels encompass the provider’s commitment to general assistance and technical help.

The choice of provider and the negotiation of these terms are hence crucial, as they could directly affect a customer’s business operations.

General assistance refers to a broad range of services aimed at helping the customer use the product more effectively. This could include things like a helpdesk for answering customer queries and assistance with updates or upgrades.

This formal agreement between the provider and the customer specifies the expected level of service. It outlines what support services the provider will offer, the resources they will commit to these services, and the expected turnaround times for service delivery. To put this into perspective, an SLA for a cloud service provider might specify that customer inquiries will be responded to within 24 hours, and technical issues will be resolved within 48 hours. If these commitments aren’t met, the SLA could specify penalties, such as service credits or even termination of the contract.

Therefore, User Support service levels play a critical role in managing expectations between the provider and customer, serving as a measurable benchmark for the quality of service. Furthermore, they can help to build trust and provide a framework for communication and resolution in case of any service discrepancies or disputes. It’s essential for businesses to carefully consider the details of the service levels when choosing a tech provider and negotiating a contract.

What are error correction service levels

In a technology contract, the provision of Software, SaaS, or an API (“Product”) can present certain challenges. Once a customer starts using the Product, they may encounter problems or “Errors,” which were not picked up earlier. These errors could range from minor bugs or glitches that cause inconvenience, to major problems that disrupt business operations or compromise data security.

For this reason, many providers supply their products “as is,” with disclaimers stating that they make no warranties the product will be entirely free from errors. This is because it is virtually impossible to guarantee a completely flawless product, particularly in the tech industry where complex systems and frequent updates can introduce new vulnerabilities. For instance, a SaaS provider may state in their contract that while they strive to provide a high-quality service, they cannot guarantee that the software will always function perfectly or that it will be compatible with all possible combinations of other software or hardware.

However, from a customer’s perspective, this can be problematic, particularly if the product plays a vital role in their business operations. For instance, a company might rely on a particular SaaS application for managing customer relationships, coordinating sales, or processing transactions. If this system encounters errors, it could cause significant disruption and potential loss of revenue. Therefore, the customer needs reassurance that if they encounter any errors, these will be addressed promptly and effectively.

In this context, error correction service levels come into play. These service levels provide specific timeframes within which reported errors must be acknowledged and resolved by the provider. For example, the contract might state that critical issues will be acknowledged within 2 hours and resolved within 24 hours, while less urgent issues will be acknowledged within 24 hours and resolved within 72 hours. These service levels are typically tiered, with faster response times for more severe issues.

Such service levels not only gives customers a clear expectation of when issues will be addressed, but it also sets a standard that the provider must meet. If these service levels are not met, the customer might be entitled to certain remedies, such as service credits or even the right to terminate the contract. Hence, these service level commitments are a crucial element in tech contracts, protecting customers’ interests and ensuring a high standard of service from the provider.

What are uptime service levels

Uptime service levels are indeed a crucial aspect of technology contracts, particularly for Software as a Service (SaaS) and Application Programming Interface (API) offerings. The term “uptime” refers to the time during which a service or system is operational, available, and accessible to users. Conversely, “downtime” is the time during which a system or service is unavailable or inaccessible.

In tech contracts, the provider often commits to a certain level of uptime, expressed as a percentage. This means the provider assures that the SaaS or API will be operational and accessible for a specified percentage of the total time over a certain measuring period.

For instance, a provider may commit to a 99% uptime. If the measuring period is one month (roughly 720 hours), this means the provider assures the service will be operational for 99% of that time. In practical terms, this allows for about 7.2 hours of potential downtime in that month without breaching the service level agreement (SLA). Note that how downtime is calculated and what exceptions or exclusions apply can vary from contract to contract.

Different services might require different levels of uptime. For example, a basic blogging platform might only promise 95% uptime, meaning the service could be down for up to 36 hours in a month without violating the agreement. Conversely, a cloud-based inventory management system for a large retailer, which needs to be accessible around the clock, might promise 99.99% uptime, meaning the service could be down for just about 4.32 minutes in a month.

It’s important to note that the consequences of failing to meet the uptime commitment are typically specified in the contract. Often, these consequences involve the provider giving the customer service credits or even a right to terminate the contract in the case of persistent or significant downtime.

Therefore, the uptime service level is a vital part of a tech contract. It sets a clear standard for service availability and provides remedies for the customer if the provider does not meet this standard. As a customer, it’s essential to ensure that the promised uptime aligns with your business needs and the criticality of the service to your operations.

What are system response time service levels

As the digital landscape continues to evolve, businesses are increasingly leveraging external Application Programming Interfaces (APIs) and Cloud Services for various functions. From payment processing and customer relationship management to data analytics and inventory control, these services often play an integral role in business processes. As such, not only is the reliability of these services vital, but also the speed at which they perform becomes increasingly important.

With advancements in technology and the rise of real-time systems, businesses now operate at a much faster pace than before. Delayed responses from APIs or Cloud Services could lead to a slowdown in business processes or even cause transactions to fail. For example, if an online retailer’s payment processing API responds too slowly, it could lead to customers abandoning their shopping carts, affecting the retailer’s revenue. Similarly, if a cloud-based inventory management system is slow to update, it could lead to stock discrepancies and operational inefficiencies.

Due to these factors, businesses often seek to establish service levels relating to the response speed of APIs and Cloud Services. This is where a System Response Service Levels comes into play. These service levels sets out the specific timeframes within which an API or Cloud Service must respond once a system request (like an API call) is made.

Let’s consider an example to illustrate this: A business might impose system response service levels on their payment processing API provider, requiring the API to respond within 200 milliseconds (ms) 99.9% of the time, for every payment transaction request. If the provider fails to meet this requirement, the contract might stipulate that the provider has to give service credits to the customer, or in extreme cases, the customer may have the right to terminate the contract.

In another scenario, a company using a cloud-based customer relationship management (CRM) system might have an SLA with the provider stating that any data request (like retrieving customer data) must be completed within one second 99% of the time.

By establishing these service levels, businesses can ensure their external APIs and Cloud Services operate at the speed required for their operations. Such SLAs provide a clear benchmark for service performance, protecting businesses from the potential adverse effects of slow system responses. Furthermore, they foster better collaboration between service providers and their customers, as both parties have a clear understanding of the performance expectations.



When setting up the process part of the service level block within a tech contract, the method of submitting requests for services, the individuals eligible to submit these requests, and the required information for submission are all vital considerations. Each of these elements needs to be clearly defined to ensure smooth communication and efficient service delivery.

Firstly, the method of submission for service requests under the SLA must be decided upon. The chosen method should be convenient and efficient for the customer while also being manageable for the provider. This could be via email, telephone, or through a dedicated customer portal. For example, a SaaS provider might have a customer portal where users can log in and raise tickets for any issues they encounter. Alternatively, for a small-scale API provider, an email to the support team might be the preferred method for receiving service requests.

Secondly, it’s important to specify who can submit these requests for services under the SLA. Depending on the nature of the service and the size of the customer’s organization, this might be restricted to only the customer’s technical contacts or key personnel. For instance, a large organization might designate certain IT staff as the primary contacts for dealing with their cloud service provider. This not only streamlines the process but also ensures that the people communicating with the provider have the technical knowledge to describe the issue accurately and understand the provider’s responses.

Lastly, the SLA should clearly define the information that must be provided when submitting a request. This is crucial because it helps the provider to understand the problem and expedite the resolution. The required information could include details like the user’s contact information, a description of the problem, the severity of the issue, the time when it was first noticed, and any troubleshooting steps that have already been tried. For example, if a company is using a cloud-based CRM, and an issue arises, the designated contact might need to provide their name, email, a description of the issue, the number of users affected, and any error messages they received.

In conclusion, the configuration of the process part of the service level block is a key aspect of tech contracts. It ensures that service requests are efficiently managed and resolved, leading to better service delivery and higher customer satisfaction. By specifying these elements, both parties can have a clear understanding of the procedures, responsibilities, and expectations related to service requests under the SLA.

Service levels

The Service Levels Block of a Service Level Agreement (SLA) lays out the key performance standards that the provider agrees to meet. This block serves as the foundation for service delivery, setting clear expectations for both the provider and the customer. Each component of the Service Levels Block should be thoroughly defined and configured to ensure the optimum performance of the contracted services.

The Support service levels portion of this block outlines the availability and delivery timeframes for support services, such as helping users with non-technical questions. For example, the SLA might specify that the provider offers email support between 9 am and 5 pm on business days. Exclusions, such as situations where the provider is not obligated to provide support services, should also be included. An example of an exclusion might be if the user is using the product in a way that is inconsistent with the product’s documentation or intended use.

The Error Correction service levels outlines the response and remedy timeframes for different types of errors, such as critical errors, urgent errors, and service-impacting errors. For instance, the SLA may require the provider to acknowledge critical errors within one hour and resolve them within 24 hours. Exclusions, such as situations where the provider isn’t obligated to correct errors, should also be specified. For instance, if the product is combined with unapproved third-party products, the provider might be exempted from error correction responsibilities. Additionally, it’s important to include any customer obligations, like providing the provider with remote access to their systems if needed to resolve errors.

The Uptime service levels sets out the expected uptime for the service and the measurement periods. For instance, the SLA might require 99.9% uptime over a month, which allows for roughly 43 minutes of downtime. This section should also define the acceptable downtime brackets and any exclusions, such as scheduled maintenance or downtime caused by the customer’s actions.

Finally, the System Response Time service levels sets the expected response times for the system or application in question. For instance, it might require that API calls to a third-party application must return a response within 200 milliseconds 99% of the time. This section should also detail how this measurement will be carried out and the period over which system responses will be measured.

By configuring these essential elements within the Service Levels Block, both the customer and provider can set clear expectations for service performance. These agreed-upon standards then serve as a basis for ongoing performance monitoring and can help to address any potential issues before they become significant problems. Thus, the Service Levels Block is an integral part of tech contracts, underpinning successful service delivery and customer satisfaction.


While not all Service Level Agreements (SLAs) carry a separate fee, there are circumstances in which a provider might impose charges for an “upgraded” SLA. Such a scenario could arise when certain support services demand significant resources from the provider.

For example, a software-as-a-service (SaaS) provider might offer basic email support within their standard package. However, if a customer requires dedicated 24/7 phone support, the provider may charge an additional fee due to the extra resources needed to fulfill this requirement.

In such cases, a provider may offer a certain number of “free hours” of enhanced support each month. Once this limit is exceeded, the provider may charge for additional support at a specified hourly rate. For instance, a provider could offer ten “free hours” of technical support per month and charge $100 per hour beyond that limit.

The Fees part within the service level block delineates all these financial terms and conditions. It is important to precisely define these aspects within the service levels block:

  • Fee Amount: This refers to the exact amount that will be charged for the service. It might be a fixed amount or could vary based on usage or other factors.

  • Payment Frequency: This defines how often the customer must pay the fee. It could be monthly, quarterly, annually, or based on a different schedule.

  • Payment Terms: This sets out whether the fee is payable in advance (prepaid) or in arrears (postpaid).

  • Escalations: This refers to any increases in the fee over time. These escalations could be based on a fixed schedule or linked to an index like the Consumer Price Index.

  • Escalation Cap: This term refers to any maximum limit on the fee increase, especially relevant in the case of contract renewal. For instance, the contract may specify that the annual fee increase cannot exceed 5%.

By meticulously outlining these aspects, both the customer and provider can have a clear understanding of the financial expectations associated with the service levels. This understanding helps to prevent disputes and fosters a harmonious business relationship between both parties.

Monitoring and reporting

The reporting and monitoring part within a service level block specifies how performance against the agreed service level is monitored, who is responsible for this monitoring, how performance is reported, and the timeframe within which this report must be delivered after each Measurement Period. Each of these part plays a crucial role in ensuring the effectiveness of the service levels and driving service improvement.

  • Who is responsible for monitoring the service levels: This determines which party or parties are responsible for monitoring the service levels outlined in the SLA. For example, in the case of a SaaS (Software-as-a-Service) contract, the provider would usually be responsible for monitoring their system’s performance levels. However, in some contracts, third-party entities or the customers themselves may also play a role in monitoring. A practical example would be a hosting service provider who monitors server uptime and provides customers with access to the same metrics through a client portal.

  • How will reporting work: The reporting method should be convenient and comprehensive for both parties involved. It should describe the format of the reports (such as dashboards, spreadsheets, PDF documents), how they will be delivered (like email or a dedicated customer portal), and what data they will include. For instance, an IT service provider might provide monthly reports showing uptime, the number of support requests received, how quickly they were resolved, and any ongoing issues.

  • Timeframe for report delivery: This refers to the period within which the provider must deliver the report after each Measurement Period. The Measurement Period is the timeframe over which the service levels are evaluated – this could be daily, weekly, monthly, or any other agreed period. For instance, if the Measurement Period is a month, the SLA could specify that the provider must provide the report within five business days of the end of each month.

By carefully configuring the reporting and monitoring parts, both the customer and the provider can ensure transparency and accountability in service delivery. This leads to a better understanding of performance, provides insights for service improvement, and strengthens the trust and collaboration between both parties.


Credits are a common remedy in tech contracts for instances where the provider fails to meet the stipulated service levels. Essentially, they are a form of compensation that is provided to the customer, often in the form of a reduction or offset against future fees.

The part relating to credits in the service levels block outlines the rules and procedures related to these credits. Here are some key elements that need to be clearly outlined in the service level block:

  1. Process for issuing credits: There may be a specific process that must be followed for credits to be issued. This might include a requirement for the customer to report the service level failure to the provider and a stipulated timeframe within which this must happen. For example, the customer may need to report an outage within 24 hours for credits to be issued.

  2. Requesting credits: There could be a clause stipulating that credits must be requested by the customer within a certain timeframe after the service failure, such as within 30 days of the end of the month in which the failure occurred.

  3. Calculation of credits: The method for calculating credits should be clearly defined. This could be a fixed amount per incident, or it might be a percentage of the monthly fee that is proportional to the severity or duration of the service failure.

  4. Sole remedy provision: Some contracts stipulate that credits are the sole remedy for service level failures. This means that the customer agrees not to seek other forms of compensation, such as lawsuits for damages.

  5. Cap on credits: There may be a maximum limit on the total amount of credits that can be issued in a certain period, such as a month or a year. This cap helps protect the provider from excessive financial liability.

  6. Forfeiture of credits: Some contracts include a clause stating that any unused credits will be forfeited if the contract is terminated. This encourages customers to use their credits promptly.

  7. Exclusions: There may be situations where credits will not be issued, even if service levels are not met. For instance, if the customer’s own negligence leads to a service failure, the provider might not issue any credits. These exclusions should be clearly defined to avoid misunderstandings.

By configuring these parts in the service levels block, the tech contract can offer a fair and effective mechanism for compensating customers when service levels are not met, while also protecting the provider from excessive liability. This balance helps maintain a positive and productive relationship between the customer and provider.

Termination rights

The termination rights part is a key component of service level block, particularly for customers who want to ensure they have an escape route should there be consistent failure in meeting the agreed service levels.

  • When will the termination right be available: This sets the criteria for when the customer can exercise their right to terminate the contract due to service level failures. For example, the contract could state that if the provider fails to meet the service levels over three consecutive measurement periods, the customer has the right to terminate the contract. A practical example could be a cloud storage service provider with an uptime guarantee of 99.9%. If this provider fails to meet this uptime guarantee for three consecutive months (the Measurement Periods), according to the terms set in the contract, the customer might have the right to terminate the agreement.
  • Penalties on termination: The agreement should clearly stipulate that if consistent service level failures trigger termination, the customer can do so without incurring any penalties or additional fees. This provides the customer with protection and leverage if the provider consistently underperforms.
  • Notification requirements: There should be a clear process outlined for how and when the customer should notify the provider about their intention to terminate the agreement. This could include requirements for written notice, specific points of contact, and lead time before termination takes effect.
  • Data handling post-termination: Particularly relevant in the context of tech contracts, the agreement should outline the provider’s obligations with respect to customer data after termination. This can include stipulations around data retrieval, transfer, and deletion to ensure the customer’s data remains secure and accessible even in termination scenarios.

By thoroughly configuring the termination rights part, the tech contract can balance the power dynamics between the customer and the provider. It can provide an avenue of exit for the customer in case of consistent poor performance by the provider, reinforcing the need for the provider to maintain high service standards.

Escalation of requests

Escalation procedures are an essential part of tech contracts, as they outline the steps customers can take if they are unsatisfied with the level of support or service they receive. The purpose of these procedures is to ensure that customers have a path to resolution when their initial support requests are not met satisfactorily. They also help providers maintain quality control, as senior personnel can intervene when necessary to maintain high standards of service.

It is crucial to outline a clear process for escalating issues. Typically, this process involves several tiers of support, from the initial help desk to increasingly senior personnel. The steps for escalation, including how and when to initiate them, should be outlined clearly in this part.

For instance, a customer may be unsatisfied with a solution provided by a first-level support agent for a critical software bug. If the bug remains unresolved, the escalation procedure would allow the customer to take the issue to a higher level, perhaps involving a senior technician or manager.

From a provider’s perspective, the involvement of senior personnel or highly skilled technicians should be reserved for extreme cases, i.e., when lower-level support staff cannot resolve the issue, or when the issue severely impacts the customer’s operations. In some instances, access to higher-tier support may be contingent on the customer subscribing to a higher-level (and likely more expensive) SLA.

For example, a SaaS company might offer a “premium” support package that includes faster response times, dedicated support staff, and priority escalation to senior personnel. This higher-level SLA would cost more than the standard support package, reflecting the additional resources dedicated to these premium customers.

It’s important to note that the details of escalation procedures and access to more senior support need to be precisely defined in the contract. This ensures that customers are aware of their options when issues arise, and helps providers manage their resources effectively while maintaining customer satisfaction.

Out of scope services

In tech contracts, defining the out-of-scope service is crucial from the Provider’s perspective. This part outlines what services are not covered under the service levels, limiting the provider’s responsibility and potential liability. It’s essentially a protective measure for the provider, clarifying the boundaries of their commitment.

One common out-of-scope scenario is services requested outside of the predefined support hours. For example, if the Provider’s support hours are from 9 AM to 5 PM local time, any support request received outside of this timeframe would be considered out-of-scope. As a practical example, if a customer experiences a software glitch at 8 PM and requests support, the Provider, as per the defined contract, would not be obligated to provide immediate assistance.

Another common out-of-scope scenario is issues caused by the customer’s actions, known as a “Customer Cause.” This could include situations where the customer modifies the product in an unsupported way, uses the product inconsistently with its documentation, or causes an issue due to their own technical error.

For instance, if a customer accidentally deletes critical data from a cloud service and requests assistance to recover it, the provider might consider this as out-of-scope. This is because the issue was not due to an inherent flaw in the product but was instead caused by the customer’s own action.

In addition to these examples, there might be other specific services that the provider wants to exclude from the service levels, such as support for third-party products or services, or support for older versions of the product that the provider no longer officially supports.

By clearly defining these out-of-scope services in the service levels, the provider can set clear expectations with the customer, avoid misunderstandings, and manage resources more effectively. It also encourages customers to use the product correctly and responsibly, knowing that certain actions might result in out-of-scope support requests.

Important considerations

World Commerce Principles

World Commerce and Contracting has provided the following principles:

  1. While suppliers intend to provide high quality services, SLA Failures can occur over time given the complex nature of technology services. SLA Failures, by themselves and In the absence of negligence or willful misconduct, should not be deemed to rise to the level of a material breach of contract.
  2. SLAs are intended to underscore supplier’s efforts to maintain the service, proactively identify potential problems, and quickly resolve any SLA Failures.
  3. SLA targets and SLA Credits should be set at levels that drive high performance but do not create financial windfalls for customers or unreasonable financial exposure for suppliers.
  4. SLA performance targets should be measurable and verifiable and should reflect minimum acceptable levels of supplier performance, focusing on critical service elements that are essential to the value of the service being provided.
  5. In some cases, the parties may wish to supplement or replace SLAs with Key Performance Indicators (KPIs) and/or Service Level Objectives (SLOs), which specify additional performance parameters that will be tracked and objectives that the supplier will strive for but not be liable for if not met.

Related articles

Ninja holding a laptop explaining tech contracts

Interested in our Contract Builder?

Table of Contents

Master contracts now
Elevate your career!

Try for free. No credit card required.

Elevate your legal game with ContractNinja.

Form part of the spearhead movement of shaping the global standard for tech contracts.