Bizzkit Service Level Agreement
1. Definitions
- Availability -- The Uptime for a given time period (e.g. month, year) in percent.
- Bizzkit Support -- The support-team of technicians at Supplier.
- Customer -- The customer of Bizzkit Commerce Cloud, as defined in the CSA.
- Downtime-- The time where Supplier's services are unexpectedly, i.e., not announced by Supplier, unavailable.
- Help Desk -- Supplier's support system, a self-service page for creating tickets for Service.
- Operating Hours -- Hours in which Supplier's services are planned to be available, i.e., Total Time Available minus Planned Maintenance time.
- Uptime-- Hours in which Supplier's services are available, i.e., Operating Hours minus Downtime.
- Planned Maintenance-- Maintenance planned for by Supplier either within or outside of the Planned Maintenance window.
- Service -- Support, bug correction, Incident correction or any other service rendered in line with this Bizzkit SLA.
- Change -- A change to Supplier's services that is not regarded as falling under the definition of Service under this Bizzkit SLA.
- Service Credit-- Credits for Downtime of Availability which Supplier is responsible for, which is paid out as a percentual reduction of the Customer's invoice, see section 7.
- Service Hours -- Normal working hours, ie. from 8:00 AM to 4:00 PM CEST on working days.
- Total Time Available -- The total amount of hours available in the given period of time, i.e., a year being 365 days times 24 hrs.
- Operating Hours -- Bizzkit Commerce Cloud is available during the following periods: 24/7/365.
- SPOC - Single point of contact at Solution Partner.
2. Introduction
2.1. This document presents the Bizzkit SLA, where a detailed description of the service level that Supplier offers are found. SLA requirements beyond the service level described in this Bizzkit SLA can be agreed upon in the Customer Service Agreement under special terms.
3. Contact Channels & SPOC
3.1. Help Desk is the function, that trough the SPOC ensures correct processing of inquiries concerning Incident, Bizzkit Support, or Changes.
3.2. Incidents are registered and processed after the Bizzkit Incident Correction Process.
3.3. Supplier can be contacted either by email, via Help Desk or telephone.
3.4. Contact Channels
3.5.1. Email -- Customer can via the SPOC report Incident, request Service, or request a Change by writing to the Support email address:
3.5.2 Phone -- For Incident that are registered with priority 1 inside and outside normal Service Hours, in addition to submitting the Incident to the Help Desk, Customer's SPOC must call the Support telephone number:
+45 30 90 23 22
3.5.2.1 If a call outside normal Service Hours results in Supplier having to call employees to work, the time consumption for support outside of the normal Service Hours is invoiced at double the hourly rate (hourly rate can be obtained at Supplier, or is included in the CSA), in case the reported issue can be traced back to Customer's or Customer's Solution Partner's actions or lack thereof.
3.5.3 SPOC -- Customer appoints a named resource from their Solution Partner as their SPOC. The SPOC to communicate with Supplier should optimally be a person with a high level of technical knowledge and access privileges at superuser level. The SPOC is in charge of sending inquiries via phone in order to avoid basic misunderstandings when submitting requests for Service.
3.5.3.1 If the Customer does not have the option to appoint a named resource from the Solution Partner or prefers appointing a named resource from the Customer, this can be agreed upon with Supplier.
4. Availability
4.1. Operating interruptions are counted from the time within the Service Hours when Supplier himself has detected an Incident/lack of Availability or received an adequate Incident description from Customer's SPOC and lasts until Availability is restored.
4.2. The service level regarding the hosting of Supplier's services at Microsoft Azure is subject to Microsoft Azure's service level agreement and other terms of service.
4.3. Supplier seeks to attain the highest operational stability for Supplier's services. Supplier guarantees an Availability for Supplier's services of 99,95 % per month within the Operating Hours, unless downtime is caused by matters beyond Supplier's control, including but not limited to matters relating to Supplier's infrastructure and subcontractors, and for which Supplier could not or should not have taken measures into account.
4.4. Uptime is calculated as Operating Hours (i.e., Total Time Available minus Planned Maintenance time) minus Downtime, or written out as:
Uptime = ( Total Time Available - Planned Maintenance time) - Downtime
4.5. Availability is calculated by Uptime divided by Operating Hours (i.e., Total Time Available minus Planned Maintenance time), multiplied by 100, or written out as:
Availability (in %) = ( Uptime / ( Total Time Available - Planned Maintenance time) ) x 100
4.6. Availability is measured on Solution Partner's or Customer's access point on Supplier's services.
4.7. If operations cannot be maintained because of an operational obstacle for which the Customer is responsible, or external disturbances such as a Microsoft Azure Incident or Incidents by other technically critical third-party suppliers to Supplier, the time covered is not deducted from the Uptime when calculating Availability.
5. Planned Maintenance Window
5.1. Window for Planned Maintenance tasks will be Mondays at 4:00 -- 6:00 AM CEST (adjusted for summertime). Supplier shall perform maintenance on Supplier's services as necessary during the aforementioned window and shall not exceed 60 minutes in duration. Supplier shall use reasonable efforts to minimize any disruption to Supplier's services during this maintenance window. Supplier shall provide notice to the Customer and Solution Partner at least 48 hours prior to any scheduled maintenance activities that will require Supplier's services to be unavailable for more than 60 minutes during the maintenance window.
5.2. Maintenance window for unplanned or irregular maintenance tasks outside of the maintenance window will be coordinated internally and announced as soon as a Planned Maintenance window has been chosen.
5.3. Downtime due to Planned Maintenance services are excluded from section 7 of this Bizzkit SLA and will not be counted as affecting the Availability regarding Service Credits.
6. Incident Processes
6.1. Bizzkit Incident Correction Process
When Customer's SPOC reports an Incident via the Help Desk and then through dialogue with Bizzkit Support has identified and possibly attempted a first remedy of the incident, a priority is agreed and Supplier begins the remedy according to the agreements for each category.
If Supplier's specialists during the remedy find that the categorization is not correct, they will propose a changed categorization to Customer's SPOC. Customer's SPOC is immediately informed of this so that Customer's SPOC can give written consent. Depending on the category, the remedy will be planned to be included in a future version or release of Supplier's services, or a hot fix.
Process:
-
Incident is reported by Customer to Customer's SPOC
-
Solution Partner SPOC report the issue to Bizzkit Support
-
When Supplier receives Incident report, the Incident is categorized.
-
Remedy is executed.
-
Closure and forwarding closure note.
-
In the case of an Incident, Supplier must carry out remedial action in accordance with the table below, taking into account the categorization of the Incident.
6.2. Categorizing of Incidents
The following categorization will apply:
| Priority | Category | Description |
|---|---|---|
| 1 | Critical Incident | Incident that leads to irreparable conditions or result in incorrect data being supplied to a significant extent. Incident that significantly hinder the users' further work process. Incident that imposes significant financial loss on the Customer. Incident corrections that cannot be postponed. |
| 2 | Severe Incident | Incident which means that several important work processes at the Customer cannot be carried out or can only be carried out with a significant change in the work process. |
| 3 | Significant Incident | Incident that results in several work processes not being able to be carried out or can only be carried out by changes in the workflow. Workaround is implemented. |
| 4 | Normal Incident | Incident that does not prevent the work process from being carried out normally, possibly with minor changes in the work process to circumvent the error. Workaround is implemented. |
| 5 | Less significant Incident | Insignificant or cosmetic Incident, but where there is a degradation in relation to the basis of the agreement. |
When the SPOC reports an Incident via the Support channels and then through dialogue with Bizzkit Support has identified and possibly attempted a first remedy of the Incident, a priority is agreed, and Bizzkit Support begins the remedy according to the agreements for each category.
If Bizzkit Support/Specialists during the remedy find that the categorization is not correct, Bizzkit Support will propose a changed categorization to the reporter. Reporter is immediately informed of this so that Reporter can give written consent. Depending on the category, the remedy will be planned to be included in a future version or release of Supplier's services, or a hot fix.
6.3. Requirements to the remedy process
| Priority | Category | Bizzkit Incident Correction Process according to priority |
|---|---|---|
| 1 | Critical incident | Supplier will always initiate remedy. Remedy is performed uninterrupted until the Incident has been resolved. Supplier must report status to Customer's SPOC at least once a day. Customer's SPOC must in addition establish a task force that can receive the daily status and work with Supplier in the remedy process. |
| 2 | Severe Incident | The correction is initiated as soon as possible during Service Hours. Remedy is performed uninterrupted until the Incident has been resolved. If reported outside Service Hours, the correction of the Incidents will begin at the beginning of the next working day. Supplier must report status to Customer's SPOC at least once a day. Customer's SPOC must in addition establish a task force that can receive the daily status and work with Supplier in the remedy process. |
| 3 | Significant Incident | The correction is initiated as soon as possible during Service Hours. If reported outside Service Hours, the correction will earliest begin at the beginning of the next working day. Work is continued within Service Hours until a workaround, i.e., an intermediate solution to the problem, has been implemented. Supplier must report status on unresolved inquiries to Customer's SPOC at least once a week. The implementation of the Incident correction must be carried out at the latest in connection with the release of a new version of the specific service at Supplier, however, so that the maximum number of simultaneous unresolved inquiries in the reporting period is respected. |
| 4 | Normal Incident | Supplier will within Service Hours work on the remedy. The implementation of the Incident correction must be carried out at the latest in connection with the release of a new version of the specific service at Supplier, however, so that the maximum number of simultaneous unresolved inquiries in the reporting period is respected. |
| 5 | Less significant Incident | The implementation of the Incident correction must be carried out at the latest in connection with the release of a new version of the specific service at Supplier, however, so that the maximum number of simultaneous unresolved inquiries in the reporting period is respected. |
6.4. Response Time
For new inquiries, the time from submitting to receiving a digital receipt is monitored.
When an inquiry is registered, the Help Desk adds a timestamp to each case.
Minimum 3 performance indicators are monitored per specific service at Supplier.
Service objective for response time is below 100ms and defined as the time it takes for a specific service at Supplier or component to perform a task.
6.5. Response and Resolution Time Incidents
| Priority | Response time | Resolution Time |
|---|---|---|
| 1 | Within 0,5 hour | 4 hours |
| 2 | Within 2 hours | 8 hours |
| 3 | Within 8 hours | Next available release |
| 4 | Within 16 business hours | Next available release |
| 5 | Within 40 business hours | Next available release |
6.5.1 Requirements to priority 1 Incidents
Critical incidents with priority 1 must be reported to Bizzkit Support via telephone, followed by creating an incident in the Help Desk. Resolution time is measured from the successful receival of a phone call and incident report.
6.6. Response Time Other Requests
Response Time on other requests is 4 hours. This includes requests for Service and Changes.
7. Service Credits
7.1. Deduction for individual months
If the Availability is not met by Supplier, the Customer has the right to claim Service Credit from Supplier in relation to the relevant Availability. The percentage is deducted from the given months part of the annual invoice, i.e., one twelfth (written: 1/12) of the full annual invoice for the Supplier license fee, written out as follows (with an example of 20 % deduction, where X is the amount due in cases of no deduction):
Total deduction = 20 % of (1/12 of total amount on invoice) = 0,2 x (total amount on invoice / 12)
The amount of the credit depends on the impact of the Downtime on the total Availability (see table in 9.2).
7.2. Claim Percentage
| Availability | Customer’s Claim Percentage |
|---|---|
| ≥ 99,95% | 0 % |
| 99,95% - 99,0% | 10 % |
| 98,99% - 95,0% | 15 % |
| ≤ 95,0 % | 20 % |
7.3. The Customer must claim a Service Credit no later than the 15th working day of the month following the Incident that gave rise to a claim for Service Credits. If several specific services at Supplier have been affected by downtime and the Customer has claimed penalty for several Service Credits, the total reduction of the Supplier license is limited in total to 100%.
8. Monitoring
8.1. Supplier's services' individual components are monitored via Bizzkit Operations and via established user-simulated end-to-end monitoring for selected business transactions and in addition via inquiries to the Help Desk. Supplier monitors the operating environment with standard monitoring tools for monitoring Availability.
8.2. The monitoring of Availability is carried out continuously and is supplemented with random samples at least every 5 minutes during the agreed Service Hours.