SLA - Service Level Agreement

Deprecation Notice

This document is superseded by the following two documents:

Version of the document: May 2020

1. Preamble

This Service Level Agreement ("SLA") regulates the standard service levels for support and services of VSHN and applies if and insofar as the contract between the customer and VSHN refers to this SLA.

2. SLA Term and Remuneration

Subject Description

Duration

An SLA is generally valid for the duration of an order, but can be terminated at any time by either party in writing with 30 days' notice to the end of the month. The SLA ends automatically at the end of the corresponding order.

SLA and remuneration

The customer can choose between the following SLAs:

  • SLA Standard

  • SLA Professional

  • SLA Premium

Unless otherwise specified in the contract, the 'Standard SLA' applies. The remuneration for the SLA is based on the contract with the customer.

Upgrade and downgrade

An SLA upgrade, if available, can be performed at any time, and an SLA downgrade can be performed subject to the notice period.

3. Overview & VSHN Services

This SLA contains regulations with regard to the following VSHN services:

VSHN offers the following three options for customers in terms of SLA:

  • SLA Standard: Service desk availability and independent response to service incidents by VSHN during business hours;

  • SLA Professional: "SLA Standard" and additionally 24/7 availability of the service desk;

  • SLA Premium: "SLA Professional" and additionally independent reaction to service incidents by VSHN 24/7.

Further services are not the subject of these SLAs, in particular:

  • Third-party infrastructure and services (cloud and hardware infrastructure, network, etc);

  • Third-party software;

  • All services that do not relate to the existing productive operation;

  • Consulting, training and other requests as defined below under Service Desk Categories;

  • Support of other requests, e.g. user hardware, configuration of the operating system, network and internet of the users and other software not supplied by VSHN;

  • Trainings.

4. Support

4.1. Use by the Customer

The following cooperation obligations are to be fulfilled by the customer for the contractual provision of the service desk services by VSHN:

  • Use of the electronic ticket system

  • Registration on the status page status.vshn.net.

4.2. Classification

With regard to customer inquiries at the service desk, VSHN distinguishes between Incidents, Change Requests und Support Requests:

Category Description SLA

Incident

An unplanned interruption or reduction in quality of a VSHN IT service.

According to the following description.

Change Request

A Change Request deals with any type of change to an IT infrastructure or IT service that was not defined in the original setup. Major updates or upgrades are also considered to be change requests.

Response with cost estimate for the change within 10 working days.

Support Request

A Support Request stands for general support requests such as information on the structure/setup/design of the infrastructure and services, possibilities for improvement, consulting & training etc.

Response with cost estimate for the support request within 10 working days.

4.3. Contact & Availability Times

The support is available as follows:

Availability support Ticket system E-mail Phone

SLA Standard

Mon - Fri from 9:00 am to 6:00 pm CET / CEST (excluding public holidays in the canton of ZH, Switzerland)

control.vshn.net

support@vshn.ch

+41 44 545 53 53

SLA Professional and Premium

Mon - Sun from 00:00 to 24:00

Special number according to contract

Depending on the severity level, the following process applies for establishing contact:

  • Severity 1-5: Create ticket (via ticket system or e-mail)

  • Severity 1-2: additional telephone

For escalations, commercial issues, setup and larger Change Requests, the customer has access to the contact persons according to the contract.

5. Incident Management

5.1. Severity Levels

Incidents are prioritized as follows:

Severity Level Description

1 (Emergency)

The problem prevents the continuation of business at several workstations. Examples:

  • Access to business-critical core applications is not possible in central functions (direct impact on business activity)

  • Business-critical processes cannot be carried out, such as the ordering process in an online shop (loss of turnover)

2 (Blocker)

The contracting party’s problem prevents the continuation of an important activity at several workplaces. Examples:

  • Functions in core applications cannot be executed in central subareas.

  • An immediate workaround is not possible or foreseeable.

3 (High)

The problem hinders the continuation of an important activity. Examples:

  • Functions in the core applications cannot be executed in individual areas or can only be executed very slowly.

4 (Normal)

The issue hinders work in a less important area. Examples:

  • Small parts of application or development environment are not accessible or delayed / slow

  • Access to the core applications as defined is not possible in non-business critical functions

  • A bypass solution is available or can be set up / does not cause significant additional work

5 (Minor)

