Service levels

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.

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.

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.

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 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.

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.