Enovation Zaurus logo

Service Level Agreement

25 November 2020

1 Introduction

This Service Level Agreement (SLA) describes the services provided by Zaurus that are developed, maintained and managed by Zaurus; and as they are offered to the Client.

1.1 Purpose of the SLA

The purpose of the SLA is to make binding qualitative and quantitative agreements about the quality parameters for the service level to be realized and about the reporting on this, with the aim of monitoring and improving the quality and performance of the service.

1.2 Related documents

The SLA is an integral part of the agreement between the Client and Zaurus. Contract information such as term, validity, etc. can therefore be found in the Order Confirmation and is not included in this SLA.

1.3 Recording of parties

This SLA applies to the services that Zaurus B.V. – established at Comeniusstraat 5, Alkmaar, the Netherlands, registered in the Trade Register of the Chamber of Commerce under number 72991941 and legally represented by Mr. Niels Greidanus, Managing Director – (hereinafter: “Zaurus”) provides and performs for the other party to whom it provides these services (hereinafter: “Client”).

1.4 Principles

  • Zaurus is the developer, supplier and operator of the Zaurus services;
  • Zaurus is responsible for the maintenance including updates and upgrades of the Zaurus services;
  • Client is responsible for providing end users (both patients and employees) with 1st and 2nd line support;
  • Zaurus is responsible for providing the Client’s application administrator(s) with 3rd line support.

1.5 Validity of the SLA

The validity of the SLA starts when the online ordering process has been completed and the first invoice has been paid. The duration of the SLA corresponds to the term of the agreement concluded by the Client and Zaurus, including any renewals thereof.

1.6 Changes to the SLA

This SLA can be changed at Zaurus’ discretion. However, changes in Zaurus’ policy will not result in a material reduction in service lebel, security or availability of the digital consulting room (and assistant).

2 The Zaurus Services

2.1 Service description

The Zaurus services consist of the following components. The services provided to the Client are stated in the Order Confirmation:

Digital consulting rooms

  • Live chat
  • Chat
  • Video calling
  • Video recording
  • File sharing
  • Screen sharing

Digital assistants (based on agreement)

  • To be developed


  • Mobile: Android and iOS
  • Desktop: Web, Windows and macOS
  • Google Chrome – screen sharing plug-in

Integration interfaces (based on agreement)

  • REST and Realtime API
  • ADFS, SAML 2.0 and OpenID

Professional services

  • Maintenance and support
  • Consultancy: chatbot development, integration support.

2.3 Services

The professional services Zaurus provides to the Client consist of the following components:

SLA services

3 General

3.1 Responsibilities

Below is an overview of the responsibilities of the Client and Zaurus.


SLA responsibilities

3.2 Reports

List of reports released periodically by Zaurus, including:

  • Ticket overview
    The status of tickets can be followed real-time through: https://support.zaurus.nl.
  • Availability reporting
    The availability of the Zaurus platform can be followed real-time through the services status page (see chapter 4.6.4).

4 Service levels

This chapter specifies the service levels that apply to the Zaurus services.

Zaurus has three windows within which service is provided:

Service window: business days 8:30 AM – 5:00 PM (Central European Time)
Online window: 24 x 7
Maintenance window: Monday until Thursday from 10:00 PM (CET) until 12:00 PM (CET)

4.1 Procedure agreements

The authorized application administrator(s) of the Client can:

  • ask questions;
  • report (security) incidents; and
  • submit feature requests to the Zaurus service desk.

Notifications should preferably be submitted via the portal: https://support.zaurus.nl

Reports submitted via the portal are immediately recorded in our service desk system and are monitored.

Zaurus has the following communication channels:

SLA communication

*In the event that an urgent incident takes place outside the service window / business hours, the emergency number can be called by one of the Client’s designated application administrators.

Please note: the emergency number should only be used for urgent incidents (see chapter 4.4.1) outside the service window. An urgent incident implies that the business process cannot be continued by a large number of users. Example: Zaurus is not available to a large group of users through different clients. In case of abuse, € 250 (or $ 300) will be charged per case.

After receipt of a report, a diagnosis is made, indicating whether it concerns a Question, Incident (disruption), Request for Service or a Feature (change) Request.

If both parties cannot agree on the diagnosis, it is escalated to management.

4.2 Questions

Questions can be asked by the application administrators of the Client by telephone, via chat and via the portal.

Zaurus guarantees the following response and resolution times:

Response time: < 8 hours (service window)

Please note: only questions asked through the portal are monitored.

4.3 Request for service

