FIRST CLAUSE

Definition

• SLA: For the purposes of this Contract, Service Level Agreement ("SLA") refers to the technical performance level of the service provided by the CONTRACTED PARTY for the Solution, as indicated in the SO (Service Order);
• Incident: Any unexpected event that causes instability or interruption in the contracted service;
• Problem: The root cause generating one or more incidents.

SECOND CLAUSE

SLA Criteria

• Unless otherwise stipulated in the SO, technical support will be provided on business days (Monday to Friday, excluding national holidays), from 9:00 AM to 6:00 PM, Brasília Standard Time;
• In the event of Unavailability (defined below), support by the CONTRACTED PARTY will be provided through an on-call service available from Monday to Friday, from 6:00 PM to 9:00 AM, and 24 hours a day on Saturdays and Sundays. For the avoidance of doubt, unavailability is defined as the total inability to perform one of the services monitored and included in the Uptime;
• For the avoidance of doubt, Uptime is defined as the amount of time the Solution is available and performing computational activities without discontinuity of this operational state, per month; specifically, it must be available 95% (ninety-five percent) of the time each month during the contract term (excluding maintenance windows);
• Occurrences must mandatory be registered and managed by the CONTRACTOR either by sending an email to suporte@meudroz.com or by opening a ticket at the support center on the platform https://help.meudroz.com/, which must be available for this purpose on the days and times stipulated in item 2.1 of this SLA.

THIRD CLAUSE

Monitored Services The services provided by the CONTRACTED PARTY that are subject to monitoring, SLA control, and Uptime counting are: (i) Web widget API; (ii) Sunshine Conversations API; (iii) Admin Panel; (iv) Dashboard API; (v) Droz Nexo; (vi) Droz Base.

For the avoidance of doubt, the SLA for the services described in item (ii) above shall only be applicable to clients who have entered into a contract with Droz that includes messaging services, responsible for communication between the Droz system and the following channels: WhatsApp, Facebook Messenger, Instagram, Telegram, Line, WeChat, Twitter, Viber, Apple Chat, Message Bird, Twilio, and Sunco Web Messenger.

FOURTH CLAUSE

Classification and Failure Recovery Times

• All incidents are classified according to Impact x Urgency, defining the incident severity, where:
  • Urgency: The perception of the appropriate speed required to resolve a failure considering its impact on the business;
  • Impact: The extent of the damage the failure may cause to the business;
• Impact and Urgency definitions may be reclassified by the Droz Product Support team after understanding and analyzing the incident, thereby defining the ideal priority for each occasion;
  
  

Priority Matrix

Impact Criteria for Web widget API, Sunshine Conversations API, Admin Panel, and Dashboard API:

• High: Services are unavailable to all users, and no alternative is available for users to utilize the product;
• Medium: Services show partial instability in operation, impacting all of the Client's users;
• Low: Services show a loss of performance for users;
• Very Low: Other incidents not falling into the above categories, or isolated unavailability for a specific client.

Impact Criteria for Droz Nexo and Droz Base:

• High: Services are unavailable to all users, and no alternative is available for users to utilize the product;
• Medium: Services show partial instability in operation, impacting all of the Client's users;
• Low: Services show a loss of performance for users;
• Very Low: Other incidents not falling into the above categories, or isolated unavailability for a specific client.

1. Urgency Criteria for Service Failures:

   • High: The contracted Droz service is the primary means of execution, and there is no alternative method for the client;
   • Medium: The contracted Droz service is the primary means of execution, but an alternative method is available to the client;
   • Low: The contracted Droz service is not the primary means of execution, and an alternative method is available to the client.
   • Incident recovery times, even if through a workaround solution, will occur within the timeframes defined in the table below. Recovery times start counting from the acceptance of the ticket by the support team through the tool until the failure is resolved, which may occur before the ticket response is sent to the Client. Due to existing proactive monitoring on the Bot and Admin Panel, reported incidents may already be under treatment by the Droz technical team.

   Priority	Maximum First Response Time	Maximum Recovery Time
   Critical	2 hours	6 hours
   High	4 hours	12 hours
   Medium	6 hours	48 hours
   Low	8 hours	96 hours
   Agreed	Per Droz Support feedback	Per Droz Support feedback

   • 
     The first response time counts within the window defined in item 2.1;
   • Enhancement requests and Project requisitions do not fall under the classifications described above. Cases of this nature will be registered by the support team, assigned to the Product owners, and subsequently closed. The prioritization and execution of these cases depend on prioritization according to the product strategy and evolution. Once a Client request is implemented in the Product, the requester will be informed by the Droz team.

   FIFTH CLAUSE

   Escalation Policy Escalation will be triggered after the resolution times provided in item 4.6 have expired, according to the resolution priority. Subsequent levels may be triggered at every 50% fraction of the maximum resolution timeframe.

   Level	Name	Contact
   First Level	Droz Support	suporte@meudroz.com
   Second Level	Support Coordinator - Vinicios Nogueira	[Protected Email]
   Third Level	Head of Droz - Diego Boesso	[Protected Email]

   SIXTH CLAUSE

   SLA Control SLA control can be monitored via the following website: https://status.meudroz.com/

   SEVENTH CLAUSE

   Uptime and Availability

   • The availability of Droz services is measured by the number of hours per quarter. Our commitment is to maintain an availability time greater than 95%;
   • [(Total minutes in quarter - Total minutes of downtime) / Total minutes in quarter] > 95%
   • Downtime calculation begins after the ticket is accepted, as described in item 4.5;
   • In certain situations, maintenance will be necessary to ensure the best performance of services. When there is a period of scheduled downtime, we will notify all active Clients, and these events will not be considered within the timeframes and agreements established in this document. The Droz team commits to notifying Clients at least 48 hours in advance.