Annex D – Service Level Agreement

 

1. General Terms

1.1. Purpose

This document provides the Service Level Agreement as well as 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

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.

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 Company will start an analysis with the goal to improve performance.

1.2.7. 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.7.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.7.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.7.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.7.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.7.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.7.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.7.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.8. 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. For the provision of Services by Open-Xchange, Inc, 228 Hamilton Avenue, Third Floor, Palo Alto, CA 94301, USA the Maintenance Time shall be between 12am and 6am EST.

1.2.9. 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:

1. 1. 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);
2. 2. Unavailability that becomes necessary in order to comply with a legal obligation Company is subject;
3. 3. 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;
4. 4. Unavailability due to Customer specifications, non-availability of Customer equipment or other interruptions caused by Customer (including failure of Customer to provide assistance);
5. 5. Unavailability caused by Customer blocking console or remote access;
6. 6. Unavailability caused by any third parties outside the responsibility of Company.
7.  

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:

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 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 Incidents reported by Customer:

 

2.3.2     General

 

2.3.3     OX Drive Clients

* Severity 1 only applies for Security Incidents

 

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 3^rd 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 Company Support

3.1. Reporting Incidents with Company

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 support key from Company. When filing an Incident ticket, that key has to be entered into the body of the E-Mail to Company.

The Incident will then get a priority based on the key 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. Phone Support for Incidents

In case of Severity 1 and Severity 2 Incidents it is possible to contact Company Service Desk via phone after Incident ticket has been created.  Customer is provided with specific support phone numbers for Germany, France, Japan, UK and USA  after conclusion of the Order Form.

3.3. How-To Contact Support

Customer shall provide the required information in each Incident ticket as defined under

https://support.open-xchange.com 

In this article Company provides an email template, which prompts for the relevant information.

If there are important parts of the information missing, the missing information has to be provided without delay. The guaranteed Reaction and Restoration Times are only applicable if all information mentioned above is available, the description is easy to understand, and the ticket has been reported in English.

Customer can track their reported tickets online as described at

https://oxpedia.org/wiki/index.php?title=TicketSystemCustomerGuide

 

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.

 

 

4.2. Company 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.

 

 

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 Company Products to resolve the Incident.