If you need assistance in carrying out certain work, you can submit a request for service.

Examples of a “request for service” are:

  • Additional training
  • Generating a specific report

Zaurus guarantees the following response times:

Response time: < 8 hours (service window)

The resolution time will depend on the service required. If a request for service has a higher impact and / or requires a substantial amount of time, we will notify you and possibly provide you with a specific quote.

4.4 Incidents

The aim of the incident management process is to rectify the disruption / deviation that has been detected as quickly as possible and to structurally solve problems and errors in the Zaurus services and to prevent incidents and problems from recurring, in order to guarantee the highest possible stability for all our services.

The incidents reported via the portal are immediately recorded in the service desk system. We will then determine which component or app the report concerns, the direction for the solution and, if known, the expected resolution time. This is always reported back to the reporter.

The reports are handled by the employees of the Zaurus Service Desk, in consultation with developers on Zaurus’s side and application administrators on the Client’s side if necessary.

For both urgent and non-urgent incidents, if the agreed terms of the response and resolution times are not met, Zaurus will report this when expiry of the agreed term is imminent. Zaurus will then consult with the Client on how to proceed.

4.4.1 Incident priority

Disruptions in the service that are reported can have different priorities. Within the Zaurus organization, it was decided to divide these into four categories with corresponding response and resolution times.

Incidents are prioritized as follows:

SLA priorities

Based on the priority assigned to an incident, the response and resolution times below apply. If a partial solution is offered, the priority of the incident can be adjusted.

The priority of an incident can be adjusted during the process if the severity of the problem and the impact on the services require it or if circumstances change. The request can be assigned either a higher or a lower priority.


SLA response time


4.4.2 Communication in case of escalations

Services that exceed the agreed service levels can always be escalated. Escalation can also take place if the Client feels dissatisfied with the handling of a report. These escalations can also result from not being informed correctly or on time about the processing of the report, which gives the impression that the agreed service level is not being met.

End users must always first contact the Client’s Helpdesk. Other parties within the Client can contact their counterpart at Zaurus.

Below we present a graphical representation of the communication process during escalations, including the sequence (numbers).

SLA escalation

4.5 Features

Feature requests should preferably be reported via the Zaurus support portal so that they are recorded directly in the service desk system. Based on the applicability, impact and possible risks or opportunities, Zaurus determines which features are included in the roadmap planning.

It is important here that requests for new functionalities are documented as completely as possible, so that the impact, opportunity, risk and functionality are clear. During the strategic consultation, Zaurus will share its roadmap with the Client and the Client can provide input on the prioritization of new functionalities.

4.6 Availability

Zaurus recognizes that the success of the Zaurus digital consulting rooms and digital assistants depend on their availability.

The Zaurus services are designed to be available 24 hours a day, 7 days a week, 365 days a year, except during maintenance periods, technology upgrades and as otherwise specified.

Zaurus guarantees an availability of the Zaurus services of > 99.8% per calendar year.

Maintenance takes place during the maintenance window. An exception can be made for urgent priority 1 or 2 cases and information security incidents, also known as emergency maintenance.

In the exceptional case that emergency maintenance of the Zaurus platform or the Zaurus apps is required during the service window and the service is not or partially available, you will be notified at least one day in advance if possible. The notification is sent to your application administrators by chat or email. The notification contains:

  • the planned start time and date;
  • the expected duration;
  • the nature of the availability.

4.6.1 Measurement of availability

Availability is calculated over a period of a calendar year.

T – D

A = ———- x 100


A: Availability
T: Total number of minutes of the Service over a calendar year.
D: Total minutes of downtime minus the planned downtime in a calendar year.

The maintenance window is defined as a period of a maximum of 4 hours per month, spread over a maximum of 2 operations per month, during which maintenance can be performed. The maintenance window is Monday to Thursday from 10:00 PM (CET) to 12:00 PM (CET).

Planned maintenance will take place at times when as little inconvenience as possible can be expected.

During maintenance, the Zaurus services may be partially or completely unavailable.

The availability of the services is not guaranteed if:

  • Failures have not been reported within five business days of their occurrence and have not been noticed by Zaurus;
  • An outage or degradation of performance or outages due to applications, equipment, infrastructure and / or internet connection has occurred outside of Zaurus’s control;
  • Outages have been caused by planned and announced maintenance, or outages have been initiated by Zaurus at the request or direction of the Client;
  • Events occur as a result of an interruption or shutdown of the Zaurus services due to circumstances reasonably considered by Zaurus to be a significant threat to the normal operation of the services (e.g., a hacker or malware attack);
  • There is an outage due to a calamity, such as denial of service attacks, natural disasters, changes due to governmental, political or other regulatory or court orders, strikes or labor disputes, acts of civil disobedience, acts of war, actions against parties, or other force majeure situations or circumstances beyond Zaurus’s control;
  • There is negligence on your side, for example by the application administrators and / or users, e.g. failure to provide the necessary information or other cooperation.

