Service level agreement
AI Services
Except as modified by this SLA, the terms of the Agreement govern the Service.
1. DEFINITIONS
Unless otherwise defined herein, all capitalized terms shall have the meanings set forth in the agreement.
“Day” means each day, not including the day of the act, event, or default from which a designated period of time begins to run but including the last day of the period unless it is a Saturday, Sunday, or US Federal holiday, in which case the period runs until the end of the next day that is not a Saturday, Sunday, or US Federal holiday.
“Ecosystem” shall mean any and all hardware, software, or processes under the management or control of Customer or its third party vendors, which impact or are impacted by the performance of the Service.
“Error” means any reproducible problem, defect, malfunction or deficiency within ASAPP’s Span of Control that causes the Service to not function in accordance with this SLA.
“Incident” means an Error or series of related Errors that impacts the Service Availability of the Service or causes the Service to fail to operate in accordance with this SLA. Incidents do not include Scheduled Downtime.
“Service Availability” means the periods of time that the Service is available for use by the Customer, excluding Scheduled Down Time.
“Service” shall mean the proprietary subscription-based software as a service offering as specified in the specifications set out in the Agreement and/or applicable Order. The term “Service” for purposes of this SLA does not include configuration tools, reporting, or analytic applications.
“Span of Control” means the areas of functionality that are under the direct control of ASAPP including functionality that is provided by external vendors or suppliers with whom ASAPP has a contractual relationship; provided that Span of Control does not include (i) firewalls, telephony systems, computer telephony integration, session border controller, data feeds, any provision of the Service that is dependent on facilities, networks, connectivity, or (ii) any acts or omissions of the Customer, or (iii) any acts or omissions of other wireless carriers, governmental entities, or other third parties over whom ASAPP has no control or right of control, or (iv) any Incidents involving content provided by vendors or suppliers of Customer.
“Scheduled Down Time” means the planned activities that impact, or in ASAPP’s reasonable judgment, that pose significant risk of impacting Service Availability or performance. Any down time impacting Service Availability outside of a Scheduled Down Time window will be calculated against the Service Availability calculations as described in Section 2 in this SLA.
“Update” means a release of the SDK or Service that contains error corrections and/or minor functional enhancements.
“Upgrade” means a new version of the Service or SDK, as applicable, that contains substantial functional enhancements.
2. AVAILABILITY STANDARDS
2.1 Service Availability. In accordance with the terms of the Agreement, the ASAPP agrees to comply with the availability standards set forth in the chart below and as further described in this service level agreement.
ASAPP shall not be responsible for any failure in the Service to the extent that this failure is caused by (a) issues outside of ASAPP Span of Control, including, without limitation, denial of service or similar attacks, mail bombs, DNS resolution, domain name expiration, hardware failure, Internet availability, Customer’s portion of the network, IP transit provider issues, SYN attacks or any other Force Majeure Event; or (b) any loss of Service related to periods of time where Customer premises equipment is being replaced or repaired; or (c) Customer’s failure to comply with obligations attributed to Customer in the Agreement, or (d) Customer’s failure to implement ASAPP’s reasonable written recommendations regarding issues that affect redundancy, capacity or quality of the Service, or (e) any failure of or material change to the Customer’s information technology or telecommunications infrastructure.
2.2 Service Availability Metrics. Service Availability is calculated over a calendar month. The primary measurement of the availability of the Service will be calculated using the following formula:
(total minutes in the month) – (minutes not available due to unplanned outages within ASAPP’s Span of Control) / total minutes in the month)
Example:
Month = June
Minutes in June = 43,200
Minutes not available (as outlined above) = 40 minutes
43,200 – 40 = 43,16043,160 / 43,200 = 99.91%
2.3 Redundancy. ASAPP shall ensure that all systems hosted by ASAPP are sufficiently redundant and/or backed up as frequently as may be required to provide a useful means of restoring the Service to a full working state promptly.
2.4 Error Classification & Response Time. The following Error Classification Table definitions are used for classifying Errors. Response times commence upon the earlier of ASAPP becoming aware of the issue or Customer reporting of the issue to ASAPP.
2.5 Notification System. The Customer will notify ASAPP-specified support personnel of any issues. To initiate the notification, the Customer must contact ASAPP in accordance with the procedure set out in the Incident Management Handbook (provided by ASAPP). If it is determined that ASAPP's product may be the cause and it is within ASAPP’s Span of Control, then ASAPP will begin its ticketing process and a reference number will be attached to the ticket (the “Start Time”). Initially, the ASAPP-Customer dialogue will take place via phone or email. Based on a mutual agreement regarding the impact of the reported Error, the severity level will be assigned and the SLA from Section 2.4 will be followed. The ticket will also be updated accordingly. When a satisfactory resolution has been reached, the ticket will be closed. The times set forth in the above chart commence upon the Start Time.
2.6 Assumptions and Dependencies. ASAPP’s ability to perform the services under this SLA is conditional on Customer cooperating with ASAPP and providing ASAPP personnel with reasonable access to individuals, data, systems, and Ecosystem partners as necessary to perform the services. ASAPP is not responsible for the performance of Customer’s third-party vendors, nor for the actions or inactions of such third parties. Customer agrees to cooperate and ensure the participation of relevant contributors as follows:
- Customer will assist with troubleshooting as necessary, including, without limitation:
- providing VPN access
- verifying connectivity between datacenters
- verifying connectivity between datacenters, a necessary to reproduce Errors - Customer will provide test accounts and other supporting material as necessary to reproduce Errors
- Customer will facilitate interaction with other partners or clients of Customer in the event those partners or clients impact, or are impacted by, the performance of the Services, including:
- Opening a bridge call with all members of the Ecosystem, as reasonably necessary.
- Making back-end systems of Ecosystem partners available for testing by ASAPP.
- Ensuring that ASAPP receives maintenance notifications at least 5 Days prior to any maintenance performed by Customer’s internal IT, Customer’s Ecosystem partners, or any other party reasonably expected to impact the performance of the Services, along with the anticipated effect on the Service.
- Sharing with ASAPP any alerts generated by any hardware and/or software which interacts with the Services. - Customer has the ability to release ASAPP from the requirements of this SLA, at the Customer’s discretion.
3. SCHEDULED DOWN TIME
3.1 Scheduled Down Time. Scheduled Down Time windows are used to perform system maintenance that will (or are very likely to) impact User access to the Services. Activities within Scheduled Downtime windows may include but are not limited to:
- Upgrade of servers and other systems to the latest versions of software to resolve critical emergency issues
- Update of shared infrastructure components to resolve critical events
3.2 Notice. Scheduled Down Time requests will be made with at least 2 Days notice prior to the planned Down Time window. Scheduled Down Time windows shall occur within the hours of 12AM and 6AM ET. If ASAPP needs a Scheduled Down Time window that exceeds 6 hours, it may be extended provided ASAPP provides prior notice to Customer.
3.3 Third Party Software. ASAPP will be responsible for obtaining support for any third party products included in the Services. Such third party support will be sufficient to aid ASAPP in meeting the service levels set forth in this Schedule.
3.4. Planned Updates. ASAPP may develop and provide Planned Updates in its sole discretion. Planned Updates do not impact Service Availability. As used herein, “Planned Update” means a deployment of program code introducing a new version, update, enhancement, feature, or functionality of the Service.
4. REPORTING
During the term of this Agreement, ASAPP will, upon Customer’s written request, provide (a) monthly reports to Customer reporting ASAPP’s Service Availability and (b) root cause analysis reports within 7 Days and final reports within 30 Days after an Incident.
5. ESCALATION
All Errors with a Severity Level of 1 or 2 will be escalated if a solution or plan of resolution cannot be achieved within the designated amount of time as described herein. ASAPP escalation levels and contact information is as set forth below. As succeeding levels of ASAPP's management become involved in the resolution process, Customer will provide contacts at proper levels within its organization to consult in resolving the Error. Contacts may be updated effective upon written notice.
6. SERVICE CREDITS
6.1 Service Credits. If ASAPP fails to meet the Service Availability provided herein, ASAPP will credit the Customer an amount equal to the percentage of the total monthly fee applicable to the month in which the service-level failure occurred corresponding to the Service Availability level set forth in the chart below (“Service Credit”):
6.2 Service Credit Process. To initiate a claim for Service Credit, the Customer must contact ASAPP. The Service Credit request shall provide: (a) Customer's name and contact information; (b) the date and begin/end time of the claimed outage(s); and (c) a brief description of the characteristics of the claimed outage(s). The Customer will be notified within fourteen (14) Days of the request of the resolution of the request. If rejected, the notification will specify the basis for rejection. If approved, ASAPP will issue a Service Credit on the Customer’s next invoice. If Customer has a good faith basis for disagreeing with a rejection of a Service Credit, Customer shall follow the “Service Credit Appeals Process” set forth below.
6.3 Service Credit Appeals Process. Customer shall have the right to appeal the denial of any Service Credit and may withhold payments to ASAPP that Customer reasonably approximates to be of the same value as the disputed claim. Customer will notify ASAPP in writing within 30 Days of such denial by ASAPP of any such disputed Service Credit for which Customer is withholding payment and describe, in reasonable detail, the reason for such withholding. Customer and ASAPP will diligently pursue an expedited resolution of such dispute. ASAPP will continue to provide the Services to the Customer during such time.
6.4 Sole Remedy. The provisions of this Section 6 states the Customer’s exclusive remedy in the event that ASAPP fails to meet the service levels set forth in this Service Level Agreement.