Cxense Service Level Agreement (SLA)
This service level agreement (SLA) describes the levels of service that customers of Cxense ASA will receive as subscribers to our software as a service offering. This SLA should be read alongside the contract that customers have with Cxense ASA, as there may be conditions that amend or overrides this SLA in these contracts.
Table of Content
1.1. Uptime and planned downtime
1.1.1. Uptime and response time targets
1.1.3. How to receive notifications
1.2. Software support and problem escalation
1.2.3. Response, update and resolution targets
1.2.5. Priority level definitions and assignments
1.2.6. Priority level 1 and 2 incidents reporting
1. Agreements
This service level agreement (SLA) sets forth the levels of service that Customers of Cxense ASA will receive as subscribers to our software as a service offering. This SLA incorporates the terms contained in the Customer’s applicable Order Form for Cxense services. In the event of any conflict between this SLA and the Order Form, the latter shall prevail.
1.1. Uptime and planned downtime
During the term of your Services Agreement, Cxense will make its best effort to ensure that the Cxense products licensed (the Services) are available 24/7. In the following, all service level objectives are measured on the basis of a calendar month, and any reference to “percent downtime” is calculated based on the number of minutes the Services may be unavailable in a calendar month.
Upgrades or general maintenance may call for service downtime where the Services will be stopped for shorter periods of time. Cxense will keep the planned downtime to a minimum, and schedule it outside of peak hours for our customers. Planned downtime is communicated upfront. Downtime due to pre-announced maintenance activities is excluded from the measurement of “percent downtime”.
1.1.1. Uptime and response time targets
Service |
Uptime |
Response time |
Notes |
Cxense Insight - data displaying |
99.7% |
N/A – Response dependent on the submitted request |
See note on uptime calculation below |
Cxense API |
99.7% |
N/A – Response dependent on the submitted request |
See note on uptime calculation below |
Cxense DMP - segment membership lookup |
99.7% |
95% of segment membership lookups processed in less than 300 milliseconds |
|
Cxense DMP |
n/a |
95% of segments updated within 120 minutes interval |
‘Modelled’ segments that are calculated based on algorithms (e.g. look-a-like) are updated one time per 24 hours |
Cxense DMP - segment exports |
99.0% |
99% of segment changes exported within 24 hours after export is started/scheduled |
Uptime is measured as the percentage of successful exports |
Cxense Conversion Engine - user profiles and content profiles lookups |
99.7% |
95% of CCE client requests processed in less than 300 milliseconds |
See note on uptime and response time calculations below |
Cxense Content - query serving |
99.7% |
95% of content recommendation requests processed in less than 300 milliseconds |
See note on uptime and response time calculations below |
Cxense Advertising - ad serving |
99.7% |
95% ads requests processed in less than 300 milliseconds |
See note on uptime and response time calculations below |
Cxense Search - query serving |
99.7% |
95% of search requests processed in less than 300 milliseconds |
See note on uptime and response time calculations below |
Cxense Video |
99.7% |
See note on uptime calculation below |
|
Cxense Video - processing time |
|
Audio: 15 times the duration Video: 20 times the duration for the first 50GB with less than 60 minutes duration |
|
Cxense Video - hosted pages load time |
95% percentile: 2 seconds |
For uptime calculations:
Pre-announced scheduled downtime (“Planned Downtime”) or events outside of the control of Cxense is not included in the uptime calculation. Examples of events outside of the control of Cxense are: external connectivity losses, network transit failures, force majeure, etc.
For response time calculations:
The response time is calculated as the time the request spends within the Cxense servers and network. This does not include Customer’s network latency or other external network latency.
1.1.2. Planned downtime
- Planned downtime will be kept at a minimum, but can be up to 90 minutes per month in total.
- Cxense will aim to perform scheduled service upgrades during the weekend hours from 9:00 pm Pacific Standard Time (PST) Friday to 2 pm PST Sunday
- Cxense will provide at least 2 days’ notice of planned Service downtime.
- Only in very rare situations: critical processing like ad serving, user and content profiles lookups, content delivery and data collection will be affected by planned upgrades, and we will communicate this very clearly if that is the case. However, during an upgrade, the user interface may become unresponsive for a short period of time, which may affect anyone who is running reports or trying to make changes to the system.
1.1.3. How to receive notifications
Notifications about scheduled downtime, upgrade, and service interruptions will be announced on the support portal: https://support.cxense.com.
1.2. Software support and problem escalation
1.2.1. Problem detection
In the event a defect, bug, or other issue affecting the Subscription Services are detected by either Cxense or Customer, the issue will be categorized as an incident pursuant to the criteria in this Section 4. Each incident will be communicated to the defined contacts and resolved as defined in the table below.
1.2.2. Outside scope
Outside scope for incident pursuant to the criteria in the tables describing Basic and Premium support offering are the following requests:
- requests for new features,
- change in implementation/integration (professional services requests)
- operational task
- customer service
- account management
1.2.3. Response, update and resolution targets
The problem response, update and resolution times set forth in this SLA depends on the support level subscribed to. The SLA targets for Premium and Basic support offering are summarized in the two tables below.
Premium support offering
Priority Level |
Initial Response |
Update Interval |
Resolution |
Critical (Level 1) |
Within 30 minutes after Customer notifies Cxense of the problem or Cxense otherwise becomes aware of the problem |
Every 30 minutes |
|
Urgent (Level 2) |
Within 1 hour after Customer notifies Cxense of the problem or Cxense otherwise becomes aware of the problem |
Every hour |
|
High (Level 3) |
Within 4 business hours after Customer notifies Cxense of the problem or Cxense otherwise becomes aware of the problem |
Every business day |
|
Standard (Level 4) |
Within 8 business hours after Customer notifies Cxense of the problem or Cxense otherwise becomes aware of the problem |
N/A |
|
See the section named “Priority Level 1 and 2 incident reporting” for conditions necessary to benefit from Level 1 and 2 SLA targets.
Basic support offering
Priority Level |
Initial Response |
Update Interval |
Resolution |
Critical (Level 1) |
Within 60 minutes after Customer notifies Cxense of the problem or Cxense otherwise becomes aware of the problem |
Every hour |
|
Urgent (Level 2) |
Within 2 hours after Customer notifies Cxense of the problem or Cxense otherwise becomes aware of the problem |
Every 2 hours |
|
High (Level 3) |
Within 4 business hours after Customer notifies Cxense of the problem or Cxense otherwise becomes aware of the problem |
Twice a week |
|
Standard (Level 4) |
Within the end of next business day after Customer notifies Cxense of the problem |
N/A |
|
1.2.4. Definitions
For purposes of the table above, the following terms shall have the meanings set forth below:
- “Final Resolution” means a permanent fix that resolves the issue.
- “Initial Response” means the first contact provided to Customer by Cxense. This response may be in the form of an email message or, if the email is unavailable, a documented phone call, or documented personal acknowledgment, and will normally contain the service request number for tracking purposes.
- “Update Interval” means any communication from Cxense support or product team to Customer where the status and plan of action for the service request is communicated. The purpose of these updates is to keep the Customer informed of the progress being made to resolve the problem reported through the incident resolution request, to gather additional details for support or troubleshooting purposes, or to communicate a resolution of the problem.
- “Workaround” means a temporary fix that resolves the issue in all material respects.
1.2.5. Priority level definitions and assignments
Each incident will be assigned a priority level based on the Priority of the issue outlined in the criteria listed below.
Priority Level 1 (“Critical”).
A Priority Level 1 problem means any of the following:
- A complete outage of a critical service
- An outage that affects 25% or more of your users
- A recurring temporary outage of a critical service
- Inability to provision the Subscription Services
- Loss of data
- Very serious failure rendering the services, or any major function of the Subscription Services, inoperable or severely impaired
Priority Level 2 (“Urgent”)
A Priority Level 2 problem means any of the following:
- Significant degradation of the Subscription Services
- An outage that affects 10-25% of your users
- Results are materially different from those described in the product definition.
- Serious failure of the Subscription Services that causes material inconvenience to Customer and/or its users
Priority Level 3 (“High”)
A Priority Level 3 problem means any of the following:
- Minor degradation of the service
- An outage that affects 5-10% of your users
- Recent modifications to the system cause the Subscription Services to operate in a way that is materially different from what is described in the Documentation for non-essential features.
- A failure of the Subscription Services that causes material inconvenience to Customer and/or its users
Priority Level 4 (“Standard”)
A Priority Level 4 problem means any of the following:
- A small system delay, but no loss of data was experienced, or a minor application error occurred
- The Subscription Services does not operate strictly according to the documentation and/or technical requirements
- Any of the “Out of scope” requests mentioned above will be marked as Priority 4 for simplicity, but excluded from reports
1.2.6. Priority level 1 and 2 incidents reporting
To qualify as a Priority Level 1 or 2 incident, the following conditions must be met in reporting and follow up of the incident.
- Initial incident report for Priority 1 and Priority 2 incidents, must contain the word “slacritical” in the subject of the ticket logged. This will trigger an alarm to the Support Engineer on call and ensure that response objectives can be met. Customers must log new tickets and not update existing cases when requesting Priority 1 and 2.
- Customer technical contacts must remain available for Cxense engineers 24x7 for the duration of a Priority 1 or 2 incident. Cxense is entitled to reduce the priority level if incident troubleshooting and resolution depend on customer feedback, and customer no longer responds.
1.2.7. Escalation procedure
In the event of
- Incidents are not being communicated within the timeframes in the table above, or
- Incidents are not being resolved to Customer’s reasonable satisfaction, or
- Cxense is not getting a timely response from Customer in its provision of information required to resolve an incident,
then the affected party can escalate the incident in accordance with the following escalation ladder.
- the escalating party will contact the other party pursuant to the contact table below, starting with the 1st escalation.
- If no resolution is attained within 12 hours, then the incident or issue will be escalated to the 2nd escalation tier.
- If no resolution is attained within 24 hours, then the incident or issue will be escalated to the 3rd escalation tier.
1.2.7.1. Escalation table
Escalation |
Cxense |
|
Tier |
Name/Title |
Phone/e-mail |
3rd |
Christian Printzell Halvorsen, |
christian.halvorsen@cxense.com +47 992 29 546 |
2nd |
Greger Wedel, CTO |
greger.wedel@cxense.com +47 9044 5000 |
1st |
Michael Medvedev, VP Global support |
Michael.Medvedev@cxense.com +7 92 761 132 26 |
When escalating an incident, the notifying party will provide the other party’s contact with the following information:
- The particular service(s) or incident(s) that is(are) experiencing a problem;
- An email notification address or alias to facilitate communication;
- All relevant information regarding the problem, including the steps that the notifying party has taken to investigate the cause of the problem prior to notification and, if necessary, the proper notifying party contact to assist in the resolution of the problem; and
- Other pertinent contact information, which will include but not be limited to, a mobile number for the authorized representative.
Comments
0 comments
Please sign in to leave a comment.