4.6.2 Availability credit

If Zaurus does not meet the standard for availability, the Client is eligible for an availability credit (see table below).

SLA availability credit

4.6.3 Claims

Claims can be submitted to Zaurus via a support ticket including all the information Zaurus needs to validate the claim, including but not limited to: (i) a detailed description of the incidents; (ii) information about the date, time and duration of the downtime; (iii) the number and location(s) of affected users (if applicable); and (iv) descriptions of your attempts to resolve the incident at the time of occurrence.

The claim must be received before January 31, following the calendar year. We will evaluate all reasonably available information and determine in good faith whether an availability credit is due. If we determine that an Availability Credit is owed to you, we will apply the Availability Credit at the end of the contract term.

4.6.4.  Availability reporting

The availability of the Zaurus platform can be followed real-time via the services status page.

Availability can be viewed via the following link: https://status.zaurus.io

A weekly and monthly overview is available and you can zoom in on the various components. See the examples below.

SLA monitors


SLA video monitoring

4.7 Release management

To develop software in a qualitative way and to guarantee the quality of the production environment and apps, Zaurus works according to a development policy and we use an isolated development, testing, acceptance and production environment (DTAP).

Zaurus also works according to the SCRUM method and two-week development cycles in which bugs are fixed and new features are developed. Validation of new developments for release is checked using the four-eyes principle.

In addition to the internal development and test environments, Zaurus has a public acceptance environment called Alterdesk and the Zaurus production environment.

SLA acceptance production

4.7.1 Standard procedure

Updates to the platform and apps are always rolled out on Alterdesk first after internal testing. New versions always run on Alterdesk for one week before they are rolled out on Zaurus.

Employees of the Client are welcome to create test users on the Alterdesk environment and to test new versions. We also recommend you make a test link for the integrations that have been made with other subsystems, so that they can be included in the test.

iOS and Android
A TestFlight / Alpha build version will be made available for iOS and Android apps.

New versions are first rolled out as a TestFlight / Alpha build version on Alterdesk and also on Zaurus. If approved, the TestFlight / Alpha build version will be published in the App Store / Google Play Store.

4.7.2 Exceptions to Standard Procedure

Zaurus may deviate from the standard procedure if that is deemed necessary. Hotfixes and new versions will always be rolled out on Alterdesk first. However, it is possible to deviate from the test period of one week. Below are some examples:

  • In case of urgent incidents according to the SLA where immediate action is required on the Zaurus production environment.
  • When there are high-risk information security incidents.
  • If a faster rollout is required according to the SLA and impact of the failure.

5 Privacy and information security

5.1 Privacy

Zaurus complies with current legislation in the field of privacy and information security. Zaurus employees are obliged to treat personal data confidentially (this is contractually secured). Zaurus complies in all cases with the legal regulations that apply to the protection of personal data (i.e. General Data Protection Regulation and HIPAA). For more information about your rights and obligations, please refer to our data protection officer.

Telephone: +31 72 – 202 9123
Email: dpo@zaurus.nl

If you would like more information, we refer you to the website of the Dutch Data Protection Authority: www.autoriteitpersoonsgegevens.nl.

5.2 Information security

Information security has the highest priority at Zaurus. Zaurus has taken all necessary technical and organizational measures to guarantee the security of information. Zaurus is NEN 7510 and ISO 27001 certified and is regularly pen tested.

Zaurus has appointed a Chief Information Security Officer (CISO) to ensure that information is properly secured in accordance with relevant standards and that compliance with legal requirements and regulations in the field of information security and privacy is in place.

CISO: Michelle Spit
Telephone: 072 – 202 9123
Email: michelle@zaurus.nl

5.3 Hosting location

The Zaurus services are hosted in highly secured and ISO 27001 certified data centers within the European Union.

Zaurus also uses a redundant infrastructure from two locations to guarantee the availability and uptime of the Zaurus services.

5.4 Monitoring

Zaurus uses various software tools to monitor and guarantee the availability, security and performance of the Zaurus services, infrastructure and network components.

Zaurus is not responsible for monitoring components used by the Client in the Zaurus services, such as non-Zaurus applications.

