Service Level Agreement

1. Definitions.

1.1 In this SLA, capitalised words and expressions shall have the meanings given to them in the Master Subscription Agreement unless otherwise specified or the context otherwise requires, and the following additional definitions shall apply:

API” means the Application Programming Interface used to communicate with the JRNI platform and programmatically interact with the data and booking activities provided.

Downtime” exists when Customer is unable to transmit and/or receive data from the Booking Service. Downtime does not include the effects of any internet, Customer network or other connectivity issues not within JRNI’s control, or the effects of any configuration changes implemented by Customer, or any unavailability due to your breach of this Agreement. Downtime is measured from (a) the time the JRNI monitoring system indicates that the Booking Service is not functioning as defined herein until (b) restoration of the Booking Service.

Edge Version” is a minor product release including the latest new features, enhancements, bug fixes and performance upgrades.

Emergency Maintenance” is maintenance which may delay or interrupt Customer’s use of the Booking Service and that is critical and cannot be delayed.

Error” means any defect, bug or error in the Booking Service that prevents: (a) the Booking Service from operating in accordance with the relevant Documentation; (b) access to the Customer Data; or (c) the Booking Service from being provided in accordance with this Service Level Agreement. Errors do not include features or functionality that may be expected by Customer, but which is not currently included in the Booking Service and/or APIs.

Long Term Support (LTS) Version” is a major release including the latest new features, enhancements, bug fixes, performance upgrades and the roll-up of all the minor Edge Version releases.

Multi-Tenant Environment” means a server, or collection of servers and network devices, either physical or virtual, which are used for the delivery of the Booking Service and are shared between multiple customers.

Penetration Test” means an authorised simulated attack on the Booking Service intended to discover security weaknesses or other vulnerabilities that could be exploited by a nefarious actor.

Priority Level” means the priority that JRNI gives to correcting a particular Error, where P1 is the highest priority of Error and P4 is the lowest.

Production Environment” means the servers, databases, software and supporting infrastructure that are being used to operate the live Booking Service for the Customer.

Response Time” means the amount of time taken for JRNI to contact the Customer after an Error has occurred. Before the Customer is contacted JRNI will evaluate the Error, determine the Priority Level, and determine a course of action for the remediation of the Error. Response Time is measured from (a) the time when the relevant Ticket is raised until (b) the time that JRNI contacts the Customer.

Scheduled Maintenance” is maintenance which may delay or interrupt Customer’s use of the Booking Service and is conducted between the hours of 12:00 midnight and 5:00am (in Customer’s local time zone) and any other maintenance for which JRNI gives you no less than 72 hours’ notice.

Service Credits” are credits given to customers if JRNI fails to achieve the guaranteed Service Levels. The method of calculating Service Credits is set out below.

Service Level” has the meaning given to it in paragraph 2 below.

Service Level Failure” means a failure by JRNI to achieve the Service Level.

Single-Tenant Environment” means a server, or collection of servers and network devices, either physical or virtual, which are used for the delivery of the Booking Service for the sole use of a single customer and not shared with other customers.

Ticket” means a support ticket that describes a request for support or an Error, and that is opened using JRNI's online support portal.

Target Resolution Time” means the amount of time within which JRNI aims to resolve a particular Error. The Target Resolution Time is measured from (a) the time when the relevant Ticket is raised until (b) the time that the Error has been resolved.

Update Schedule” means the frequency with which JRNI will provide updates to Customer after an Error has been reported.

Version” refers to a specific, point-in-time state of the Booking Service, including its source-code, features and capabilities. A Version is identified by either a name or a number, or a combination of the two, to easily differentiate its features and capabilities from any other Version of the Booking Service.

Work-Around” means a temporary work-around, patch or bypass supplied by JRNI in order to temporarily correct an Error.

2. Uptime.

JRNI shall ensure that the Booking Service will be available on the Production Environment, excluding Downtime caused by Scheduled Maintenance, Emergency Maintenance or Force Majeure event, 99.5% of the time in any one calendar month (first day to last day) (the “Service Level”). The Service Level will not apply (and therefore no Service Credits will be applicable) to the extent that any Service Level Failure is caused by: (a) a Penetration Test conducted by Customer without the prior written approval of JRNI; or (b) Customer’s failure to comply with specific instructions provided by JRNI; or (c) a failure of the Customer to comply with any Customer responsibility or obligation detailed in a Statement of Work, Order Form or the Master Subscription Agreement; or (d) Customer’s failure to adhere to JRNI’s best practice guidelines for the use of the API.

3. Booking Service Releases and Versions.

3.1 If Customer is using the Booking Service in a Multi-Tenant Environment the Booking Service will be updated automatically to the newest Edge Version as soon as it becomes available.

3.2 If Customer is using the Booking Service in their own Single-Tenant Environment, the Booking Service will be updated automatically up to three times per year to the newest LTS Version at the dates specified from time to time by JRNI.

