The English version of this document is considered the legally binding original. Automated translations are provided only for convenience. In case of contradiction, the English original is valid.
1 Components of the Service Level Agreement
1.1 The Service Level Agreement (SLA) per service instance comprises three components of quality aspects:
Support Plan
Backup Plan
Business Continuity Plan
1.2 In the signed offer one subscription plan is selected per subscription:
Team: includes Support Plan Basic, Backup Plan Week and Business Continuity Plan Standard
Business: includes Support Plan Extended, Backup Plan Week and Business Continuity Plan Extended
Enterprise: this is a customised subscription plan with subscription plan Business as the baseline. The signed offer specifies the selected custom options that adapt the baseline.
1.3 The Support Plan component regulates the availability and responsiveness of IT services and support. The available predefined Support Plan are described in section 4. Customer-specific SLA arrangements can be agreed on in the offer. If nothing specifically is agreed, Support Plan Basic will be assumed.
1.4 The Backup Plan component regulates the creation of backups of the system and data and their retention. The available predefined backup plans are described in section 6. Customer-specific plans can be agreed on in the offer. If nothing specifically is agreed, Backup Plan Week will apply.
1.5 The Business Continuity Plan component defines the targets regarding the handling of extensive system failures. The available predefined business continuity plans are described in section 7. If nothing specifically is agreed, Business Continuity Plan Standard will apply.
1.6 If you are using Phonemos outside the Phonemos Cloud environment hosted by linkyard, only section 6 Bug Fix Policy and the time to first response as specified in section 4 Support Plan applies. System availability, backups etc. are the responsibilities of the Customer and its other sub-processors.
2 Definitions
2.1 The operating time is the period of time during which the productive systems are available to the customer.
2.2 The standby time is the period of time during which provider staff can ensure support of the service and receive and process messages. The time measurement for the response and resolution time is interrupted for the time outside the standby time.
2.3 The time to first response is understood to be the period of time within the standby time from the time the message is received in the linkyard customer portal (https://servicedesk.linkyard.ch/) with sufficient information to identify and classify the request until it is put to work by an employee of the Provider.
2.4 The resolution time is understood to be the period of time within the standby time from the beginning of the processing of a message by an employee of the Provider until its resolution (fault elimination or answering the request) minus the waiting time for solution contributions by the Customer or third parties commissioned by the Customer.
2.5 Downtime defines a period during operating time within which the service was entirely unavailable to the users.
2.6 The system availability is evaluated on an annual basis and is calculated from the operating time minus the system downtime in relation to the operating time, whereby announced interruptions during the agreed maintenance windows are not counted as system downtime.
2.7 A maintenance window is the period of time during which the provider is allowed to carry out planned maintenance work on the system.
2.8 An incident is classified by the Provider acting reasonably and in good faith on the basis of the actual operational impact known to the Provider at the time. The Provider may reclassify an incident if additional information becomes available.
3 Error Classes
3.1 Software errors and operational faults are divided into the following error classes:
Class | Definition | Criteria |
|---|---|---|
Blocker | Preventing operation The error does not allow the product to be used for its intended purpose. |
Complete interruption of operation. Central functions of the system cannot be used. All of the customer's users are affected. No workaround solutions are available. Example: Login is not possible. |
Critical | Partially preventing operation Use in accordance with the main purpose of use is guaranteed. However, there is a significant error in an important sub-function or work can only be ensured by using complex workarounds. |
Partial operational interruption. Central functions of the system cannot be used. A majority of the customer's users are affected. The customer can use an organisational or technical workaround solution for a limited period of time. Example: An interface to an important third-party system (e.g. SAP) is not working. |
Average | Impeding operations The use of the software in accordance with its main purpose is guaranteed. However, there are errors in sub-functions that make work more difficult. |
No interruption to operation. Central functions of the system can be used. Obstruction of only a few of the customer's users. Workaround solutions are not necessary. Example: Master data cannot be customised via the GUI. |
Minor | Disruptive Errors that only marginally affect the use of the solution. |
No interruption to operation. Minor impairment due to avoidable additional work, lack of comfort. Workaround solutions are not necessary. Example: spelling mistakes, errors in the documentation. |
3.2 The defect classes Blocker and Critical are considered significant defects, the defect classes Average and Minor are considered insignificant defects.
4 Support Plan
4.1 The time to first response values set out in this Section apply only to fault reports and support requests submitted via the Provider's ticketing portal (or a successor support portal designated by the Provider), sufficiently described by the Customer and classified by the Provider in accordance with Section 3.
4.2 Unless expressly agreed otherwise in the signed or accepted offer, the SLA does not include guaranteed resolution times. The Provider will use commercially reasonable efforts to resolve incidents in accordance with their classification and operational priority.
Support Plan: | Basic | Extended | Premium |
|---|---|---|---|
Service times, system availability | |||
Production uptime | 7x24, 365 | 7x24, 365 | 7x24, 365 |
Operating time test system | on demand | on demand | on demand |
System availability | >99.0% | >99.6% | >99.9% |
Standby time | Office hours1 | Office hours1 | 7x24, 365 |
Time to first response during office hours | |||
Blocker | Best Effort | 4 hrs. | 1 hr. |
Critical | |||
Average | next | 4 hrs. | |
Minor | next | ||
Other enquiries | |||
Time to first response outside office hours | |||
Blocker | Best Effort | next | 2 hrs. |
Critical | 4 hrs. | ||
Average | next | ||
Minor | |||
Other enquiries | |||
1: Monday to Friday 07:00-18:00, excluding federal and cantonal public holidays in the Canton of Berne
5 Maintenance Windows
5.1 The provider may apply changes to the test and production systems without prior notice at any time. Any downtime caused by such changes is taken into account for the calculation of system availability.
5.2 The provider applies changes to the system on the basis of a risk analysis. For changes with considerable risks, the provider may request the customer to conduct tests prior to the application to the production system.
5.3 Major planned maintenance work (e.g. elaborate software updates, migrations, etc.) takes place at a time explicitly agreed with the customer in advance. The corresponding system downtime is not taken into account in the calculation of system availability.
5.4 Emergency maintenance may be performed at any time if reasonably necessary to preserve the security, integrity or stability of the services. The Provider will use reasonable efforts to notify the Customer as soon as practicable.
6 Bug Fix Policy
6.1 In the case of third-party services (like LLM or translation services), their service provisions and bug fix policies apply. The Provider has no direct influence on this and this section does not apply.
6.2 The Provider's support team assists the customer in the search for workarounds and error detection.
6.3 Software errors in the provider's own developments are generally handled as follows based on the error class:
Class | Treatment strategy |
|---|---|
Blocker | Corrections are prioritised with the aim of being able to meet the guaranteed system availability in accordance with the selected SLA. Error corrections are put into production outside of any release planning if necessary. |
Critical | Critical errors are usually fixed in the next maintenance release. |
Average | Average class errors are rectified if there are no other critical errors or project priorities. They are prioritised within the error class taking into account other criteria, in particular the number of affected users and customer instances, the availability of practicable workarounds and their significance for the future. |
Minor | Insignificant errors in the Minor class are usually corrected when our developers make changes in this area anyway and it makes sense to make the correction at the same time. |
6.4 The treatment strategies in this Section 6 are operational principles and do not constitute guaranteed resolution times unless expressly agreed otherwise in writing.
7 Backup Plan
7.1 The available predefined Backup Plans are set out in the table below.
7.2 The stated RPO and RTO values apply only to restorations from the most recent available backup within the selected Backup Plan, during standby time, subject to the technical feasibility of the restoration and the Customer's timely cooperation. Unless expressly agreed otherwise, the stated RTO assumes that the relevant cluster or data-centre location continues to function and that the data volume to be restored does not exceed 100 GB.
Backup plan: | Week | Month | Year |
|---|---|---|---|
Backup retention period | last 7 daily snapshots | corresponds to "Week" plus: last 4 weekly snapshots | corresponds to "Month" plus last 12 monthly snapshots |
Recovery Point | 24 hrs. | 24 hrs. | 24 hrs. |
Recovery Time | Response time (see section 4) plus 4 hours | Response time (see section 4) plus 4 hours | Response time (see section 4) plus 4 hours |
1: if the cluster/data centre location continues to function, up to 100 GB of data
8 Business Continuity Plans
8.1 The available predefined Business Continuity Plans are set out in the table below.
8.2 The descriptions in this Section 8 describe service capabilities and target operating models. Unless expressly agreed otherwise in the signed or accepted offer, they do not create separate quantified failover commitments, additional service credits or guaranteed disaster-recovery times beyond the system availability, RPO and RTO commitments expressly stated in this SLA.
Business Continuity Plan: | Standard | Extended |
|---|---|---|
System Site Redundancy | No, one location (cluster/data centre) An off-site backup is available. If necessary, the system can be put into operation with a time delay for a second infrastructure. | Yes, an additional disaster recovery site is available at a second infrastructure provider at all times, which could be put into operation in the event of a complete failure of the main site. |
Server | Yes, the system is operated on a cluster with several nodes. In the event of a failure, an automatic failover takes place. | |
Backup Site Redundancy | Yes, backups are also stored geo-redundantly and encrypted at a second location. | |
9 Reporting & Penalties
9.1 The Provider reports on the status of its clusters and planned mainte-nance windows via http://status.linkyard.ch/. The customer may sub-scribe to announcements.
9.2 SLA reports on system availability are evaluated for each consecutive twelve-month period of a Subscription, and pro rata for any shorter final period yearly by the Provider. In case of a contractual breach, a penalty calculated based on the percentage in below table of to the total invoiced subscription price of the SLA period considered is reimbursed to the customer in the form of a discount on future subscription fees invoiced.
System availability | Penalty Support Plan Basic | Penalty Support Plan Extended | Penalty Support Plan Premium |
|---|---|---|---|
>= 99.9% | 0% | 0% | 0% |
>= 99.6% | 0% | 0% | 5% |
>= 99.0% | 0% | 5% | 10% |
< 99.0% | 5% | 10% | 20% |
9.3 If other targets are breached, no penalties are owed by the Provider. In return, the Provider must analyse and report the causes that lead to the breach and propose measures to discuss with the customer.
9.4 Any service credit or contractual penalty under this Section 9 shall constitute the Customer's exclusive financial remedy for the relevant SLA breach, to the extent permitted by law.
9.5 Claims for service credits or contractual penalties must be asserted by the Customer in writing within sixty (60) days after the end of the relevant SLA period, failing which they lapse. Service credits are applied only against future fees and are not paid out in cash, except where mandatory law requires otherwise.
9.6 Notwithstanding the preceding provisions on contractual penalties, the liability provisions of the Terms of Service remain applicable. To the extent the Provider is exceptionally liable for the same event both under the Terms of Service and this SLA, any service credit or contractual penalty granted under this SLA shall be offset against such liability.