Software as a Service (SaaS) Service Level Agreement
Effective September 2023 onwards
Overview
This Support Services Policy applies to the standard support provided by Syrenis as part of the SaaS service purchased by you as stated in the Order.
Support Terms
SaaS Fees
The Fees paid by you as stated in the Order include the support described in this SaaS Services Policy.
Support Hours
Service desk hours are: –
| UK | 09:00 to 17:30 BST Monday to Friday, excluding UK Bank Holidays, however tickets can be raised electronically at any time. |
| EU | 10:00 to 18:30 CET Monday to Friday, excluding UK Bank Holidays, however tickets can be raised electronically at any time. |
| US | 09:00 to 17:00 EST Monday to Friday, excluding UK Bank Holidays, however tickets can be raised electronically at any time. |
Contact details:
| EU | 0800 368 7842 (UK) or +44 20 4551 9501 |
| US | +1 844 585 6264 (USA/Canada Toll Free) |
| AUS | +61 2 5119 5048 |
Email support contact: [email protected]
Support Period
Syrenis SaaS support is effective upon the “Commencement Date” specified in your ordering document and ends upon the expiration or termination of the SaaS subscription.
Incident Reporting
You must report Incidents or service failures using the support feature built into our products.
For critical incidents (only), you MUST follow up by phone call. When calling either of the support numbers in this SLA you can press 2 for Support and depending on the time an agent will answer or you can leave short message. This will trigger our critical incident response process 24×7.
Incident Categories
Incidents will be categorised in two dimensions Urgency and Impact as set out in the tables below by Syrenis at the time each Incident is reported. The Urgency determines how fast the incident needs to be dealt with and the Impact is related to how many users or parts of the service are impacted by the incident. Together these help us understand in which order to deal with incident depending on how many users and parts of the service are affected.
Syrenis may subsequently change priority of such an Incident if it is reasonable to do so in the circumstances.
| PRIORITY MATRIX | URGENCY | |||
|---|---|---|---|---|
| Impact | Critical | High | Medium | Service Request |
| Extensive | P1 | P1 | P2 | P3 |
| Significant | P1 | P2 | P3 | P4 |
| Moderate | P2 | P2 | P3 | P4 |
| Minor | P2 | P3 | P3 | P4 |
Definitions used in triaging Incidents:
| URGENCY | DESCRIPTION |
|---|---|
| Critical | A serious business impact is occurring now. The Incident needs to be resolved immediately. |
| High | The Incident needs to be resolved as soon as possible because of potentially damaging service impact. |
| Medium | There is missing or broken functionality that needs to be fixed. |
| Service Request | A request to improve efficiency or effectiveness. |
| IMPACT | DESCRIPTION |
|---|---|
| Extensive | The Incident is causing immediate and significant disruption affecting either: life, safety or business critical transactions while in use. No easy workaround available. |
| Significant | The Incident is causing immediate and significant disruption but not affecting life, safety, or business critical transactions and services while in use. No easy workaround available. |
| Moderate | The Incident is causing or will cause disruption in the near term. Workaround is often available. |
| Minor | The Incident is not causing disruption but still needs to be fixed. |
Responding to Incident Reports
- With your co-operation, Syrenis will use reasonable endeavours (at Syrenis’ cost) to prevent repetition of future service level failures.
- Service failures shall be excused to the extent that the failure arises out of:
a. A force majeure event as described in this agreement; or
b. An act or omission by you as the Customer. - Within 10 days of a failure of the Service, Syrenis will provide a full response to you including root cause analysis, action taken and long-term actions to prevent future occurrences.
Indicators and Target Service levels
| PERFORMANCE INDICATORS | MEASUREMENT PERIOD | TARGET SERVICE LEVEL | MINIMUM SERVICE LEVEL |
|---|---|---|---|
| Service uptime except maintenance windows* | Monthly | 99.9% (a rate of no more than 43 minutes and 12 seconds downtime in a 30 day period). | 99.8%(a rate of no more than 1 hours, 26 minutes and 14 seconds downtime in a 30 day period). |
| RPO of 4 hours to be maintained | Daily | 24 replications per day | 6 replications per day |
| Incident & Requests: First Time Fix | Quarterly | Incident: 80% Request: 90% | n/a |
| Incident & Requests: Average Response Time (Measured from the time it is correctly logged to the time it is triaged and assigned a reference, within the Support Hours) |
Quarterly | Incident: P1 –15mins P2 –15 mins P3 –15 mins P4 –15 mins | n/a |
| Incident & Requests: Average Resolution Time. (Measured from the time it is correctly logged to the time it is resolved or downgraded within the Support Hours & excluding time spent in Customer or Resellers queue) |
Quarterly | Incident: P1 – 1hr P2 – 4hrs P3 – 8hrs P4 – Next Patch | Incident: P1 – 1hr P2 – 4hrs P3 – 2 days P4 – Next Patch |
| Change Requests and their statuses (e.g. Reviewed, Costed and Implemented). | Quarterly | 10 days to finalise SOW and cost 10 days from approval to agree a targeted implementation date |
15 days to finalise SOW and cost 15 days from approval to agree a targeted implementation date |
*Our Standard Maintenance Periods are up to 1 hour of outage per service on Saturdays and Monday morning GMT, occurring within the window of 03:00 – 5:00. Additional maintenance windows will be by prior communication and consultation.
Maintenance Windows
Support Period
Our Standard Maintenance Periods (SMP) reserve up to 1 hour of outage per service on Saturday and Monday mornings in the time zone of the region your service is hosted, occurring within the window of 03:00 – 5:00. Additional maintenance windows will be by prior communication and consultation.
During the SMP one of three scenarios will occur:
- The maintenance window will not be used. There will be no impact to service.
- We will undertake Infrastructure component patching or major refreshes. No service outage will occur, and the service will run at 50% resilience during this period. The service will still scale to give the same throughput performance. This scenario is used 1-2 times a month.
- Full Outage Maintenance. Very rarely used. Syrenis reserve this facility in case there is ever the need to simultaneously take multiple availability zones out of service. Cassie dataflows use submission queuing techniques to ensure that the system will catch up after any form of outage, therefore reducing the risk of any data not being captured during this scenario.
Please refer to the following table for more details.
SMP Regions
| REGION COMMON NAME | AWS ZONE | TIMEZONES (STD / DAYLIGHT SVG) |
|---|---|---|
| US East (North Virginia) | us-east-1 | EST/EDT (UTC-5/UTC-4) |
| US West (Oregon) | us-west-2 | PST/PDT (UTC-8/UTC-7) |
| Asia Pacific (Sydney) | ap-southeast-2 | AEST/AEDT(UTC+11/UTC+10) |
| Canada (Central) | ca-central-1 | EST/EDT (UTC-5/UTC-4) |
| Europe (Ireland) | eu-west-1 | GMT/IST (UTC/UTC+1) |
| Europe (London) | eu-west-2 | GMT/BST (UTC/UTC+1) |
| Asia Pacific (Singapore) | ap-southeast-1 | SGT (UTC+8) |
UAT Instances
The UAT instance should not exceed 10% of the live contracted service. Syrenis reserve the right to maintain the UAT environments by providing 24 hours’ notice and have the right to cleanse data that is more than 3 months old.
Additional UAT capacity is available on request.
Transaction Throughput
Cassie can be delivered on 3 different infrastructure tiers. Each tier has different performance characteristics. The following are the benchmarks based on tests undertaken by Syrenis using our performance measurement tools.
| Infrastructure Tier | Standard API¹ | Connector Service¹ | Transactional API¹ |
| Standard | 100/min | 100/min | Standard² |
| Enterprise #1 | 1000/min | 1000/min | Standard +² |
| Enterprise #2 | >1000/min | >1000/min | Standard ++² |
¹All performance measurements are obtained using Syrenis performance measurement tools. Factors outside the control of Syrenis can affect performance.
²the transactional API will perform at greater volumes however the actual metric is determined by the complexity of the matching logic and therefore comparison across infrastructure tier is not possible.