a) The Customer may elect to skip one of the LTS Version releases during the year by providing written notice to JRNI at least 14 days before the release date of the LTS Version release to be skipped. If Customer has skipped a release, they will automatically be upgraded to the latest LTS Version at the next release.

3.3 JRNI will provide support, according to the terms set out in this Service Level Agreement, for the current Edge Version, the current LTS Version and the previous LTS Version. Unless otherwise agreed by the Parties, the Response Times, Service Credits, Service Level, Target Resolution Times and Update Schedules will not apply if Customer is on a Version of the Booking Service that is not supported.

3.4 JRNI will not re-create features from the current Version of the Booking Service in older Versions.

4. Support hours.

Telephone and email support will be provided primarily by the JRNI support team that is in Customer’s country of operation. Should we not have a support team in your country of operation we will utilise our worldwide resources to provide support from the most appropriate location. JRNI will provide support according to the table below:

Priority Level

Time

Description

P1

24 x 7 x 365

Phone and/or email support will be provided by JRNI’s Customer Support Helpdesk, for all Priority Levels.

P2, P3 or P4

Monday to Friday (excluding public holidays in the UK and USA), 9:00am to 6:00pm (in Customer’s local time zone).

Except that the API support team is based in London, so API-related support for P2, P3 and P4 Errors will only be provided between the hours of 9:00am to 6:00pm (London time). However, the API support team will coordinate with Customer’s local support team to provide support in as timely a fashion as possible.

Phone and/or email support will be provided by JRNI’s Customer Support Helpdesk, for all Priority Levels.

5. Error Priority Levels.

JRNI will resolve all Errors reported by customers according to the Priority Level set out in the table below. Priority Levels will be determined by JRNI in its sole discretion and will be based upon the information provided at the time the Ticket is raised. If Customer is not satisfied with JRNI’s classification of the Priority Level, then Customer should discuss the matter with JRNI’s Head of Customer Support.

Priority Level

Business Impact

P1

Whole or critical part of the Booking Service is unusable on the Production Environment, causing a major business impact.

For example:

  • Complete server outage
  • An essential component is not available. E.g. the calendar dashboard or customer-facing widget are not loading and therefore the customer’s customers are not able to make bookings
  • An essential component is completely unusable and the issue is not caused by network problems within the customer’s location
  • The issue seriously impacts the customer’s customers or serious complaints are raised
  • The API responds (or fails to) in a manner that renders the Booking Service unusable

P2

Important, but not immediately critical part of the Booking Service is unusable on the Production Environment, causing some business impact.

For example:

  • A small number of locations are affected within the whole customer’s network
  • The customer is unable to view standard JRNI reports via the back-end user-interface
  • A Work-Around is present where an issue would otherwise be P1. For example, it is not possible to book via the dashboard, but it is possible via the add booking feature
  • The customers tab is not available
  • The API responds in a way that prohibits standard tasks, such as data upload

P3

Small, but not critical part of the Booking Service is unusable or has limited functionality, causing some business impact.

For example:

  • Filters within a widget are not responding as expected
  • A Work-Around is present where an issue would otherwise be P2
  • Some emails are not being received
  • The API intermittently fails to respond as expected

P4

Small other items, which may include non-urgent Errors, Errors where acceptable Work-Arounds are available, causing little business impact.

For example:

  • The customer is unable to view bespoke or third-party reports (e.g. from an integrated technology or reports created and sent specifically from JRNI to the customer)
  • A service request – i.e. a user request for information or advice or a standard change (a pre-approved change that is low risk, relatively common and follows a procedure)
  • Single user or customer fault. For example, password resets

6. Error reporting and Resolution procedures.

The procedures for reporting and resolving an Error are as follows:

(a) For all Errors Customer should (i) log the Error using JRNI's online support portal, or (ii) call the JRNI Customer Support Helpdesk.

(b) Once the Error has been reported by Customer, JRNI will:

(i) Determine the Priority Level and confirm this to Customer.

(ii) Respond within the agreed Response Time.

(iii) Open a support Ticket (if this has not already been done per the steps above). All Tickets will be opened using JRNI's online support portal, which is actively monitored by qualified JRNI support personnel. The status for all Tickets previously reported by any customer can be viewed by JRNI support personnel via the support portal.

(iv) Provide an estimate of the Target Resolution Time.

(v) Assign resources to correct such Error within the relevant Target Resolution Time. JRNI will use all commercially reasonable efforts to correct the Error in an expeditious manner and will inform Customer of the progress, including the steps being taken to resolve the Error, the expected time for resolution of the Error and any resolution of the Error.

(vi) Provide updates as per the agreed Update Schedule. JRNI will endeavour to resolve all Errors in the first response, but should this not be possible JRNI will provide ongoing status updates and information about when we expect any Errors to be resolved. Additional information exchanges related to an open support case may be conducted via email, telephone, or web meeting communication, as appropriate to the case. Customers can check the status of their Ticket at any time using JRNI's online support portal.

