Vimmelskaftet 41A, 1 Sal.
VAT No.: 36561009
Last updated: April 3 2018
1. Prerequisites for service-level agreement
The terms described in this service-level agreement only applies for the Dixa Enterprise subscription plans and contracts.
2. Severity levels
Severity is defined as the impact an issue has on the Customer’s ability to conduct business. Restoration targets are based on the Severity level assigned to an incident by Dixa Support.
Priority is defined as the Customer designated level of importance and is used as a weighting factor when defining the Severity Level of an incident.
Dixa Support prioritize issues based on the Severity level.
|1 – Critical Impact (Code Red)||The customer is experiencing a severe problem resulting in an inability to perform a critical business function. There is no workaround.|
|2 – High Impact||The customer is able to perform job functions but performance is degraded or severely limited.|
|3 – Medium Impact||The Customer’s ability to perform job functions is largely unaffected, but noncritical functions or procedures are unusable or hard to use. A workaround is available.|
|4 – Low Impact||Dixa is available and operational; trivial impact to Customer’s business operations or Customer requires information or assistance on the Dixa Service capabilities or configuration.|
The characteristics set forth in the above table are used to identify the criteria for the severity of a Customer’s case. The assigned severity level for an issue may be mutually re-determined by both Dixa and the Customer during the issue resolution process, but Dixa shall have the final authority as to the actual Severity designation.
3. Target initial response times
All target initial response times apply to business hours Monday through Friday, 8:00am to 5:00pm customer local time. Severity 1 or Critical impacting incidents are supported and responded to 24x7x365.
Note: Reproducible errors that cannot be resolved promptly are escalated for further investigation and analysis.
|Issue severity||Standard initial response time|
|1 – Critical Impact (Code Red)||Severe impact or degradation to the Customer’s business operations caused by intermittent disruption of Dixa Service. Response Target: 5 min. (phone and chat)|
|2 – High Impact||Dixa Service is available and operational; moderate impact to the Customer’s business operations. Response Target: 1 business hour (web*)|
|3 – Medium Impact||Dixa Service is available and operational; nominal adverse impact to the Customer’s business operations. Response Target: 2 business hours (web*)|
|4 – Low Impact||Dixa Service is available and operational; no impact to the Customer’s business operations or the Customer requires information or assistance on the Dixa Service capabilities or configuration. Response Target: 1 business day (web*)|
4. Time to Restore and Time to Resolve
The objective of Dixa Support is to restore functionality as quickly as possible. For non-platform issues, the time to restore timer starts when the customer engages Dixa Support.
Time to restore is the amount of time a Customer is impacted before functionality is restored.
Time to resolve is the amount of time it takes to resolve the root cause of an issue.
Time to restore targets are based on Severity.
5. Target restoration times
Dixa Support and Engineering aim to reach restoration of your issue within the following target restoration times, but does not offer any guarantee on restoration times.
|Issue severity||Restoration target|
|1 – Critical Impact (Code Red)||4 hours|
|2 – High Impact||1 business day|
|3 – Medium Impact||3 business days|
|4 – Low Impact||7 business days|
6. SLAs and credits
We will make the Dixa Service available 24 hours a day, 7 days a week, and use commercially reasonable best efforts to provide 100% uptime, except for the following “Uptime Exclusions”: (i) occasional planned downtime at non-peak hours (for which we will provide advance notice); or (ii) any unavailability caused by circumstances beyond our reasonable control, including failure or delay of your Internet connection, misconfiguration by you or any third party acting on your behalf, issues on your network, major country or regional wide outages in network, connectivity or telecommunications infrastructure provided by major service and telecom providers, or telecommunications services contracted directly by you.
However, if our service uptime falls below the following thresholds in any one month billing cycle (not including any Uptime Exclusions), you may request a credit within thirty (30) days after the month in which the uptime fell below threshold. Please contact your Customer Success Manager to request credit. Upon Customer’s valid request, we will provide upon customer request the stated credit against the following month’s invoice. For annual term contracts, we will provide the applicable cash refund as a credit to the pre-paid balance or a cash refund, at the customer’s discretion.
|Uptime %||Credit %|
Dixa Technical Support must be able to reproduce errors in order to resolve them. The customer is expected to cooperate and work closely with Dixa to reproduce errors, including conducting diagnostic or troubleshooting activities as requested and appropriate. Also, subject to the customer’s approval on a support cooperation via email, chat and phone basis, and users may be asked to provide remote access to their Dixa application and/or desktop system for troubleshooting purposes.
7.1. Support channels
All support inquiries on the Enterprise subscription plan can be initiated via phone, in-app chat (in the Dixa Agent Interface) and email plus web support at the Dixa Helpcenter support.dixa.help/en
8. Dixa platform high-availability
The Dixa Platform is hosted on a highly-available Kubernetes cluster which is composed of nodes running in AutoScaling groups on Amazon Web Services (AWS EC2). The cluster is distributed across three availability zones (datacentres) inside the same AWS region (EU), which makes the platform tolerant to scenarios where up to two availability zones are unavailable.
Availability zones are located about 30 km from one another, and have isolated and redundant power distribution and network connectivity. This deployment pattern ensures failure tolerance even in the unlikely event of fires and floods.
Our databases also use highly-available deployments. Every service the platform relies on is always available in at least two availability zones.
We also ensure to be always overprovisioned in terms of node count in the Kubernetes cluster. In addition, our database layer is based on DynamoDB, which provides dynamic auto-scaling for each individual table.
8.2. Content delivery
The public-facing components of the Dixa platform are served by a global Content Delivery Network (116 Points of Presence in 56 cities across 24 countries).
This network is used both by the Agent Interface and the Chat Widget. This CDN ensures that there is no single point of failure for end-users and agents when loading Dixa assets.
In addition, the CDN enables us to have extremely good load times for your end-users, regardless of their geographical location.
The Dixa platform uses a number of global telephony carriers and service providers. All of our partners are present in a vast number of countries, enabling Dixa to offer its service across most of the world.
In the unlikely event that one of our partners encounters an incident, we have the ability to route your outbound voice traffic to another carrier. Furthermore, our enterprise carrier is able to re-route your inbound traffic directly to an emergency phone number of your choosing in case the Dixa platform would become unavailable. This is a manual backup solution that can be activated within minutes.
8.4 The current status
The current status of the platform and the Dixa Service and overview of planned maintenance and incidents is at all times available here http://status.dixa.io, and you are able to subscribe to status updates via email and sms.
9. Additional Guarantees
Any additional guarantees related to the Dixa platform and services may be found in the Terms and Conditions