From ambiguous uptime definitions to narrow scope and limited remedies, some Service Level Agreements (SLAs) in Software as a Service (SaaS) contracts remove or unduly narrow vendor obligations. This leaves companies to their own devices to bear the burden of unexpected downtime, performance issues, and safety risks.
In an interview with Machinery Maintenance Matters, Olivia Deckers of pre-eminent African law firm, Bowmans, outlines common pitfalls and offers practical guidance for customers to ensure SLAs safeguard operational reliability and uptime. With over 650 lawyers, Bowmans delivers integrated legal services to clients throughout Africa from nine offices in six countries.
By Jimmy Swira
Ideally, when a customer, such as a copper mine in Zambia, entrusts a vendor to provide it with a Software as a Service (SaaS) solution to enhance equipment reliability by monitoring and determining when maintenance is required, there is the expectation (or the desire) that it will function as and when needed diligently. After all, this would often be in accordance with the assurances made by the vendor during the ‘sales pitch’ and the expectations of the terms and conditions of the SaaS contract as a whole (which entails the full contract for the use of the SaaS, with warranties, indemnities, limitations of liability, IP, data protection, etc.).
Nevertheless, in reality, this may not always be the case, as accounts of customers – companies that are end users – indicate. And it is very important to carefully review the terms and conditions.
This issue is particularly evident in Service Level Agreements (SLAs), which are parts of, or relate to, SaaS contracts. An SLA is the portion of the contract dealing with service levels, service credits, and other related aspects including how certain technical issues will be handled. By its nature, an SLA includes an inherent acknowledgment that the SaaS is not perfect and that outages and performance issues may occur. The purpose of an SLA is to set clear rules for this. However, SLAs are often not always as clear as expected for various reasons including poor drafting, lack of attention and thought and attempts by vendors to limit their responsibility, liability and exposure.
Grey Areas in SLAs
There are often grey areas in SLAs that customers often overlook. Unfortunately, these can affect operations at a significant cost, observes Olivia Deckers, Partner in the Technology, Media and Telecommunications (TMT) team at Bowmans. She highlights the following common issues:
1. Uptime (availability)
The SLA will typically include a commitment to a specific uptime, e.g., 99.99%. However, SLAs often do not clearly define “uptime” and often have numerous exclusions.
This worrying ambiguity is prominent in four areas, laments Deckers:
“Firstly, there is no definition of ‘uptime’. It is often not clear if the service level only applies to total unavailability of the SaaS as a whole, or if it also applies to partial unavailability and degraded performance.
“Secondly, the measurement period may be unclear (e.g. whether it is monthly or quarterly). This situation may lead to uncertainty, as the vendor will usually prefer a longer measurement period and the customer will usually prefer a shorter one.
“Thirdly, it may be unclear whether uptime is measured across all sites or per site/region. This may also lead to uncertainty, as the vendor will usually prefer the former and the customer will usually prefer the latter.”
To cap it all, the broad exclusions dilute the uptime commitment. Common examples include third-party failures (including core providers such as hosting providers), broad rights to schedule planned maintenance, uncapped emergency maintenance, and force majeure that is not aligned with the force majeure clause in the SaaS contract.
As a result of these issues, Deckers notes, the customer may experience more partial or total downtime and performance issues than expected. Inevitably, this has huge implications – it could result in monitoring gaps, equipment malfunctions or breakdowns, and safety or compliance issues. Moreover, because of the ambiguity and exclusions the customer may have no or limited recourse against the vendor.
2. Accuracy and quality
An uptime service level is not always sufficient, Deckers states:
“A service level does not provide a commitment in relation to the accuracy, quality and reliability of the SaaS, or other performance metrics that the customer may require. This may result in a situation where the SaaS has perfect availability but does not function with the accuracy and quality that the customer requires and this may result in monitoring, safety, and other issues.”
3. Resolution times
SLAs often include response times but no resolution times (the response time being the time by which a response must be provided to a logged issue versus the resolution time being the time by which the logged issue must be resolved).
Resolution time service levels may not always be strictly necessary because of the uptime service level (and other service levels). However, they operate as an additional mechanism to ensure swift resolution by the vendor. In businesses that require continuous operation, downtime or degradation will have a significant impact on the business.
To address this, Deckers suggests:
“The SLA should include specific resolution time service levels based on allocated priorities of issues. Watered-down ‘best efforts’ or ‘commercially reasonable efforts’ undertakings are not recommended.”
Furthermore, SLAs often use generic definitions of severities that don’t take into account the customer’s specific business or industry. As a result, the wrong severity level may be allocated to an issue.
For this reason, customers should carefully consider the definitions to ensure these are appropriate in the circumstances, Deckers advises.
Otherwise, if issues are not resolved timeously based on severity, the customer may experience extended downtime or performance issues. This could result in maintenance tracking gaps, equipment malfunctions or breakdowns, and safety or compliance issues.
4. Scope
The scope of what the SLA applies to is often too narrow, such that the service levels only apply to the SaaS/cloud application itself, and do not apply to the full solution (for example, including sensors and edge gateways).
Consequently, the vendor may have limited to no responsibility or liability for issues in the solution but external to the SaaS/cloud application. Accordingly, the customer may have little to no recourse for such issues. However, Deckers acknowledges this does depend on what the vendor is actually responsible for – therefore this scope should always be clearly recorded in the both the underlying contract and the SLA.
5. Service credits
Last but not least, vendor SLAs often do not include service credits for service level failures. Alternatively, where there are service credits, they are often the exclusive remedy, subject to a cap, and require the customer to request the service credit within a short time period, notes Deckers.
As a result of this limitation, customers often have insufficient remedies for a service level failure, and their other remedies are excluded. This exclusion is particularly risky in relation to material service level failures for which a customer may seek to rely on other remedies such as termination and/or a damages claim, Deckers points out.
Weak SLA provisions in SaaS agreements can undermine maintenance programmes and compromise equipment reliability.
What Should Customers Consider?
To avoid being left high and dry with SLAs, Deckers advises applying due diligence during procurement and negotiations of the SLA.
Informed procurement and negotiations
As end users with mission-critical equipment – and more at stake in the event of failure – companies should consider the following vital aspects to include in their SLAs to ensure they are not shortchanged:
• Clear scope of the SLA that reflects the full scope of the vendor’s responsibility.
• Clear, defined service levels, with identified measurement periods and other measurement metrics (e.g., measured by site/region). These should include uptime, any other relevant performance metrics in the circumstances (such as accuracy and quality), as well as response times and resolution times, by severity.
• Narrow exclusions (be wary of blanket exclusions) with clear, limited maintenance windows.
• The hours and days when remote and on-site support is provided.
• Responsibilities and dependencies clearly identified and appropriately allocated to the customer and vendor.
• Service credits that apply automatically for a failure to meet the service levels. Service credits should be sufficient to motivate service level compliance by the vendor while still being proportional to the harm likely to be suffered by the customer in each case (consider the amounts of the service credits and any caps).
• No exclusivity of remedies. In addition, the right to claim damages instead of a service credit should be expressly reserved (if permitted by law).
• Termination rights for the customer for chronic failures, persistent breach, and repeated service level breaches.
• Regular service level reporting obligations.
• Escalation procedures with named roles and response commitments.
A Well-Structured SLA for Accountability
In heavy industry, where downtime can have costly and hazardous consequences, weak SLA provisions in SaaS agreements can undermine maintenance programmes and compromise equipment reliability. Imagine, for instance, four hours of downtime at a copper mine in Zambia exacerbated by grey areas in an SLA – the ensuing losses in production, safety risks, and operational disruptions could be immense and the company operating the mine may have no little to no certainty of when resolution will occur and no little to no recourse against the SaaS supplier to recover any related financial losses.
A well-structured SLA should therefore be clear, measurable, and enforceable. This ensures that vendors remain accountable and responsive. In the end, it safeguards operational reliability and ensures uptime for mission-critical equipment.
In word: do the home work during SaaS procurement and negotiations of the SLA or the condition of your machinery will be worse off.
*The focus of this article is on the standard provisions found in a typical SLA for a SaaS contract. In some instances, these may also include security, liability and other provisions, but these have not been considered for the purposes of this article.