(c) While we endeavour to resolve any Errors within the Target Resolution Time, our attainment of the target will be related to the amount of development work that is required to rectify the Error. Equally, we try to, and are often able to resolve problems far quicker than the target times if the work required allows:

(i) If an Error has not been corrected within the Target Resolution Time we will discuss the situation with the Customer and mutually agree a resolution which may include a Work-Around.

(ii) Notwithstanding the availability of a Work-Around, JRNI will continue to work to fix the Error and, in any event, provide Customer with the applicable permanent correction within: (a) ten (10) calendar days for a P1 Error; or (b) four (4) weeks for a P2 Error. The timeline for permanent correction of P3 and P4 Errors will be agreed between the Customer and JRNI on a case-by-case basis.

(iii) If JRNI cannot correct a P1 or P2 Error within the time periods described in paragraph 6(c)(ii) above, then Customer may immediately terminate the relevant Subscription, Order Form and/or this Agreement.

(d) All Errors are categorised in accordance with the Priority Levels defined in this Appendix. Any support requests not categorised as set forth herein will be addressed in the ordinary course of business by JRNI, and any applicable modifications or corrections of the Booking Service will be delivered in the next release of the Booking Service after implementation of the correction(s).

(e) These procedures only apply to live customers. Errors that are discovered during a Customer’s implementation phase will be handled by the implementation team according to the procedures defined during that phase.

(f) Errors that are discovered during the implementation process and present when a Customer goes live will be handled according to any previously agreed arrangements and not according to the procedures outlined in this Appendix.

(g) Errors that are caused by Customer’s suppliers (e.g. implementations performed by Customer’s systems integrator or configuration of the Booking Service by Customer’s professional services partner) may not be able to be corrected by JRNI and must be corrected by the relevant supplier.

7. Response Time, Update Schedule and Resolution Time.

The Response Times, Update Schedule and Target Resolution Times described above are as follows:

Priority Level

Response Time

Update Schedule

Target Resolution Time

P1

2 hours

2 hours

24 hours

P2

1 business day

1 business day

10 business days

P3

1 business day

Upon request

To be agreed between the Customer and JRNI on a case-by-case basis

P4

1 business day

Upon request

To be agreed between the Customer and JRNI on a case-by-case basis

8. Monitoring of JRNI Application.

JRNI will regularly monitor the status of the Booking Service (including routine checks on the hardware, processes and wait queues) using both automated and manual tools and testing procedures.

Upon request by Customer, but no more than once per calendar month, JRNI will provide a report listing all Customer-affecting service and outage faults during the prior month, including:

  • Date and time of fault
  • Impact of fault on service provision
  • Service outage duration
  • Description of Error and resolution identifying steps taken to prevent future occurrences
  • Scheduled releases

9. Service Credits.

If, as recorded at the end of a calendar month, the Booking Service fails to achieve the Service Level, Customer is eligible to receive a Service Credit as detailed in the table below. The Service Credit percentage will be calculated in relation to the Fees payable in the month in which the Service Level Failure occurred:

Uptime in a calendar month

Service Credit

Less than 99.5% but greater than or equal to 99.0%

5%

Less than 99.0% but greater than or equal to 95%

15%

Less than 95% but greater than or equal to 90%

50%

Less than 90%

100%

JRNI shall deduct any Service Credits due at the end of a calendar month from the Fees due to JRNI that month or, where Fees have been paid in advance, refund the Service Credit amount within 30 days of the end of the relevant calendar month. Should a Service Credit be earned in the final month of the Booking Service being provided, JRNI shall deduct the Service Credit against outstanding amounts due to JRNI under this Agreement, and if no amounts are due, JRNI will refund the Service Credit amount to Customer within 30 days of the Booking Service having terminated.

The Parties acknowledge that the Service Credits represent a genuine pre-estimate of some of the losses that the Customer would suffer in the event of a Service Level Failure.

Worked Example:
February Uptime: 99.4%
February Fees: $1,000
Service Credit: $50
March Fees: $1,000 less $50 Service Credit = $950

10. Data Backup Cycles.

JRNI operates the following backups for all customers:

  • Hourly. Additional hourly data backups are transferred to an external data storage service, to allow the recovery of service if a disruption of services at the primary data center prevents automated recovery. Hourly backups are available for the last fourteen (14) days.
  • Daily. Daily backups, typically taken at midnight, are also transferred to an external data storage service. Daily backups are available for the last sixty (60) days.

In addition, for those customers that choose JRNI’s standard hosting provider, the database servers have a built-in snapshot and recovery process, allowing for the rebuilding of a cloned database server without the need to go direct to backups. Snapshot capabilities are available for the last eight (8) days.

The infrastructure used for all off-server storage solutions is designed with a higher than 99.999% resilience, redundantly storing each backup across multiple data center facilities. The integrity of the storage solution can sustain and restore data integrity after a concurrent loss of equipment in any two (2) facilities.

Restoration of databases for the resolution of issues caused by customers (e.g. deleting records by mistake) is at the sole discretion of JRNI. Restoration times are dependent on database size and will be mutually agreed with Customer.