Service Level Agreement

Service Level Agreement (SLA)

1. Definitions.

1.1 In this SLA, capitalised words and expressions shall have the meanings given to them in the Master Services Agreement entered into between you and JRNI (“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.

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

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

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.

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.

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 Availability Service Level. The method of calculating Service Credits is set out below.

Service Level” means each and any of the Availability Service Level and the Response Times, Update Schedules and Target Resolution Times referred to in the table at paragraph 7 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.

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 “Availability Service Level”). The Availability Service Level will not apply (and therefore no Service Credits will be applicable) to the extent that any Availability 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 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 Customers will be updated automatically to the latest Version of the Booking Service.

3.2 JRNI will provide support in accordance with this Services Level Agreement for the latest Version of the Booking Service only. This Service Level Agreement including the Service Levels and Service Credits will not apply if Customer is not using the latest Version of the Booking Service.

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




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


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


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


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


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 the designated online support portal, or (ii) call the designated 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.

(d) All Errors are categorised in accordance with the Priority Levels defined in this SLA. 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 SLA.

(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 Target 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


2 hours

2 hours

24 hours


1 business day

1 business day

10 business days


1 business day

Upon request

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


1 business day

Upon request

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

8. Purchase of the Booking Service via an authorised reseller

If Customer has purchased the Booking Service via a JRNI authorised reseller or distributer, Customer acknowledges and agrees that JRNI’s obligations hereunder in respect of front line support (which may include as applicable: call receipt, call screening, incident reporting and tracking, database problem searching and resolution of documented problems, installation assistance, problem isolation, determining the next step in problem resolution (including but not limited to providing a work-around solution) and identification and diagnosis, and the distribution of any replacement media, minor updates or maintenance releases) (“Front Line Support”) may be fulfilled by such authorised reseller or distributer (instead of by JRNI) in accordance with the reseller’s or distributer’s standard support processes and response times. In such case, the reseller or distributer shall be solely responsible and liable to Customer for the provision of the Front Line Support and JRNI expressly does not accept liability for the same.

9. 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

10. Service Credits.

If, as recorded at the end of a calendar month, the Booking Service fails to achieve the Availability 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 Availability Service Level Failure occurred:

Uptime in a calendar month

Service Credit

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


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


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


Less than 90%


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 an Availability Service Level Failure. The Service Credits are Customer’s sole and exclusive remedy and JRNI’s entire liability for an Availability 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

11. 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.