Cxense Service Level Agreement (SLA) 

This service level agreement (SLA) describes the levels of service that customers will receive as subscribers to our software as a service offering.
This SLA describes the service offering only for the following products (ex-cxense products): Insight, DMP, CCE, Content, Search, Advertising, Video. 
This SLA should be read alongside the contract that customers have with the Provider (Piano or Cxense ASA organizations), as there may be conditions that amend or overrides this SLA in these contracts.

 

Table of Content

1. Agreements

1.1. Uptime and planned downtime

1.1.1. Uptime and response time targets

1.1.2. Planned downtime

1.1.3. How to receive notifications

1.2. Software support and problem escalation

1.2.1. Problem detection

1.2.2. Outside scope

1.2.3. Response, update and resolution targets

1.2.4. Definitions

1.2.5. Priority level definitions and assignments

1.2.6. Priority level 1 and 2 incidents reporting

1.2.7. Escalation procedure

 

1. Agreements

This service level agreement (SLA) sets forth the levels of service that Customers 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 the mentioned Piano (ex-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, Provider will make its best effort to ensure that the  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. Provider 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
Insight - data displaying	99.7%	N/A – Response dependent on the submitted request	See note on uptime calculation below
API	99.7%	N/A – Response dependent on the submitted request	See note on uptime calculation below
DMP - segment membership lookup	99.7%	95% of segment membership lookups processed in less than 300 milliseconds
DMP - segment update	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
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
CCE - 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
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
Advertising - ad serving	99.7%	95% ads requests processed in less than 300 milliseconds	See note on uptime and response time calculations below
Search  - query serving	99.7%	95% of search requests processed in less than 300 milliseconds	See note on uptime and response time calculations below
Video - uptime	99.7%		See note on uptime calculation below
Video  - processing time		Audio: 15 times the duration Video: 20 times the duration for the first 50GB with less than 60 minutes duration
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 Provider is not included in the uptime calculation. Examples of events outside of the control of Provider 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 Provider 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.
• Provider 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
• Provider 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.piano.io/

 

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 Provider 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:

1. requests for new features, 
2. change in implementation/integration (professional services requests)
3. operational task
4. customer service
5. 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 Provider of the problem or Cxense otherwise becomes aware of the problem	Every 30 minutes	Reasonable Workaround within 1 hour Final Resolution within 8 hours
Urgent (Level 2)	Within 1 hour after Customer notifies Provider of the problem or Provider otherwise becomes aware of the problem	Every hour	Reasonable Workaround within 3 hours Final Resolution within 16 hours
High (Level 3)	Within 4 business hours after Customer notifies Provider of the problem or Provider otherwise becomes aware of the problem	Every business day	Reasonable Workaround within 1 business day Final Resolution within 3 business days
Standard (Level 4)	Within 8 business hours after Customer notifies Provider of the problem or Provider otherwise becomes aware of the problem	N/A	A proposed plan for Workaround within 5 business days Final Resolution when deemed feasible by Provider

 

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 Provider of the problem or Provider otherwise becomes aware of the problem	Every hour	Reasonable Workaround within 3 hour Final Resolution within 24 hours
Urgent (Level 2)	Within 2 hours after Customer notifies Provider of the problem or Provider otherwise becomes aware of the problem	Every 2 hours	Reasonable Workaround within 8 hours Final Resolution within 48 hours
High (Level 3)	Within 4 business hours after Customer notifies Provider of the problem or Provider otherwise becomes aware of the problem	Twice a week	Reasonable Workaround within 3 business days Final Resolution within 5 business days
Standard (Level 4)	Within the end of next business day after Customer notifies Provider of the problem	N/A	Proposed plan for Workaround within 10 business days Final Resolution when deemed feasible by Provider

 

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 Provider engineers 24x7 for the duration of a Priority 1 or 2 incident. Provider 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 

1. Incidents are not being communicated within the timeframes in the table above, or 
2. Incidents are not being resolved to Customer’s reasonable satisfaction, or 
3. Provider 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 to the Account Manager who is managing the Customer.

When escalating an incident, the notifying party will provide the other party’s contact with the following information:

1. The particular service(s) or incident(s) that is(are) experiencing a problem;
2. An email notification address or alias to facilitate communication; 
3. 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
4. Other pertinent contact information, which will include but not be limited to, a mobile number for the authorized representative.