An SLA (or service level agreement) is useful for anyone who doesn't want to leave the scope of the service to chance. They often form part of a support and maintenance agreement or an application's terms of use, which then form one comprehensive service agreement.
Whether you are a customer or a supplier, you should require an SLA whenever you want to be sure of the quality of the service you provide. This is because an SLA guarantees certain parameters such as uptime, speed or performance. With a good SLA, you will always be sure of the correct quality of the service to be provided and how non-compliance will be dealt with.
Why do we write about the SLA separately from the service contract ↗? After all, it has the word "service" in the abbreviation.
We deliberately distinguish a service contract from an SLA. While a service contract is about troubleshooting (the application suffers from a malfunction that needs to be fixed), an SLA deals more with the operation itself (the application is running, it is accessible via the Internet). Thus, in a service agreement you will find, for example, the agreed methods of receiving requests, how to resolve them, and the deadlines within which the supplier will start working on the problem (for example, response within 2 hours). In the SLA, on the other hand, you will find requirements for time availability (for example, 99% of the time in a month), speed of operation (time to load a web page) or its performance parameters (for example, a quad-core processor and 8 GB of RAM).
However, SLAs and service contracts often work together and complement each other. That is why we usually deal with them in one contract.
Software as a Service (SaaS) is the most common practical use case for SLAs. If the user is not running the software on their own device and instead relies on a third party infrastructure or cloud, one of the first questions will usually be - what if it crashes? Or better yet, do you guarantee it won't crash? Even the most robust solution can have a weak moment. That's why it's always a good idea to think about what level of availability you can guarantee. Alternatively, whether you want to provide the product "as is and as available" with minimal guarantees.
The operation of *aaS usually involves the processing of personal data ↗. Haven't you forgotten them?
The entrepreneur's online e-shop is not working. And even if the entrepreneur and the website operator are looking at the error message from the same screen, the expectations of both of them are fundamentally different. While the entrepreneur demands an immediate solution and resolution of the outage, the website operator says it is a permissible downtime that can last up to three days. Which party is in the right? Does the website downtime violate the rights of the entrepreneur? Or is the website operator entitled to carry it out?
If only the parties would enter into an SLA that would give them an unambiguous answer...
Price for the preparation of the contract: from 15 000 CZK + VAT
The content of the contract will always be set according to the client's requirements, the type of cooperation between the parties and the level of trust between them. At the client's request, the SLA can also be prepared as part of a service or other contract, which will additionally modify:
