Cxense Service Level Agreement - Valid from March 8th, 2017

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 amends or overrides this SLA in these contracts.

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 From 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 very 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 up front. 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 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 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 Insight

99.7%

See note on uptime calculation below

Cxense Display

- ad serving

99.8%

See note on uptime calculation below

Cxense Display

- booking server

99.5%

See note on uptime calculation below

Cxense Maxifier

- recommendations complete

90% by 9 am each business day

Cxense Video - uptime

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 Cxense1) 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 from 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 will the ad serving 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: http://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.

1.2.3.1 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

· Reasonable Workaround within 1 hour

· Final Resolution within 8 hours

Urgent (Level 2)

Within 1 hour after Customer notifies Cxense of the problem or Cxense 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 Cxense of the problem or Cxense 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 Cxense of the problem or Cxense otherwise becomes aware of the problem

N/A

· Proposed plan for Workaround within 5 business days

· Final Resolution when deemed feasible by Cxense

See section named “Priority Level 1 and 2 incident reporting” for conditions necessary to benefit from Level 1 and 2 SLA targets.

1.2.3.2 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

· Reasonable Workaround within 3 hour

· Final Resolution within 24 hours

Urgent (Level 2)

Within 2 hours after Customer notifies Cxense of the problem or Cxense 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 Cxense of the problem or Cxense otherwise becomes aware of the problem

Twice a week

· Reasonable Workaround within 3 business day

· Final Resolution within 5 business days

Standard (Level 4)

Within end of next business day after Customer notifies Cxense of the problem

N/A

· Proposed plan for Workaround within 10 business days

· Final Resolution when deemed feasible by Cxense

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 email is unavailable, a documented phone call, or documented personal acknowledgement, 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 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.

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:

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

A 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.5 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 to 4 if incident troubleshooting and resolution depends on customer feedback, and Customer no longer responds.

1.2.6 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 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

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.

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.