Terms & Conditions
General Terms
1.1 Purpose:
This document provides the support service details associated with the Service1.2 Availability Terms
1.2.1 Solution Availability
Is the time available per month reduced by the cumulated occurrences of Solution Unavailability expressed as percentage. Solution Availability will be calculated as follows: Services may depend on the availability of external components, e.g. name servers, external authentication services, and the possibility to connect to those services elsewhere over the network or the internet. Any unavailability of external components does not count as Solution Unavailability of the platform. Any Solution Unavailability due to a root cause in the responsibility of the Customer is not accounted against the Solution Availability.
1.2.2 Webmail Availability Measurement
Company will measure webmail performance to determine Solution Availability by setting up a probe. The following sequence of steps will be followed by the probe:- Connect to HTTP server;
- Perform a login request for App Suite;
- Perform a logout request for App Suite; and
- Disconnect from the server.
1.2.3 POP3 Availability Measurement
The following sequence of steps will be followed by the probe:- Connect to the POP server;
- Perform a user command;
- Perform a pass command;
- Perform a list command;
- Perform a quit command; and
- Disconnect from the server
1.2.4 SMTP Availability Measurement.
The following sequence of steps will be followed by the probe:- Connect to the SMTP server;
- Perform an EHLO command,
- Perform an AUTH LOGIN command,
- Perform a QUIT command, and
- Disconnect from the server
1.2.5 IMAP Availability Measurement.
The following sequence of steps will be followed by the probe:- Connect to the IMAP server;
- Perform a user command;
- Perform a pass command;
- Perform a list command;
- Perform a quit command; and
- Disconnect from the server.
1.2.9 Secondary Service Availability
Availability of a Secondary Service, as outlined below, is the time while an automated probe or an agent is able to use the Secondary Service via the internet. Company will gather availability metrics for the Secondary Services by running probes against these interfaces. These probes will be conducted using three monitoring systems (one internal and two externals to the Service datacenter) in parallel. In the event that two monitoring systems return a failure at the same time over a period of five (5) minutes for the same Secondary Service, such occurrence shall be registered as an Incident of Severity 2 but does not account against the Solution Availability. For all probes, test accounts are used which are able to perform the probes without interaction of any external systems (e.g. external SSO/PW verification systems).1.2.9.1 Provisioning API Measurement
Company will measure provisioning API performance by setting up a probe. The following sequence of steps will be followed by the probe:
- Connect to SOAP API;
- Create a context
- Create a user in the new context
- Delete the user
- Delete the context
- Disconnect from the server.
The probe will be considered a failed probe if one of the actions taken between connect and disconnect is not successfully completed within a total sequence time of one hundred and twenty seconds (120) seconds or less for three consecutive probes. These checks can only be performed every 15 minutes
1.2.9.2 CalDAV API Measurement
Company will measure CalDAV API performance by setting up a probe. The following sequence of steps will be followed by the probe:
- Connect to CalDAV API;
- Create and appointment
- Delete the newly created appointment
- Disconnect from the server.
The probe will be considered a failed probe if this sequence is not successfully completed within a total sequence time of sixty (60) seconds or less.
1.2.9.3 CardDAV API Measurement
Company will measure CardDAV API performance by setting up a probe.
- Connect to CardDAV API;
- Creating a contact
- Deleting the newly created contact
- Disconnect from the server.
The probe will be considered a failed probe if this sequence is not successfully completed within a total sequence time of sixty (60) seconds or less.
1.2.9.4 OX Text Measurement
Company will measure OX Text performance by setting up a probe. The following sequence of steps will be followed by the probe:
- Connect to HTTP server;
- Perform a Login request for App Suite;
- Open a defined document;
- Perform a logout request for App Suite; and
- Disconnect from the server.
The probe will be considered a failed probe if this sequence is not successfully completed within a total sequence time of ninety (90) seconds or less.
1.2.9.5 OX Spreadsheet Measurement
Company will measure OX Spreadsheet performance by setting up a probe. The following sequence of steps will be followed by the probe:
- Connect to HTTP server;
- Perform a login request for App Suite;
- Open a defined spreadsheet;
- Perform a logout request for App Suite; and
- Disconnect from the server.
The probe will be considered a failed probe if this sequence is not successfully completed within a total sequence time of ninety (90) seconds or less.
1.2.9.6 OX Presentation Measurement
Company will measure OX Presentation performance by setting up a probe. The following sequence of steps will be followed by the probe:
- Connect to HTTP server;
- Perform a login request for App Suite;
- Open a defined presentation;
- Perform a logout request for App Suite; and
- Disconnect from the server.
The probe will be considered a failed probe if this sequence is not successfully completed within a total sequence time ninety (90) seconds or less.
1.2.9.7 Email Roundtrip (RTT)
The following sequence of steps will be followed by the probe:
- Deliver email via SMTP;
- Login to IMAP service;
- Verify availability of the test email from first step in mailbox; and
- Disconnect from the server
The probe will be considered a failed probe if all probes of this sequence are not successfully completed within a total sequence time of ten (10) minutes or less over a period of longer than thirty (30) minutes.
1.2.10 Maintenance Time
Between 12am and 6am CET (“Maintenance Time”) Company shall be authorised to maintain the underlying components (hardware and software) for the Service. Company will use reasonable efforts to ensure maintenance is conducted with minimum level of impact for the Users, leveraging the technical capabilities of the software and the redundancy of the underlying hardware (for example rolling restarts of the services without interruption of user sessions). Company will use reasonable efforts to minimize the required maintenance time.1.2.11 Solution Unavailability
Shall mean the time during which a Primary Service is not available as defined under Solution Availability and such unavailability is not due to a planned activity, Maintenance Time or the following cases:- Unforeseen Maintenance that becomes necessary if this work was not caused by a breach of Company’s obligations to provide the services (force majeure, in particular unforeseeable hardware failures, strikes, natural disasters, etc);
- Unavailability that becomes necessary in order to comply with a legal obligation Company is subject;
- Unavailability due to virus or hacker attacks, insofar as Company has taken the agreed security measures or, in the absence of such an agreement, the security measures according to standard business practices;
- Unavailability due to Customer specifications, non-availability of Customer equipment or other interruptions caused by Customer (including failure of Customer to provide assistance);
- Unavailability caused by Customer blocking console or remote access;
- Unavailability caused by any third parties outside the responsibility of Company.
1.3 SLA Applicability Requirements
The provisions of this SLA shall not apply until the Customer has accepted the solution and the solution is in productive operation. The SLA is also not applicable for OX Cloud running a non-production environment (e.g., training, development and integration). Obligations hereunder only apply if the following conditions are met:- Customer has paid in full all outstanding fees under the Agreement
- Customer provides test account(s) within the Service
- The respective Incident has been reported through Company’s ticket system in English
1.4 Processes and Communication
1.4.1 Service Request Process
Company will manage all Service Requests during Business Days in an organized and structured way to ensure minimum impact on Customer services. Every Service Request needs to be filed following the agreed “Service Request Management process” as defined within the Service Runbook.
1.4.2 Maintenance Announcement Process
At least five (5) Business Days prior to each planned Maintenance, Company will provide a description of its scope along with the expected impact to Users and will document progress and status of each ongoing Maintenance as defined within the Service Runbook.
1.4.3 Pro-Active Incident Communication
In case Company determines a significant Incident to the Service, Company will pro-actively inform Customer, as defined in the Service Run-Book.