Last Modified: September 09, 2024
THIS AGREEMENT IS SUBJECT TO THE MASTER SERVICES AGREEMENT WHICH GOVERNS THE CUSTOMER PURCHASE AND RECEIPT OF THE BASELINE PRODUCTS AND SERVICES.
SERVICE LEVEL AGREEMENT CREDITS
1. SUBORDINATION AND DEFINED TERMS
1.1 Subordination. This Agreement is a party and is subject, in all its terms and conditions, to the Master Services Agreement.
1.2 Terms defined in the Agreement. Except as otherwise expressly set forth in this Agreement, capitalized words, in the singular or plural, shall have the meanings assigned in this Agreement.
1.3 Terms defined in this Agreement. The terms listed below, when used in this Agreement with the initials capitalized, in the singular or plural, shall have the meanings assigned in this Clause:
|
Defined Terms |
Meaning |
|
Baseline Designated Contacts |
These are the persons designated and authorized by Baseline to respond to a Ticket, provide the support and maintenance services provided for in the Service Level Agreement and perform any other interaction with Customer under the Level Agreement of service. |
|
Contacts Designated by Customer |
These are the persons designated and authorized by Customer to open a Ticket, request the execution of support and maintenance services provided for in the Service Level Agreement and perform any other interaction with Baseline under the Agreement of Level of Service. Service. |
|
Technical Account Manager (TAM) |
Person is a person with a management level designated by Baseline to serve any Ticket that involves a Critical Severity Incident or any other Tickets that have not been properly served by the Baseline Designated Contacts. |
|
Incident |
means any unplanned outage of a Baseline Service or a reduction in the quality of a Baseline Service, excluding Change Requests. |
|
Availability SLA goal |
Has the meaning assigned in Clause 3.1. |
|
Goal of SLA of Ticket Resolution |
It has the meaning assigned in Clause 4.1. |
|
Availability |
Means the Period of a given month calculated in percentage terms. |
|
Availability Period |
Means the total period of time in a particular month in which the Baseline Systems and the Application have been operating uninterrupted, in accordance with the criteria and conditions set forth in this instrument. |
|
Unavailability Period |
Means the total period of time in a particular month in which the Baseline Systems and / or the Application presented interruptions of one or more services, according to the criteria and conditions set forth in this instrument. |
|
Total Time Period |
Means the total amount of time in a given month, which will be obtained by multiplying (i) the total number of days in the month of competence by (i) 1,440 (24 hours x 60 minutes). |
|
Baseline’s official support system Electronic Platform |
means the electronic platform maintained by Baseline through which Customers can open, monitor and monitor the Ticket Resolution of Tickets and the resolution of Incidents. |
|
Report |
Has the meaning assigned in Clause 2.8. |
|
Baseline Systems |
Means all software and hardware used by Baseline for the provision of services by Baseline and Baseline Services in the Resolution, including, but not limited to, all computer programs, terminals, computers, platforms, databases, Baseline services and media used for the execution of the Agreement. |
|
Ticket Resolution SLA |
Means Baseline's commitment to attending Incidents to specific deadlines in a satisfactory manner. |
|
Request for Change |
Means a formal amendment proposal, additional to the project envisaged and agreed upon by both parties as to the delivery of the project. This includes new functional developments or technical adaptations of new technologies or standards that may arise in the future and / or not agreed upon in the project. |
|
Ticket End |
Has the meaning assigned in Clause 2.7.6. |
|
Ticket |
Means the request for the resolution of Incident, requests, doubts or other type of request for service. |
2. SUPPORT AND MAINTENANCE SERVICES OF BASELINE AND APPLICATION SYSTEMS
2.1 Support and maintenance. By virtue of the Service Level Agreement, Baseline undertakes to provide support and maintenance services for Baseline Systems and / or the Application, as well as performing any other activity that is required or required by Customer to maintain Baseline Systems and / or the fully functioning Application, as provided in this instrument and in the Agreement.
2.2 Language. In interaction with the representatives and the Designated Contacts for Customer, Baseline should communicate and make their employees and representatives communicate only (i) in English Language Writing and English Language Spoken.
2.3 Office hours. Baseline is required to provide Application Support and Maintenance services EST, from 8:30 am to 5:00 pm EST on weekdays.
|
Severity ofIncident |
Working hours |
|
Critical (Level 5) |
24-hour |
|
Urgent (Level 4) |
8h30 to 17h* |
|
High (Level 3) |
8.30 to 17h* |
|
Average (Level 2) |
08h30 to 17h* |
|
Low (Level 1) |
08h30 to 17h* |
* does not include weekends and holidays, exclusively.
2.3.1 Time Zone. The schedules indicated in the table above are established based on EST.
2.3.2 Counting Response Times and Resolution Times. Inquiries will not start counting the Response and Resolution Times, since such metrics will only have their counts started at the time Tickets are opened in Baseline’s official support system, according to the procedure described in Clause 2.7.
2.4 Tools and channels for opening tickets. Customers shall open any Ticket for the resolution of Incidents through Baseline’s official support system Electronic Platform.
2.5 Baseline’s official support system. Baseline shall grant and maintain active Customer access to its official support system, by means of an individual login and password. Should any of the Customer Designated Contacts be replaced, Baseline shall arrange for the inclusion of the new Designated Contact of Customer on Baseline’s official support system Electronic Platform, by granting a new individual login and password.
2.6 Incidents. Incidents will be classified according to their level of severity and impact on the operation of Baseline Systems and their integration with the Customer systems.
2.7 Procedure for opening and follow-up of Tickets and resolution of Incidents. The Parties shall observe the rules set forth below for the opening and follow-up of Tickets and for the resolution of Incidents.
2.7.1 Opening of Tickets. At any time during the Term of the Agreement, observing the 24x7x365 (24 (twenty four) hours per day, 7 (seven) days per week, 365 (three hundred and sixty five) days per year), Porto Insurance, through any Representative or Contact Designated by Customer, may open a Ticket and communicate to Baseline.
2.7.2 Information on opening the Ticket. Upon opening of a Ticket, Customer shall (i) classify the Incident object of the Ticket according to its severity level; and (ii) report the Incident in the most accurate and detailed manner possible, so as to enable Baseline to have all reasonable information available to resolve the Incident in the shortest time possible. In the event of several incidents reported, each one will receive the classification that corresponds to him, not having unified treatment for all incidents reported in the same act.
2.7.3 Confirmation of the opening of the Ticket. The parties must inform the opening of the Ticket in Baseline’s official support system Electronic Platform for the resolution of an Incident. The Tickets must necessarily be opened through Baseline’s official support system Electronic Platform, observing Clause 2.3.3. The confirmation of the opening of the Ticket will be done automatically, through the platform itself.
2.7.4 Reclassification of the level of severity of the Incident. In case Baseline understands that the Incident has been classified by Customer in a severity level more serious than it should, then Baseline shall communicate such understanding to Customer in the shortest possible time span. In the event that the Parties can not agree on a downgrading of the level of severity of the Incident, in accordance with the criteria set forth in Clause 4.3 of this Service Level Agreement, the matter shall be resolved by negotiation between the Chairman of Baseline and the manager responsible for Customer Electronic Channels Area.
2.7.5 Incident Resolution. After the opening and eventual confirmation of the level of severity of the Ticket, Baseline shall, observing the maximum resolution periods of each severity level, arrange for the resolution of the Incident, such that failure, error, interruption or unavailability in the Application communicated by Customer ceases to exist.
2.7.6 Closing of the Ticket. After Baseline considers the Ticket closed, Customer will have 3 (three) business days to reopen said Ticket ("Ticket End"). Tickets can only be considered closed after the complete resolution of the Incident that originated its opening.
2.8 Reports. As required, upon request from Customer following an actual, or possible SLA failure, Baseline shall be required to submit to the Customer a written report containing the description of the support and maintenance activities performed by Baseline in the affected period. In the report, Baseline should detail: (i) the total number of Tickets opened and completed in the month of competence; (ii) the total inventory of pending Tickets; (iii) the opening hours, closing hours and pause time with Customer of each completed ticket; (iv) if each completed Ticket is liable to SLA penalty and whether it has been served within or outside the SLA; (v) indication of the severity level of each open and completed Ticket and any reclassifications agreed between the Parties; (vi) the Availability Period and the Period of Unavailability of Baseline components determined by its platform and the critical severity incidents opened by Customer; and (vii) the Service SLA and Availability SLA ( Report").
3. SYSTEM AVAILABILITY
3.1 System Availability. Baseline is obliged to keep Baseline Systems and the Application in full operation and fully available for use by Customer, its Affiliates, Representatives and External Users, in the 24x7x365 (24 (twenty four) hours per day regime, 7 (seven) days per week, 365 (three hundred and sixty five) days per year) for at least 99% (ninety-nine percent) of the Total Time Period of each month ("Availability SLA Target") .
3.1.1 Example of conversion of the Availability SLA Target into units of time. For a 30-day month, for example, Baseline Systems Availability SLA Target will equal 717 hours and 41 minutes. In other words, the Application Period can not exceed 7:12 am, under penalty of applying the penalties provided in this instrument.
3.2 Components for determination of the Period of Unavailability. The Unavailability Period will be calculated according to the unavailability time of the components that are included as an integral part of Baseline’s solutions. These components are indicated in the table below, with their respective Alert Levels (maximum values that are allowed to be reached), Alert Limits (the time the alert level should exceed to alert Baseline 24/7 support center and notify by any means or channel to Customer) and the Weight of each component in the calculation (used to calculate the financial penalties). For example, if there is a 60-minute degradation of a component having a weight of 10%, the incident would only apply to 6 minutes of Uptime Assurance.
|
Component |
Description |
Alert Level |
Limit |
Weight |
|
Account Portal |
System used by internal users |
10 Seconds |
15 Minutes |
10% |
|
Communication Engine (to send e-mails, sms, push app) |
Send emails, SMS, in app pushes |
5 items |
15 Minutes |
10% |
|
External API Gateway |
Connection to external systems |
5 seconds |
15 minutes |
10% |
|
Infrastructure GCP |
Environment Cloud Hosting |
one second |
15 minutes |
100% |
|
Mobile Application |
iOS and Android Application |
15 Minutes |
10% |
3.3 Availability Period Measurement. For the determination of the Availability Period, the total time of unavailability of each component at the end of each month, taking into account its weight, will be added and compared to the Availability SLA Goal, to verify whether this was or not achieved.
3.4 Failure to achieve Availability SLA Goal. If the Availability SLA falls below the Availability SLA Goal in a given month, Baseline shall be subject to the penalties provided for in Clause 5, without prejudice to any others provided for in the Contract.
- SLA FOR TICKET RESOLUTION
4.1 SLA for Ticket Resolution. Baseline undertakes to use its best efforts to resolve all incidents of Tickets of Customer in the respective resolution deadlines, according to the severity level of each Incident, and must comply with at least one SLA of Ticket Resolution equal or higher than 90% ("SLA Target for Ticket Resolution").
4.2 Criteria for determining the Service SLA. The calculation of the Service SLA is based on the total time that the Ticket was under Baseline's responsibility. Excluded from the time elapsed is the time that the Ticket was under the responsibility of Customer, as exemplified in the table below, in which the Requester's Wait Time is translated as "Requester wait time":
4.3 Response time and resolution. "Applicant Waiting Time" is the maximum duration (indicated in hours, below in the "D" or "E" columns of the table) where Baseline must resolve an incident, depending on the severity level. The resolution time must comply with what is indicated in the table below, considering the severity level of each incident and the Applicant Waiting Time, where:
- The column "D - Deadline (if publication is required)" indicates the deadlines that Baseline has to resolve the tickets classified in the Baseline’s official support system Electronic Platform in the "What can we help you with" field, such as "Technical issues and bugs", which occur in the provision of Baseline Services. The deadlines indicated in column D are considered for the application of penalties.
- The column "E - Deadline (if publication is not required)" indicates the deadlines that Baseline has to resolve all tickets, except tickets classified in the Baseline’s official support system Electronic Platform, in the "What can we help you with" field, such as " Technical issues and bugs ". The deadlines indicated in Column E are considered for the application of penalties.
|
A |
B |
C |
D |
E |
F |
G |
|
Ticket Severity |
1st answer |
Prod Update |
Time (if update is required) |
Time (if the publication is not necessary) |
Description |
Criterion |
|
Critical (level 5) |
30 min (24x7) |
the push of the solution must be immediate ( "Hot Fix") |
4 hours |
Unavailability |
Total unavailability of the application and critical services: login, discounts, make a quote. They are problems without a viable contour with the following impacts: financial, day-to-day operation, image or affecting more than 70% of users. |
|
|
Urgent (level 4) |
30 min (business) |
8 working hours |
Partial unavailability / Bugs with severe impact |
Partial application unavailability and severe impact of critical services: login, discounts, make a quote. They are problems without a viable contour with the following impacts: financial, day-to-day operation, image or affecting large numbers of users. |
||
|
High (level 3) |
30 min (business hours) |
Solution publishing can follow the sprint schedule ("Planned Fix"), but in the current sprint. |
Up to 6 weeks |
1 week |
Partially affected bugs Partial |
impact on end customers or impact on some of the functionality that can cope with the problem. |
|
Normal (level 2) |
30 min (business hours) |
Solution publishing can follow the calendar of sprints ("Planned Fix"), but in the next sprint. |
Up to 8 weeks |
2 weeks |
bugs |
SpotSpot impact on one or a few users or some non-essential functionality. |
|
Low (level 1) |
30 min (business hours) |
Not Applicable |
Not Applicable |
8 weeks |
Other requests |
No impact |
4.4 Incidents of critical severity. In cases of Critical Severity Incidents, the Baseline must contact the applicant within 30 (thirty) minutes, and resolve the incident within 4 hours, 24/7, 365 days a year. Any failure related to this commitment must be evaluated and classified according to the components of the Baseline Solution Component List, according to the table in item 3.2.
4.1.1 Components not included in the Baseline Solution Components List, according to the table in item 3.2. If an unavailability is caused by a component that on the date of signature of the Agreement is not on the List of Components of the Baseline Solution, according to the table in item 3.2 above, Customer agrees to open a Ticket with a high severity level (3 ), for the inclusion of the monitoring of this component in said table and definition of its weight of unavailability as of the closing of that Ticket. In the event that the Parties can not agree on the extent of unavailability, the matter shall be settled by negotiation between the Chairman of Baseline and the manager responsible for the Electronic Channels Area of Customer.
4.5 Failure to meet the SLA goal of Ticket Resolution. If the Service SLA is below the Service SLA Goal in a given month, the Baseline will be subject to the penalties set forth in Clause 5, without prejudice to any others provided for in the Contract.
5. PENALTIES
5.1 Basis for calculation of penalties. The penalties mentioned in Clauses 5.2 and 5.3. may be cumulative in the same month, but can not be transferred to any other month and have a "Cap" value mentioned in clause 5.4.
5.2 Penalty for non-compliance with Availability SLA. In SLA case of noncompliance availability in a given month, the baseline will be subject to financial penalties by way of punitive fines and noncumulative compensatory, to be calculated based on sales percentage generated based on the Contract in accordance with the table below:
|
Availability (%) |
||
|
Range |
From - To |
Penalty |
|
1 |
100% - 99% |
0% |
|
2 |
98.9% - 97.4% |
5% |
|
3 |
97.3% - 95.8% |
10% |
|
4 |
95.7% - 94 , 2% |
15% |
|
5 |
94.1% - 0% |
25% |
5.2.1 Procedure for applying the penalty for breach of Availability SLA. For purposes of determining the possible penalty for non-compliance with the Availability SLA, the Parties shall observe the rules and procedures set forth below.
5.2.1.1 Submission of the Report. Subject to Clause 2.8, Baseline undertakes to provide Customer with a Report to Customer if a failure is suspected, within 5 business days, which report shall indicate the Availability SLA as measured by the Baseline for the month immediately above, detailing the Unavailability Time of the components according to the table of clause 3.2 above and the Unavailability Time caused by critical severity incidents.
5.2.1.2 Review of the Report. Upon receipt of the Report, Customer may validate or contest said Report within 30 (thirty) days.
5.2.1.3 Determination of possible penalty. Once the Availability SLA is determined, the Parties shall verify that the minimum percentage of availability has been met. If the minimum percentage of availability has not been reached, the provisions in the table indicated in Clause 5.2 will be applied.
5.2.1.4 Tickets considered for the application of the penalties provided in 5.2. The Tickets considered for the application of the penalties provided in 5.2 above may also be opened by Customer and shall be: (i) classified in the Baseline’s official support system Electronic Platform in the "Environment" field as "Production"; (ii) related to the availability, that is, classified in the Baseline’s official support system Electronic Platform, in the "What can we help you with" field, such as "Urgent - Call Sysadm / System Outage". If Baseline systems do not automatically detect any unavailability, Customer may open a Ticket to advise Baseline of this unavailability and the time count for the purposes of calculating penalty of clause 5.2. starts when the Ticket is opened. Customer, upon the opening of the Ticket, shall inform the affected services so that Baseline can correlate with the corresponding component (s), as provided in the table in clause 3.2. above.
5.2.1.5 Penalty application. Once the amount of the penalty has been determined, according to the table indicated in Clause 5.2, the fine calculated may be deducted from the variable remuneration due to the Baseline but only with prior written consent of the Baseline and in compliance with the provisions of Article 368 et seq. Of the Civil Code.
5.3 Penalty for failure to comply with the Service SLA. In the event that the SLA Service is below the goal SLA Service in a given month, the baseline will be subject to financial penalties by way of punitive fines and noncompensatory cumulative to be calculated based on sales percentage generated based on the Agreement according to the table below: Service
|
SLA (%) |
|||
|
Range |
From |
To |
Penalty (%) |
|
1 |
100% |
90% |
0% |
|
2 |
89.9% |
80% |
5% |
|
3 |
79.9% |
70% |
10% |
|
4 |
69.9% |
60% |
15% |
|
5 |
59.9% |
0% |
20% |
5.3.1 Tickets considered for the application of the penalties provided in 5.3. The Tickets considered for the application of the penalties provided in 5.3, above, will be exclusively (i) Tickets related to production, classified in the Baseline’s official support system Electronic Platform in the field "Environment" as "Production"; (ii) Incident related Tickets, classified in the Baseline’s official support system Electronic Platform in the "What can we help you with" field as "Technical issues and bugs".
5.3.2 Procedure for applying the penalty for noncompliance with the SLA Goal of Ticket Resolution. For purposes of determining the possible penalty for noncompliance with the SLA Target for Service, the Parties shall observe the rules and procedures set forth below.
5.3.2.1 Submission of the Report. Subject to the provisions of Clause 2.8, Baseline undertakes to send the Report to Customer within 5 business days , which report shall state the Service SLA measured by Baseline for the month immediately previous.
5.3.2.2 Review of the Report. Upon receipt of the Report, Customer may validate or contest said Report within 30 (thirty) days.
5.3.2.3 Determination of possible penalty. Once the Service SLA is determined, the Parties shall verify that the Service SLA Goal has been met. In case the Ticket Resolution SLA Goal has not been reached, the respective penalty will be applied. In order to verify whether or not the Service SLA goal is met, the total number of incidents closed in the immediately preceding month shall be taken into account, taking into account the service deadlines indicated in the table in clause 4.3.
5.3.2.4 Penalty application. Once the amount of the penalty has been determined, according to the table indicated in Clause 5.3, the assessed fine may be deducted from the variable remuneration due to the Baseline but only with prior written consent of the Baseline and observing the provisions of article 368 and following of the Civil Code .
5.4 Limit value charged as penalty. The penalties calculated each month under 5.2 and 5.3 can not be greater than 50% of the invoice amount for that same month and no penalty can be transferred to another month ("Cap").
5.5 Limit of noncompliance of the Service SLA (limit of Unresolved Incidents). If there are more than 20 (twenty) Critical, urgent, high and / or normal unforeseen cases (open) for a period exceeding 8 (eight) weeks, Customer may immediately terminate the Agreement without any fine or penalty, after thirty (30) days' prior notice.
5.6 Cumulativeness of the penalties for not achieving the SLA Availability Target and the SLA Target of Ticket Resolution. The penalties for not meeting the Availability SLA Target and the Service SLA Target, provided for in Clauses 5.2 and 5.3, respectively, are cumulative.
5.7 Grace Period. The Parties agree that only the first sixty (60) days after the commercial launch of the application will incur no penalties as outlined in 5.2, 5.3 and 5.5 for the Baseline, as the period considered reasonable by the Parties for necessary adjustments.
6. PERIOD OF VALIDITY
6.1 Term of Effect. This Service Level Agreement will remain in effect as long as the Agreement is in force, subject to the termination and termination assumptions set forth in the Agreement, as well as any extensions.
6.2 Baseline Services upon termination of the Agreement. In the event of termination of the Contract Term, for any reason, Baseline shall continue to provide the support and maintenance services provided for in this Service Level Agreement for at least the notice period, in the event of termination unmotivated, or , in the event of termination caused by Baseline, during the term established in the Agreement for the provision of Baseline Services in the Resolution.
7. GENERAL PROVISIONS7.1 Obligation of Cooperation. Customer undertakes, by itself and its Affiliates, to cooperate with Baseline to reproduce any incidents and errors with the purpose of conducting diagnostic activities and to solve problems and incidents related to the operation of the Application.
7.2 Conflict. In the event of a conflict between what is provided in this Service Level Agreement and what is provided in the Contract, what is provided in the Contract shall prevail for all purposes and effects.
7.3 Review. Baseline undertakes to review, together with Customer, all the parameters and metrics of this Service Level Agreement, in order to adapt its services to Customer's expectations.