Service Level Agreement
This Service Level Agreement (“SLA”) forms part of the Terms of Service between Customer and Apcurium Group, Inc. dba Dispatch Science (“Agreement”). Apcurium Group, Inc. dba Dispatch Science shall hereinafter be referred to as “Dispatch Science.”
This SLA describes the levels of Services availability and support that Customer can expect to receive from Dispatch Science for the duration of the Agreement for their production-use tenant.
As used in this SLA, the following terms shall have the meanings specified below. Any capitalized terms not defined herein shall have the meaning attributed to them in the Agreement. In this SLA the singular includes the plural and vice versa; the words “month”, “year”, and “quarter” mean calendar month, calendar year, and calendar quarter, unless otherwise stated; and the word “including” (or any analogous word or phrase) means “including without limitation”.
|Business Day:||08:30 to 18:00, local time for the contracting Dispatch Science entity, not including Saturday, Sunday or public holidays.|
|Degraded Performance:||a lower quality of service as described in this SLA (e.g. temporarily broken or temporarily unavailable functionality).|
|Downtime:||the period of time during which the Services are wholly unavailable to Customer, including maintenance occurring outside of Maintenance Hours for which less than 24 hours’ notice was provided to affected Customers. However, Downtime shall not include:
|Knowledge Base:||Dispatch Science help portal located on the Dispatch Science website (support.dispatchscience.com) that publishes information on how to perform tasks in the Services and responds to frequently asked questions.|
|Maintenance Hours:||Dispatch Science may perform maintenance on Tuesdays and Thursdays. The maintenance timeframes will be 2:00 am EST to 5:00 am EST for each day. Minor non-disruptive updates may be performed anytime.|
|Resolution Time:||the time that elapses from the Response Time until the Ticket is resolved.|
|Response Time:||measures the time that elapses during the Business Day between the receiving of a Ticket and the time of responding to the customer that the Ticket has been received and Dispatch Science commences work on the issue.|
|Scheduled Maintenance:||planned outages, either suspending service in full or in part, which Dispatch Science will endeavor to announce at least 5 days in advance, and in any case will announce no later than 24 hours in advance, which will not exceed a reasonable period of time for the maintenance required and which, where possible, shall take place during Maintenance Hours.|
|SLA Effective Date:||the date Services commence as further provided for in the Agreement or applicable Statement of Work and the date this SLA enters into force.|
|Ticket:||an electronic request sent to Dispatch Science by Customer (e.g. requesting a solution to an incident).|
|Uptime:||as calculated in accordance with this SLA.|
Scope of the Service Level Agreement
This SLA applies only to the Services described in the Agreement or applicable Statement of Work. This SLA does not apply to any software, equipment, services, or other parts of an information technology system that are not purchased from or managed by Dispatch Science.
Dispatch Science will rectify material issues with the Services, except where:
- the issue has been caused by Customer’s use of the Services in a manner that is contrary to Dispatch Science Training, Knowledge Base, or any other instruction issued by Dispatch Science;
- Customer has made unauthorized changes to the configuration or set-up of the affected Services;
- Customer has prevented Dispatch Science from performing maintenance on the Services;
- the issue has been caused by Third-Party Services; or
- the issue has been caused by User(s), including by modifying part of the software or by adding, deleting, or assigning improper rights to Users.
SLA Effective Date and Term
This SLA will be effective from the Project Start Date and will terminate without further notice and without right to compensation or restitution upon the expiry or termination of the Agreement or applicable Statement of Work.
Dispatch Science’s responsibilities:
- ensure the relevant Services are available to Customer in accordance with the Uptime guarantee;
- respond to support requests within the timescales listed below;
- take steps to escalate, diagnose, and resolve issues in an appropriate and timely manner, including the allocation of a sufficient number of skilled staff and the collection of necessary information; and
- maintain clear and timely communication with Customer at all times.
- use the Services as intended under the Agreement;
- notify Dispatch Science of issues or problems in a timely manner and as thoroughly as is possible through its ticketing system which will be made available to Customer;
- cooperate with Dispatch Science in its efforts to escalate, diagnose, and resolve issues by providing timely and accurate responses to requests for information;
- in case of a Severity 1 Ticket, ensure the availability of a sufficient number of skilled Customer employees to cooperate with Dispatch Science;
- provide Dispatch Science with access to equipment, software, and services for the purposes of maintenance, updates, and fault prevention; and
- maintain staff with adequate information technology knowledge to fulfil these responsibilities.
Dispatch Science guarantees 99.5% Uptime each month 24 hours a day 7 days a week (“Agreed Hours of Service”). Uptime is measured based on the monthly average of availability, rounded down to the nearest minute, and calculated as follows:
Uptime % =
Agreed Hours of Service – hours of Downtime
Agreed Hours of Service
Should Uptime fall below 99.5% in any month, Dispatch Science will pay liquidated damages in the form of a Service Credit, which is calculated as follows:
Uptime < 99.0% 50% of monthly subscription fee Uptime ≥ 98.0% and less than 99.0% 25% of monthly subscription fee Uptime ≥ 99.5% 0% of monthly subscription fee
To apply for a Service Credit under this SLA, Customer must submit a request to email@example.com, within 30 days of the end of the applicable month with the subject line “SLA Service Credit”. The request must include the dates and times of the Downtime for which Service Credit is being requested, and any additional documentation that demonstrates the claimed Downtime.
Service Credits are the exclusive remedy for Dispatch Science’s failure to meet its Uptime guarantee and no other or additional types of damages can be claimed, including breach of warranty, in accordance with the limitations of liabilities and other limitations in the Agreement. In the event there are no new invoices to be issued, Dispatch Science will pay out the Service Credit to Customer directly. Dispatch Science will only provide a Service Credit if Customer’s account is up to date and in good standing (including but not limited to Customer being current on all subscription fees and payments due and payable to Dispatch Science as required by the Agreement or Statement of Work) at the time of the Service Credit request.
Support Services, Response Time and Resolution Time
In the event of a Ticket, Dispatch Science is deemed to have responded when it has replied to Customer’s initial request. This may be in the form of an email or telephone call, to acknowledge receipt of Customer’s request, provide a solution, or request further information.
The level of support service, Response Time and Resolution Time will depend on the priority of the item(s) affected and the severity of the Ticket, as set out in the following definitions and schedules:
The following characteristics are used to identify the severity of a Ticket:
Business and financial exposure
Number of clients/users affected
Acceptable resolution time
It is not necessary (nor is it likely) to have perfect match of each characteristic to categorize a Ticket at a particular severity level. A given problem must be judged against each of the characteristics to make an overall assessment of which severity level best describes the problem. Dispatch Science shall assign a severity level to each Ticket in its reasonable discretion.
The characteristics below do not cover work requests. Severity levels for work requests may carry a different set of characteristics and weightings. Work requests are not covered as part of this SLA and are subject to a separate Statement of Work.
Severity 1 (Critical)
Severity 2 (High)
Severity 3 (Medium)
Severity 4 (Low)
|Business and financial exposure|
|The application failure creates a serious business and financial exposure.||The application failure creates a serious business and financial exposure.||The application failure creates a low business and financial exposure.||The application failure creates a minimal business and financial exposure.|
|The application failure causes the client or user to be unable to work or perform a significant portion of their intended use.||The application failure causes the client or user to be unable to work or perform some significant portion of their intended use.||The application failure causes the client or user to be unable to perform some small portion of their intended use, but they are still able to complete most other tasks.||The application failure causes the client or user to be unable to perform a minor portion of their intended use, but they are still able to complete most other tasks. May also include questions and requests for information.|
|Number of Clients Affected|
|The application failure affects all clients or users.||The application failure affects a large number of clients or users.||The application failure affects a small number of clients or users.||The application failure may only affect one or two clients or users.|
|Workaround [This bullet carries the heaviest weighting of the characteristics for Severity 1 and 2.]|
|There is no acceptable workaround to the problem (i.e., the intended use cannot be achieved in any other way).||There is an acceptable and implemented workaround to the problem (i.e., the intended use can be achieved in some other way).||There may or may not be an acceptable workaround to the problem.||There is likely an acceptable workaround to the problem.|
|Within one hour of receipt during Business Day||Within four hours.||Within eight hours or by next Business Day (EST).||Within eight hours or by next Business Day (EST).|
|The maximum acceptable resolution time is 24 continuous hours, after initial response time.||The maximum acceptable resolution time is five Business Days.||The maximum acceptable resolution time is 30 Business Days.||The anticipated resolution time is 120 calendar days.|
Dispatch Science’s Storage & Infrastructure
Dispatch Science uses Microsoft Azure (Azure) to provide its Services via a cloud-based storage application and Azure offers the possibility to store a virtually unlimited amount of data with a guaranteed data durability of 99.999999999%.
Dispatch Science offers Customer the option to host Customer Data in Microsoft datacenters located in the United States, Canada, United Kingdom or Australia. Customer will be required to select its data hosting location in the applicable Statement of Work and any change to the data hosting location after Customer’s initial selection of location shall only be done for a fee at Dispatch Science’s then-current rates. Any questions or requests regarding the data hosting location or costs to change said location should be addressed by sending an email to firstname.lastname@example.org.
Dispatch Science Support regularly analyses all Customer Tickets in order to identify trends and bottle necks. Based on these findings, Support updates the Knowledge Base with information explaining the solution to “known errors”.
In order to respond to FAQs and help Customers to resolve common problems without needing direct assistance from Support, Dispatch Science maintains the Knowledge Base on the Dispatch Science website (support.dispatchscience.com). Dispatch Science Support has defined four general types of FAQs:
- Technical issues are related to a particular bug, security or backup failures, or any other type of non-functioning of the Services.
- User questions arise from instances when the system fails to be self-explanatory. Dispatch Science works hard to prevent these questions and reduce them to an absolute minimum.
- Requests are requests to change the Services, features or settings.
- Content questions are related to the contents of Customer Data itself. Customer is the creator and controller of its Customer Data, and is therefore tasked with providing User support for these questions.
If your question is not resolved via the Knowledge Base, the Dispatch Science help desk can be contacted by email anytime via email@example.com, or by telephone during applicable office hours of 9:00 am to 6:00 pm Eastern Standard time at 1-844-558-2011.
By using Microsoft Azure, Dispatch Science’s Services come with many reliability, security and scalability certifications such as AES-256 encryption, ISO 27001, HIPAA, FedRAMP, SOC 1, SOC 2 and others.
The Dispatch Science team secures backups of all data and code in the following manner:
- Incremental backups of all uploaded media on multiple back-up servers (daily).
- Full backups of the database (hourly, retention of 7 days).
- Backups of the file database (monthly, on separate Azure servers).
In the (unlikely) event of damage or outage at Dispatch Science’s Azure locations, Dispatch Science will restore Customer’s data from the most recent backup. This will be treated as a Severity 1 Ticket.
At Customer’s request, a backup or a part of a backup can be restored within 48 hours for a fee negotiated in the Agreement or charged on a time and material basis.
Dispatch Science releases the Services via Continuous Integration and Continuous Delivery. This means that whenever a new feature or release of Dispatch Science is ready, it can be deployed to the production clusters at any moment. The main application, and any improvements or updates thereto, is typically released once every two weeks. All perimeter applications are deployed to production continuously when a build is succeeded on the continuous integration servers.
Urgent bug fixes that impact availability and critical features are applied immediately on production servers in accordance with the Resolution Time schedule.
Third party components in use by Dispatch Science (e.g. Microsoft Azure, Here mapping service, Open Street Map, etc.) are updated automatically every night (in the local time zone), whenever critical updates become available.
Dispatch Science will make available to Customer new versions, releases, and updates to the Services to solve defects and/or errors, keep the Services up-to-date with market developments, or otherwise improve the operation or functionality of the Services. These improvements may include bug fixes. Dispatch Science will only support the most recent version of the Services.
New versions, releases, or updates will contain at least the level of functionality as set out in this SLA and as contained in the version or release of the Services previously used by Customer and will not otherwise negatively impact Customer’s use of the Services. Dispatch Science shall make reasonable efforts to ensure that when performing such actions, the impact on Customer and its User(s) is limited.
Updates to the SLA
This SLA may be updated at Dispatch Science’s discretion, but only after providing thirty (30) days’ notice, after which it shall be effective (“SLA Effective Date”). Such notice will be sufficient if provided to a User designated as an administrator of Customer’s Services account either: (a) as a note on the screen presented immediately after completion of the log-in authentication credentials at the log in screen, or (b) by email with read receipt to the email address provided for the administrator(s) for Customer’s account.
If Customer objects to any such changes, Customer’s sole recourse shall be to terminate the Agreement. Continued use of the Services following the SLA Effective Date of any update shall indicate Customer’s acknowledgement of such update and agreement to be bound by the updated SLA. When Dispatch Science changes this SLA, the “Updated” date below will be changed to reflect the publication date of the most recent version.
Updated: 26 April 2019