Annex D – OX Cloud Easy Service Card and SLA
1 General Terms
1.1 Purpose
This document provides the support service details associated with the Service.
1.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
Open-Xchange GmbH 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.
The probe will be considered a failed probe if this sequence is not successfully completed within a total sequence time of thirty (30) seconds or less.
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.
The probe will be considered a failed probe if this sequence is not successfully completed within a total sequence time of thirty (30) seconds or less.
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 server.
The probe will be considered a failed probe if this sequence is not successfully completed within a total sequence time of thirty (30) seconds or less.
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.
The probe will be considered a failed probe if this sequence is not successfully completed within a total sequence time of thirty (30) seconds or less.
1.2.6 Performance Threshold
If any of these probes returns in more than five (5) seconds over a period longer than fifteen (15) minutes, it is stipulated as performance Incident and Open-Xchange GmbH will start an analysis with the goal to improve performance.
1.2.7 Primary Services
Shall mean the webmail interface, IMAP, POP3 and SMTP.
1.2.8 Secondary Services
Shall mean the provisioning API, CalDAV/CardDAV, OX Text, OX Spreadsheet, OX Presentation and Email Rountrip.
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.
Open-Xchange GmbH 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
Open-Xchange GmbH 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
Open-Xchange GmbH 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
Open-Xchange GmbH 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
Open-Xchange GmbH 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
Open-Xchange GmbH 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
Open-Xchange GmbH 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”) Open-Xchange GmbH shall be authorised to maintain the underlying components (hardware and software) for the Service. Open-Xchange GmbH 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). Open-Xchange GmbH 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 Open-Xchange GmbH’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 Open-Xchange GmbH is subject;
- Unavailability due to virus or hacker attacks, insofar as Open-Xchange GmbH 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.
2 Service Level Agreement
2.1 Committed Solution Availability
Company will use reasonable efforts to reach a Solution Availability of 99.9% of the entire time in a month.
2.2 Service Credit Amounts
Company will use reasonable efforts to provide all Services in accordance with the following Solution Availability. Company will credit Customer’s account with service credits as follows:
| Solution Availability | Days of Service to the end of Customer Term without additional charge |
| 99.9% or higher | – |
| 99.7% – 99.89% | 3 |
| 99.0% – 99.69% | 7 |
| 98.99% or below | 15 |
By the 15th day of each month during the Term, Company will provide Customer with monthly reports detailing the Solution Availability provided in the previous month. At that time any credits will be calculated, and Customer can claim them accordingly within 30 days. Force Majeure or any Incident outside the sphere of influence of Company as well as the cases in Section 1.2.11 are excluded.
The aggregate maximum number of Service Credits to be issued by Company to Customer for all Solution Unavailability in a single calendar month shall not exceed fifteen days of Service added to the end of Customer Term. Service Credits may not be exchanged for, or converted to, monetary amounts.
2.3 Response Times
Company will respond to an Incident which has been reported by Customer for getting resolved by Company by assigning a resource and by responding to the request in the time frame outlined in the SLA. Response Times are applicable for the initial response to the Customer’s request. The Response Time begins as soon as the respective ticket has been reported to Company following the process described in the SLA.
The following Response Times apply for Severity 1 and 2 Incidents reported by Customer:
2.3.1 Severities
The Severity of an Incident is determined by its impact to Customer’s business and therefore defines the urgency of solving an Incident.
2.3.1.1 Severity 1
Severity 1 shall mean Incidents that are defined as a complete outage of either a Primary Service or an interruption or malfunction causing a critical impact on Customer’s business with no possible Workaround, meaning it affects more than 35% of the Users deployed on the system.
Also means a concrete security threat causing an imminent risk to the Customer’s or a User’s data integrity to lead to an unintended data disclosure.
2.3.1.2 Severity 2
Severity 2 shall mean that the Customer’s business is severely disrupted. This is the case when a Primary Service is performing below the defined Performance Threshold or cannot be used by more than 10% of the provisioned Users on the system. A major functionality (e.g. search function, ability of users to create new contacts), or a Secondary Service cannot be used by more than 35% of the Users.
2.3.1.3 Severity 3
Severity 3 shall mean Incidents, which involve partial loss of non-critical functionality, one that impairs many operations, but allows the Customer to continue to operate. Also means issues occurring in a Staging Environment that would normally cause a Severity 1 or Severity 2 Incident to the Production Environment.
2.3.2 General
| Severity | Resource assigned and initial response |
| 1 | 2 hours |
| 2 | 4 hours |
| 3 | Reasonable efforts |
2.3.3 OX Drive Clients
| Severity | Resource assigned and initial response |
| 1* | 4 hours |
| 2 | 8 hours |
| 3 | Reasonable efforts |
Business Day means any day other than a Saturday or Sunday, and all public holidays in Germany incl. Christmas Eve and New Year’s Eve.
2.4 Exclusions from Support and SLA
Company provides support for analysis of all reported Incidents.
Recommendations for the configuration of components not part of the Service will be provided on best effort. Restoration and Resolution for such components will not be provided. Such components include, but are not limited to:
- Synchronization with End User Devices and 3rd Party Client Software, for example:
- IMAP Clients
- Groupware and Collaboration Clients
- Clients on Mobile Devices
2.5 Exclusions from Support and SLA for OX Drive Clients
Support and SLA of the OX Drive Clients exclude the process and time for the processing of any software update or patch through the respective AppStores being Apple iOS AppStore, Apple Mac AppStore and Google PlayStore (delivery channel). Company cannot control or determine whether or not an AppStore provider accepts an update or patch or which time it takes for making an update or patch available. Company is not liable for any damage related to the unavailability of an update/patch in the respective AppStore.
The conditions described in this document only relate to the time that it takes company to make a patch or update available to be processed by the respective delivery channel (e.g. AppStore). It does not include the time for the processing in the respective delivery channel.
Excluded are device specific Incidents related to a particular device, brand or model. Support is only provided for the defined operating system version and defined reference devices as published on Company’s website.
3 Interaction with FUAGO Support
3.1 Reporting Incidents with FUAGO
To report an Incident or Problem to Company, a support ticket has to be filed per E-Mail. For this purpose, Customer gets a dedicated Customer ID from Company. When filing an Incident ticket, that ID has to be entered into the body of the E-Mail to Company.
The Incident will then get a priority based on the ID and the relevant Support Level Agreement. Customer and Company shall exclusively communicate through Company’s ticket system (directly or via email) or other jointly agreed communication tools.
3.2 How-To Contact Support
- Send an email to oxcloud-support@fuago.io
- Provide your Customer ID and a detailed description of the issue in the email body.
4 Escalation Process
4.1 Customer Escalation
The table below gives timings for each severity level after which it is appropriate for Customer to escalate the Incident to a particular level.
| Severity | Level 1 Escalation | Level 2 Escalation | Level 3 Escalation |
| 1 (not restored) | 6 hours after target time | 10 hours after target time | 14 hours after target time |
| 2 (not restored) | 12 hours after target time | 48 hours after target time | 96 hours after target time |
4.2 Open-Xchange Escalation
The table below gives timings for each severity level after which it is appropriate for Company to escalate the call to a particular level.
| Severity | Level 1 Escalation | Level 2 Escalation | Level 3 Escalation |
| 1 | 1 hour after request for Information was not effectively and/or timely responded | 3 hour after request for Information was not effectively and/or timely responded | 5 hour after request for Information was not effectively and/or timely responded |
| 2 | 3 hour after request for Information was not effectively and/or timely responded | 16 hour after request for Information was not effectively and/or timely responded | 24 hour after request for Information was not effectively and/or timely responded |
4.3 Customer Escalation Contact Data
The relevant contact information of both parties can be found within the Service Runbook.
4.4 Support Levels
The Support Levels are as follows:
4.4.1 Level 1
“Level 1 Support” shall mean first point of contact for telephone and email support provided in response to the initial inquiry placed by a User. Level 1 Support answers questions regarding product operation generally or identifies, troubleshoots and escalates Incidents based on defined processes, including provision of compatibility information, installation assistance and usage support.
4.4.2 Level 2
“Level 2 Support” means technical support beyond Level 1 Support via telephone and email. It is the first point of escalation and provides guidance and instructions to Level 1 Support to diagnose and resolve the Incidents. Level 2 Support takes the ownership of Incidents where subject matter experts and experience are required for diagnosis, Problem isolation and Resolution of Incidents, including efforts to duplicate the behaviour reported by Users.
4.4.3 Level 3
If, despite reasonable efforts, Level 2 Support it is unable to resolve an Incident then the Incident is escalated to “Level 3 Support”. This shall mean the technical support service provided for error resolution for Incidents which Level 2 Support has identified, and which require changes to Open-Xchange GmbH Products to resolve the Incident.