The customer is not hindered in his work. (For inquiries, suggestions, etc.)

5.2. Reaction and intervention times

The response times are determined on the basis of the severity level and the availability times of the support of the selected Service Level according to the following table.

SLA Standard SLA Professional SLA Premium

Customer priority

3 (low)

2

1 (high)

VSHN Monitoring

Office hours

Office hours

24/7

Ticket/Phone

Office hours

24/7

24/7

Severity Level

Reaction

Intervention

Reaction

Intervention

Reaction

Intervention

1

4h

8h

2h

4h

1h

2h

2

8h

16h

4h

8h

2h

4h

3

12h

24h

8h

16h

4h

8h

Input of the fault message means:

  • Creating the ticket at Severity 3-5

  • Phone call at Severity 1&2

  • Alarming the VSHN monitoring system

The response time is the time between the receipt of a fault message at VSHN and the start of fault analysis.

The intervention time is the time between the receipt of a fault message at VSHN and the start of work to rectify the fault.

For the calculation of the time periods, the working hours according to the availability of support shall apply. Hours outside of availability are not taken into account for the calculation.

If a workaround is provided, VSHN is entitled to change the priority of the error or fault message accordingly.

After receipt of the incident report, the customer is informed via the defined channels. Where necessary, the customer is informed about the status with regular updates.

The customer is finally informed after the incident has been resolved. Where possible, measures are taken by VSHN or in cooperation with the customer to prevent or minimize such incidents in the future.

Priority 4 and 5 requests are processed in the normal course of support work, without a specific response time being agreed. Priority 4 issues will are usually included in the next maintenance release and priority 5 issues containing proposed changes as defined in Section 5.2 above are taken into account in the planning for the next maintenance release.

VSHN prepares a report on compliance with the service levels at the request of the customer.

6. Support and Change Requests

6.1. Change Request Management

A Change Request deals with any type of change to an IT infrastructure or IT service that was not defined in the original setup. If the customer requires adjustments to existing functions and/or the system, these will be accepted for execution within the framework of the agreed conditions. In the case of a Change Request, the customer is informed in advance of the estimated time required for the implementation, and the estimated hours of work to be charged are presented to the customer in a formal offer for approval and assignment. A Change Request must be issued via control.vshn.net.

Change Request Acceptance and Prioritization

The customer can submit a Change Request by ticket via control.vshn.net and prioritize it by severity level.

Reply to a Change Request

VSHN usually responds to Change Requests within 10 working days and prioritizes the Change Requests according to the customer’s severity level. The answer contains:

  • Overview of the feasibility and benefits of the Change Request;

  • Estimated effort and costs for implementation;

  • If necessary, further questions and further steps to clarify them.

The customer can accept or reject the change request based on the response.

6.2. Support Request Management

A Support Request stands for general support requests such as information about setup/setup/design of the infrastructure and services, improvement possibilities, consulting & training etc. and can be submitted via control.vshn.net or telephone during support’s availability hours. VSHN usually responds to support requests within 10 working days.

7. Services

The exact contents of a service are defined in the general or product-specific service description.

7.1. Service availability

The availability of specific VSHN services is typically regulated in the corresponding service description. If nothing is regulated, an availability of 99% per month is valid for continuously provided services for which an availability is relevant and measurable.

A service is considered available when it can be reached by VSHN. The 100% availability is calculated on the basis of 24/7 operation. In calculating the effective availability, failures of less than 5 minutes and due to the following exceptions are not considered:

  • Availability of third-party and customer infrastructure and services (including cloud and network providers)

  • A change commissioned by the customer or carried out by the customer himself and not approved by the provider, which leads to the failure of the service.

  • Time periods during which previously announced maintenance work is carried out.

  • An error that is not attributable to the service provided by the provider (e.g. lack of availability of a third-party provider).

  • An error that can be traced back to the general operational risk of an Internet connection (e.g. impairment by DoS attacks, etc.).

  • Changes to devices, connections, network plans, applications operated by the Provider on behalf of the Customer that were not carried out by the Provider.

  • The customer has reported an error, although none was present.

  • Errors within the software, provided that these do not affect the basic characteristics necessary for the provision of the service.

  • Errors within the software that relate to individual functional characteristics of the software but do not reduce the availability of the contractually agreed service, do not reduce the availability and are not classified as Critical.

  • Failures caused by configurations made by the customer.