Service Level

Definitions

Capitalised terms have the meaning given to them in the Agreement or below in this Service Level Agreement.

1. Error – malfunctioning of the Services, covered by the categories described in the relevant table;
2. Notification – a notification of a failure duly communicated by the Principal to the Contractor, i.e. in particular through the applicable communication channel, containing both a description of the malfunctioning element(s) covered by the SLA and a set of further information required to analyse it and take appropriate action within the meaning of the SLA;
3. Response time - the time between the Notification and the Contractor's sending of its acknowledgement and the start of its analysis;
4. SLA – this document, i.e. Service Level Agreement;
5. Services – services covered by the SLA in the form of the functionalities of the Application, including those accessible from the APIs described in API documentation:: Synerise Help Center.

‍

Scope of SLA

1. The Contractor guarantees the specified availability and performance quality of the Services.
2. In view of the above, the SLA does not cover elements such as:
3. data quality;
4. Errors caused by data or broadly defined materials provided by the Principal or entities acting on its behalf;
5. Errors caused by exceeding any limits described in the documentation or set by the Principal.
6. The Services operate in 24/7/365 mode.

‍

Communication channels

Notifications will be submitted by persons authorised by the Principal, through a portal provided by the Contractor, operating at http://synerise.com/support/. At the same time, the Principal acknowledges that:

1. The Contractor is entitled to unilaterally change the method of submitting the Notifications – communication in this respect will take place through coordinators within the meaning of the Agreement;
2. only in the event of problems with the operation of the portal in the above sense, preventing the submission of the Notification through it, the Contractor may accept the Notification using the e-mail channel at support@synerise.com.

‍

Guaranteed availability

Application availability:

1. is understood as an opportunity to interact with the Application in order to carry out business activities;
2. is measured by external mechanisms, independent of the Contractor (currently by https://hund.io);
3. is calculated as an average for each calendar month and reported at https://status.synerise.com;
4. is guaranteed at the level of 99.5% (in words: ninety-nine and a half per cent).

‍

Planned maintenance work

The Contractor has the right to carry out maintenance work under the following conditions:

1. it shall be carried out between 11 p.m. and 6 a.m. for the time zone applicable to the Contractor;
2. upon prior notification at least 48 (in words: forty-eight) hours prior to the planned commencement of said work, made using communication channels within the meaning of the SLA or the Agreement;

At the same time, the Contractor:

1. confirms that during the said works, the data transmitted to the Application will not be lost but only loaded into the Application with a delay (depending on the specific nature and duration of the said works);
2. shall provide the Principal with information on the unavailable elements of the Services and the planned duration of their unavailability.

For the avoidance of any doubts, the Principal acknowledges that service works as defined above do not reduce the level of guaranteed availability within the meaning of the SLA.

‍

Error types and response times

‍

Conditions for reporting and handling Errors:

1. Under the pain of invalidity, the Notification should contain:
2. the name and surname of the notifier and the e-mail address;
3. the reporting person's assessment of the level of the error (critical = very high, serious = high, average = medium, fault = low);
4. screenshots (if available);
5. the name of the Profile to which the Notification relates;
6. time of occurrence of the Error;
7. the business process identifier visible in the Application, to which the Error relates, e.g. CampaignId, ClientId, AutomationId (if possible);
8. attachment of a scenario brief (if available);
9. a description of the Error with the elements defined for the specific incidents described below, together with a campaign brief, if available;
10. request logs (request + response), particularly necessary in cases where the event relates to the Principal's 3rd party systems
11. information about the users affected by the Error: user ID, mobile application version, OS version if the Error occurs in the Principal's mobile application;
12. a list of steps leading to the reproduction of the Error (if possible);
13. If the Error relates to a business process that depends on Application objects created or configured by the Principal and not authorised by the Contractor, the Principal shall indicate these objects in the Notification and verify their correctness before sending the Notification by confirming this fact in the Notification itself, e.g.:
14. when the Notification concerns a business process using a customer segment defined by the Principal, the Principal shall verify the correctness of the construction of this segment;
15. when the Notification relates to a business process using jinjava, as defined by the Principal, the Principal will verify the syntax and availability of the elements necessary for the business process (aggregates/voucher pool/attributes/records in the catalogue);
16. for the automation realising the scenario of integration of the Application with other systems, as defined by the Principal, the Principal will verify the webhooks (method of authorisation, tokens, correctness of headers, correctness of the body);
17. for business processes using CRM, the Principal will verify that the correct user_ID is used (to cover the case that there are two different customers with the same name in the Application database).
18. Response time calculation:
19. The notification is considered to be correctly made only when a complete set of information enabling its analysis is provided - until then, the obligations of the Contractor indicated in the SLA, in particular regarding broadly understood response times, do not apply to it.
20. in the case of the Notification made through the website indicated above in the SLA, the Response time is calculated from the moment the complete Notification is submitted through this website;
21. in the case of a Notification sent by e-mail, the Response time is calculated from the moment of sending of the e-mail by the Principal, provided that the Principal receives a confirmation of receipt of the Notification so made;
22. The Notification shall also be deemed to have been correctly made by the Principal if, after the expiry of the time specified as Response time plus one hour, the Contractor does not comment on the completeness of the information provided by the Principal in the Notification.
23. Error reports are made by persons indicated by the Principal (through the coordinator within the meaning of the Agreement).