Navigating the maze of error correction service levels in tech contracts
27 Sep 2023
During Part 1 of SLAs explained, Derick learned the ins and outs of uptime service levels. Armed with knowledge and aided by ContractNinja, he drafted clear and precise uptime service levels. But as any seasoned contract lawyer would tell you, uptime is just one piece of the puzzle. Now, Derick faces a new challenge: error correction service levels.
Just when Derick thought he could sit back and enjoy a “Call of Duty” game, his phone buzzes. It’s the Boss again. “Derick, uptime is great and all, but what about error correction service levels? These guys will do a lot of customisation to their offering, and we will pay an arm and leg for these professional services. We want any errors to be sorted out ASAP.”
Derick opens his laptop. His browser greets him with tabs of SLAs, availability, and uptime definitions. One more search won’t hurt. “Error correction service levels,” he types. The screen fills with jargon that only deepens his confusion: “response times,” “resolution times,” “severity levels,” and “workarounds.”
Jen’s wisdom.
With a sigh, Derick calls Jen. “It’s like deciphering ancient runes, Jen.”
Jen chuckles. “Don’t worry; think of error correction service levels like an ambulance service. How quickly should it arrive after you dial 911? What’s the plan if they can’t cure you on-site? That’s your response and resolution time.”
“Ah, I see! So, it’s about setting the obligations for how quickly errors need to be addressed!”
“Exactly.”
Derick navigates to ContractNinja. Sure enough, it can generate error correction service levels. It even helps him define the severity levels of errors, from critical system crashes to minor glitches and corresponding response and resolution times. Awesome!
Important concepts
Response Time: Imagine sending a message to customer support about a glitch you encountered in their solution. The response time is how quickly they reply back, saying they’ve seen your message and are looking into the issue.
Resolution Time: This isn’t about just acknowledging you’ve had a problem; it’s about fixing it. So, if that software glitch stopped you from saving your work, the resolution time would be how long it took them to patch the bug so you can save again.
Severity Levels: Imagine different issues you might face with software. If the entire software crashes and nobody can use it, that’s a critical severity level – like a blackout in a city. On the other hand, if there’s a small typo in the user interface or a button is slightly misaligned, that’s a low severity – like a streetlight being out.
Workarounds: Say there’s a known issue with the software, like not being able to upload a particular file format. The SaaS company might suggest a temporary solution, like converting your file to another accepted format until they fix the issue. This suggestion is a workaround: not the ultimate solution, but a way to keep things moving while they work on a fix.
What’s an “Error” anyway?
In Software-as-a-Service (SaaS), “Error” often denotes a flaw, glitch, or malfunction that interferes with the software’s intended operation. However, without a clear definition, there could be ambiguity about what exactly qualifies as an “Error,” leading to potential disputes between the service provider and the customer.
An important aspect in many definitions of an ‘Error’ is reproducibility. If an issue occurs sporadically and cannot be consistently reproduced, it becomes challenging to diagnose and rectify. For this reason, many SaaS contracts specify that only reproducible Errors are considered valid.
The SOS procedure
So, an Error occurs. What now? The contract must outline a crystal-clear process for reporting Errors. Is it via email, an online support ticket, or a bat signal? From a Cloud Service Provider’s perspective, you want the Response Times and the Resolution Times to start running only once the Customer has followed the correct proses when notifying the Service Provider about the Error.
Another important aspect to address from a Service Provider’s perspective is placing an obligation on the Customer to provide sufficient information to diagnose the Error.
You don’t want a situation where a Customer phones up some random person in accounts, tells them something is wrong with the System, and puts down the phone. You want the Customer to follow the correct channels and provide sufficient information to enable your technical resources to do their job.
Customer-caused errors: Whoops!
“What if Vector AI is the one who messed up?” The contract should specify what happens if the customer causes the Error—like clicking where they shouldn’t have. Normally, the service provider is not responsible for these.
Third-party troubles
What if the Error happens due to some third-party software Vector AI uses? From a service provider’s perspective, errors resulting from third-party software or services should not count as errors unless explicitly agreed upon.
To try or to do, that is the question
Should the service provider only try to fix an error or be obligated to do so? From a Customer’s perspective, you ideally don’t want a situation where the Service Provider pulls up their shoulders and says, “Listen, we really tried our best to sort out this Error”. If the Service Provider cannot sort out a critical Error, the Customer will generally want to have all available remedies available when there is a breach of contract.
Remedies
What if the service provider can sort out the Error? Don’t leave this critical aspect to chance!
Credits are typically offered by service providers as a form of compensation for any service disruptions or errors that occur, ensuring the user isn’t paying fully for a service they didn’t receive adequately. This system is seen as an alternative to refunds and encourages customer loyalty by providing an incentive for the customer to stay and use the service.
What you need to consider when it comes to Credits
The first thing to consider is how the Credit will be calculated. Will it be a fixed amount or a percentage? How will the calculation work?
These Credits can usually be redeemed during future billing cycles. For instance, if a customer pays a monthly subscription fee and they are awarded credits due to an Error, their next monthly fee might be reduced by the credit amount.
There might be a limit to how much a customer can receive in credits. This cap is set to protect the service provider from excessive claims. For example, a SaaS provider might state that in no event will credits for a given month exceed 50% of that month’s subscription fee.
It’s common for there to be a timeframe within which the customer must claim these credits. This ensures timely reporting of issues and prevents sudden, unexpected claims from long-past errors. For instance, a company might require that customers claim credits within 30 days of the Error occurrence.
Termination due to Errors not being attended to
Not all Errors are created equal. A single severe Error that disrupts a crucial service might be enough to warrant a termination. Conversely, a series of minor, non-critical errors might also accumulate to a point where termination is justifiable.
SLAs often stipulate the conditions under which the agreement can be terminated due to Errors. This might be defined as a number (e.g., three critical Errors in six months) or based on unresolved issues that significantly hamper the software’s primary function.
In conclusion, credits are a mechanism to ensure fairness and accountability. By clearly defining their application, cap, and claim process, as well as tying them to potential contract termination, both providers and customers can manage expectations and protect their interests.
The quest continues
Derick now knows that contracts aren’t just about legalese; they’re about clarity, expectations, and covering all bases. As he sends his final draft to The Boss, he can’t help but feel a sense of achievement. However, the tech world is ever-changing, and so is the landscape of tech contracts.
Who knows what our intrepid legal counsel will face next? His trusty action figures will be there, on his cluttered desk, bearing witness to his continued quests. And so will we.
See also:
- Uptime SLAs explained
- The future of tech law in South Africa
- Understanding tech buzzwords like Augmented Reality (AR)
- The indispensable tool of legal technology
Martin Kotze
Martin Kotze has been a practising attorney, conveyancer and notary public for more than 10 years. He began his academic pursuit with a degree in business, where he dived deep... Read more about Martin Kotze