5.5 Back-up en recovery

Zaurus has set up a backup and restore procedure.

In case of calamities, data can be restored up to 14 days in the past at the request of the Client.

Immediately after notification, at the latest on the next working day, the backup will be secured and the restore procedure will be started. Based on the impact and the type of data loss, it will be determined how and within what period the data will be made available to the Client.

If the cause of the restore can be attributed to a user error, the costs will be charged on the basis of subsequent calculation.

If a calamity occurs on the entire Zaurus platform, a restore will be initiated by Zaurus and will return to the “Last known good configuration”.

6 Finance

The Zaurus services are made available to the Client on the basis of expected use for an amount per month. This means that the number of employees is unlimited and that the app can be rolled out at all of the Client’s workplaces without additional costs.

If the use is so successful that the set limits are exceeded, the parties will enter into consultation.

Assignments for consultancy, integration support or chatbot development will be quoted separately. The following rates apply: 

Consultancy: 150,- euro per hour

  • Advice and project support;

Support: 125,- euro per hour

  • Implementation support;
  • Integration support;
  • Chatbot development.

Appendix 2 – Standard reports

Ticket overview

The overview report can be found in the support portal: https://support.zaurus.nl.

Availability report

The availability report can be found via the following link: https://status.zaurus.io.

Appendix 2 – Incident matrix and examples

SLA incident matrix



  • Zaurus is not available for the entire organization.
  • Main functionality such as chat and video calling is not available for the entire organization.
  • Entire organization cannot log in.
  • Consulting room is not created from API (API responsibility lies with Zaurus, integration lies with the Client).
  • Messages do not arrive.


  • Video calling via, for example, the iOS version of Zaurus is not available.
  • Push notifications are not received regardless of device.
  • Entire organization is experiencing delay during video calling (and this is not related to the internet).
  • Attachments cannot be sent.
  • Screen sharing not working from web / desktop app.


  • Push notifications on, for example, the Android version of Zaurus are not received.
  • Email notifications are not sent by Zaurus platform.
  • Video recording is not available.
  • Full screen of video stream does not work within an app.
  • Add attachment on one app does not work.


  • Video calling for one individual on specific mobile device not available.
  • Password reset for one individual does not work.
  • Font in the text bar of a chat message is different from the font in the chat.
  • Special characters are not displayed properly.
  • Consulting room pdf cannot be downloaded if there is a special character in the subject.

Appendix 3 – Glossary

Corrective maintenance: Make the Zaurus services function in accordance with the specifications as agreed and recorded. Corrective maintenance is aimed at resolving incidents and disruptions.

Preventive maintenance: Is aimed at preventing incidents, errors, defects and / or disruptions in the Zaurus services (reduction of corrective maintenance).

Working days: Working days means every day with the exception of Saturdays and Sundays, New Year’s Day, Easter Monday, King’s Day, Ascension Day, Whit Monday, Christmas Day and Boxing Day.

Resolution time: The period of time between receiving a notification and having a response or solution available in the event of an incident. There can be time between having a solution available and having the solution live on the production environment.

Response time: The period of time within which contact is sought with the reporter and the diagnosis of the incident is started, or the time between obtaining a question and confirming to the customer that the question has been received.

Diagnosis: Analysis of the report, classification and solution direction.

Report: A report is a signal from the Client to the helpdesk related to the Zaurus services. Notifications are divided into the following categories:
Question, Request for Service, Incident, Feature request.

Incident: An incident is a bug, error or disruption in the Zaurus services.

Question: A question is a report that can be resolved simply by answering it. No action needs to be taken or there are no immediate changes to the infrastructure or the application. Repeated questions about a particular topic can lead to action and / or change proposals. Questions reported via the portal are registered in the service desk system.

Feature request: a request for a new functionality for one of Zaurus’ services.

Support / support:

First line: Solving malfunctions and problems and answering questions by the Client’s helpdesk employees.
Second line: Solving malfunctions and problems and answering questions by the Client’s application managers to the Client’s helpdesk employees.
Third line: Solving malfunctions and problems and answering questions by Zaurus to the Client’s application managers.

Disruption: A situation related to failure or malfunctioning of (part of) the application. Such an incident will often lead to an update of the part / app to which it relates.

Calamity: An unplanned situation with a major impact on the end users where the Zaurus services are not available, i.e. an incident with priority “Urgent”.

Problem: A problem is, in general, a structural cause of multiple incidents.

In order to offer you the right products, we would like to know how many employees your organization has.