Service Level Agreement (SLA)

1. Relationship to the Master Agreement and Scope

1.1. This SLA forms part of, and is subject to, the Master Agreement between the Supplier and the Customer.

1.2. Capitalized terms used but not defined in this SLA have the meanings given to them in the Master Agreement and its annexes, schedules and order forms.

1.3. This SLA applies to the support and maintenance services for the Avante application software (the “Application Software” or “Software”) provided under Program as specified in the applicable order form, commercial schedule or similar document under the Master Agreement.

2. Definitions

In this SLA, unless the context otherwise requires, the following terms have the meanings set out below:

• Application Software / Software – the Avante software platform and related modules licensed to the Customer and forming part of the overall solution (system) supported by the Supplier, as described in the applicable order form or technical schedule under the Master Agreement.
• Average Data – historical data for a specific process (for example, number of SMS, calls, activations per weekday) calculated over an agreed historical period (for example, the previous month) and used to identify abnormal deviations.
• Closed Request – a Request marked as closed in the Supplier’s help desk system after:
• written confirmation from the Customer, or
• expiration of a reasonable period after provision of a solution, during which the Customer has not raised justified objections.
• Complete Request – a Request for which the Supplier has provided a temporary or permanent solution and reasonably considers that the Request has been fulfilled, but the Customer has not yet confirmed completion.
• Customer Request / Request – any request, incident report, query or change request submitted by or on behalf of the Customer to the Supplier under this SLA.
• Delivering a Response – sending the Response from the Supplier to the Customer via any of the agreed communication channels (help desk portal, e-mail, phone, or other agreed means).
• Help Desk System – the Supplier’s system for registering, tracking and managing Requests. If the help desk system is temporarily unavailable, Requests may be submitted by e-mail or phone, but registration in the help desk system remains the formal record for SLA purposes.
• Open Request – a Request for which processing has started and which has not yet been completed and closed in accordance with this SLA.
• Processing a Request – the handling of a Request by the Supplier, including analysis, determination of the cause, classification, assignment of responsible specialist(s) and implementation of a solution or workaround.
• Refinement / Minor Revision – a change to the functionality of the System or Application Software that does not contradict the technical documentation and agreed design documents and is within the scope of minor changes.
• Release – a life cycle of development and delivery of a new version of the Application Software that includes a set of bug fixes, improvements and new functionality.
• Remote Access – permanent or time-limited remote access to the Customer’s environments (servers and, where relevant, workstations) provided to the Supplier’s specialists via secure channels over the Internet (for example, SSH, VPN, remote desktop tools).
• Request for Additional Information – a written notification from the Supplier to the Customer requesting clarifications, logs, screenshots, steps to reproduce, access details or other information necessary to analyze and resolve a Request.
• Request Execution Time – the time from registration of the Request in the help desk system until provision of a temporary or permanent solution, excluding periods that are explicitly stated as SLA Timing Exclusions.
• Response to Request / Response – the first reaction of the Supplier to a Request (for example, confirmation of registration, clarification questions, provision of a workaround or a permanent solution), delivered to the Customer within the applicable response time.
• SCP – Secure Copy Protocol, a Linux utility for securely copying files between hosts over SSH.
• Service Center – the Supplier’s business unit responsible for providing support and maintenance services under this SLA.
• System – the combined software and hardware solution resulting from implementation of the Software in the configuration agreed between the Parties and described in the technical and/or commercial documentation referenced in the Master Agreement (for example, in a scope of work or order form).
• System Administration – activities aimed at maintaining operability of the System (for example, configuring environments, deploying updates, backing up data, and performing scheduled maintenance), as allocated between the Parties in this SLA and in the Master Agreement.
• Submitting a Request – the act of delivering a Request from the Customer to the Supplier via the agreed communication channels.
• Software Implementation – installation of the Software in the Customer’s environment, configuration of the Software and its components, and adjustment of the Software to implement the Customer’s business processes in accordance with the agreed implementation scope.
• Software Support – activities performed by the Supplier to eliminate errors in the Application Software, improve its performance and stability, and implement minor functional enhancements as described in this SLA.
• Unexpected Errors / Unexpected Error – errors in automated processes (such as rating, charging, provisioning) that cannot be explained by normal business logic and lead to deviations from expected statistical data, taking into account Average Data and the subscriber base growth rate (for example, an operation is not performed due to missing configuration when it should have been processed).
• % Unexpected Errors – the percentage of unexpected errors in relation to the total number of processed operations for a given process, adjusted for Average Data and subscriber base growth rate.
• Verified Request – a Request that has been recorded in the Supplier’s help desk system, assigned a unique identifier and accepted for handling within the applicable response time.
• Withdrawal of a Request – the act of canceling or retracting a previously submitted Request before it is processed or fulfilled.
• Workaround / Temporary Solution – a preliminary solution that restores or maintains essential functionality while a permanent fix is being prepared. A temporary solution may include reasonable functional limitations that do not prevent provision of essential services.
• Subscriber Base Growth Rate – the ratio of the increase in the subscriber base over a specific period to the average size of the subscriber base for previous periods, used to normalize expected values.
• Technical Schedule – a document attached to the Master Agreement that specifies technical details, scope, and other relevant information related to the project or services.
• Tracking a Request – the process of monitoring the status and progress of a Request throughout its lifecycle in the help desk system.
• Unauthorized Configuration Changes – use of the Software in a manner inconsistent with the documentation or the Master Agreement, including unauthorised configuration changes, unsupported integrations, modification of database structures, or operation outside recommended conditions.

3. Conditions for Support Obligations

3.1. Support Services under this SLA are provided only while the Master Agreement remains in force and the Customer is in good standing with respect to applicable payment and other material obligations.

3.2. To optimize the performance of the Parties under the Master Agreement, the Customer shall ensure that the Software and its up-to-date copies are installed and accessible in environments agreed between the Parties, and shall grant the Supplier the technical access necessary to perform diagnostics and corrective actions, as follows:

• Server environments (Linux/Unix OS).
  Where the Software runs on Linux/Unix operating systems, the Customer shall provide the Supplier with:
• SSH access to the relevant servers; and
• SFTP and/or SCP enabled to allow secure transfer of files (for example, logs, configuration files, deployment artifacts);
  using authentication (password and/or key-based) and privilege levels sufficient to review logs, manage relevant services and deploy updates necessary for Support Services.
• User workstations / client environments.
  When resolving issues related to the operation of user workplaces (e.g., GUI issues, client tools), the Customer shall provide the Supplier with one or both of the following:
• Direct access to the relevant workstation(s), and/or
• Remote desktop access (for example, RDP, TeamViewer or another mutually agreed remote access tool) to the user’s workstation so that the Supplier’s specialists can reproduce and analyze the issue.

3.3. All access granted to the Supplier under this SLA shall be:

• Controlled and logged by the Customer in accordance with the Customer’s internal security policies; and
• Limited to the minimum level necessary for the Supplier to provide Support Services.

3.4. If the Customer does not provide the requested access (or delays its provision), all applicable Response, Request Execution and Resolution times under this SLA shall be extended by a period equal to the delay in granting such access. Such periods are treated as SLA Timing Exclusions.

3.5. The Supplier shall provide services in the volume stipulated by this SLA and the Master Agreement. The Supplier’s scope of responsibility for the System components is further specified in the responsibility allocation matrix (e.g., Application Software support – Supplier; DBMS administration – Customer; OS and hardware – Customer), as may be set out in the Master Agreement or in technical documentation agreed between the Parties.

3.6. Support Requests are accepted only if they are submitted by authorized representatives of the Customer. The list of authorized representatives and their contact details is defined and maintained either under the Master Agreement or in related written agreements between the Parties. Such representatives must have completed appropriate training for their role and access level.

4. Service Provision Procedure

4.1. The Customer may submit Support Requests using the following channels (the next channel is used only if the previous one is unavailable):

1. Creating a ticket in the Supplier’s help desk system (preferred channel).
2. By e-mail to the Supplier’s support address specified in the Master Agreement or support documentation (if the help desk system is unavailable).
3. By phone to the Supplier’s Service Center using the phone numbers specified in the Master Agreement or support documentation (if the above channels are unavailable); such calls are subsequently registered in the help desk system.

4.2. All support contacts are handled through the Service Center. Communication with other employees of the Supplier (for example, via instant messengers or direct e-mail) does not constitute formal submission of a Request for the purposes of this SLA.

4.3. When a Support Request is submitted via e-mail, the sender’s e-mail address must belong to an authorized representative of the Customer as defined under the Master Agreement or another written agreement between the Parties.

4.4. When submitting a Request, the Customer shall provide at least the following information:

• Customer’s legal name.
• Reference to the applicable agreement or order (for example, contract number, order form number).
• Contact person name, phone number and e-mail address.
• Name of the functional module or component requiring support.
• Environment in which the issue was observed (Production, Pre-production, Test, etc.).
• Detailed description of the problem, including steps to reproduce, error messages, screenshots or logs where possible.
• Customer’s initial assessment of priority.

4.5. Each Request is associated with the relevant Program and/or additional options purchased by the Customer under the Master Agreement and is assigned a unique registration number in the help desk system. The Supplier communicates this number to the Customer and uses it in all further communication regarding that Request.

4.6. The Supplier may reasonably change the priority of a Request, acting in good faith and based on the criteria described in section 6 (Request Priority Determination) and section 7 (Time to Provide Solution (SLA Targets)). In such case, the Supplier will notify the Customer in the help desk system and/or by e-mail and provide justification.

4.7. The Customer shall comply with the Supplier’s recommendations and provide requested information and clarifications in a timely manner. The Supplier documents such recommendations and the Customer’s responses in the help desk system.

4.8. If a Request results from a malfunction of software or components not within the Supplier’s responsibility (for example, third-party OS/hardware/network issues), the Customer shall resolve those issues at its own cost. The Supplier may assist on a consulting basis if agreed.

4.9. If the Supplier’s Response, further work or Request completion depends on information, actions or approvals from the Customer (including access, logs, or decisions on maintenance windows), the Supplier shall notify the Customer. Any delays arising from such dependencies will be considered SLA Timing Exclusions.

4.10. Delivery of Response.
Response is delivered by recording updates in the help desk system and/or by sending information to the Customer via e-mail or telephone; other agreed channels may also be used.

4.11. Completed and closed Requests.

• After a solution (temporary or permanent) is provided, the Request is treated as Completed.
• A Request becomes Closed when the Customer confirms closure or five (5) calendar days have elapsed after provision of the solution, during which period the Customer has not raised justified objections or submitted additional information requiring further action. In such case, the Request shall be automatically closed by the Supplier in the help desk system.
• Any new issues that are not directly related to the original Request, or that arise after the Request has been Closed, shall be registered as new Requests.

4.12. A Request initially submitted as an Incident may be reclassified (for example, as a Consultation or Minor Revision) if analysis shows that:

• Cause of the issue is incorrect actions by the Customer.
• Software is operating as designed and the Request reflects a misunderstanding of functionality.
• Incident cannot be reproduced despite reasonable efforts; or
• the Request is in essence a question or change request rather than a fault.

In such cases, further work on the Request is performed as Consultation or Minor Revision and the time spent is accounted accordingly.

5. Program Composition

The following services and parameters are included under Program:

 5.1. General Limitations and Accounting Rules

1. Hours Included: The hours specified in the Program composition table above are the maximum numbers of hours per calendar month included in the Subscription Fee for the relevant types of Requests (consultation and minor revision).
2. Excess Hours: Any time spent by the Supplier in excess of these included hours shall be treated as Additional Services and charged at the rate of USD as set out in the Master Agreement.

5.2. Specific Accounting Rules for Request Types

A. Incidents of Priority Medium (3) and Low (4):

• The Supplier's man-hours to resolve incidents of priorities Medium and Low will be accumulated within single scheduled release.
• The list of incidents included in the release cannot be changed by the Customer once agreed.

B. Consultations:

• The Supplier's man-hours for providing consultations are accumulated on an accrual basis within one calendar month.
• Hours not used within a calendar month for consultations are not carried over to the next month.
• If the included hours are used up for consultations within a month, the Supplier informs the Customer.
• The Customer may request consultations beyond the scope on a paid basis as Additional Services.

C. Minor Revisions (Change Requests):

• The Supplier's man-hours for providing revisions are accumulated on an accrual basis within one calendar month.
• Hours not used within a calendar month for revisions are not carried over to the next month.
• If the included hours are used up, the Supplier informs the Customer.
• If, after evaluating a revision, it is declined by the Customer, the time spent on its evaluation is deducted from the available Consultation hours.

5.3. Notifications and Updates

• Release Notes: In case of official releases, at the request of the Customer, an opportunity is provided to familiarize themselves with the changes included in them.
• Requirements: When preparing new releases, at the request of the Customer, it is possible to get acquainted with the list of requirements for improvements planned.
• Updates: The Customer receives electronic updates related to the Software aimed at eliminating identified bugs and improving performance. The Supplier shall notify the Customer of each update together with accompanying release notes.
• Planned Maintenance Windows (Scheduled Maintenance): The Supplier may carry out planned maintenance of the Application Software (including deployment of patches, security fixes, upgrades and related activities) during a minimum of two (2) and a maximum of four (4) planned maintenance windows per calendar year (each a “Planned Maintenance Window”). The Supplier shall notify the Customer at least seven (7) calendar days in advance, specifying the planned start time, expected duration and expected impact. Where, under the Master Agreement, deployment is performed by the Customer, the Customer shall implement the Supplier’s patches/updates in accordance with the Supplier’s written instructions during the notified Planned Maintenance Window (or within such other timeframe as the Supplier may reasonably specify for security or stability reasons) and shall not unreasonably delay or refuse scheduling of such Planned Maintenance Window. Any unavailability or degradation of the Application Software, and any delay in processing Requests, occurring during a Planned Maintenance Window shall be treated as an SLA Timing Exclusion and shall not be taken into account when assessing compliance with SLA targets or calculating Service Credits (see Sections 7.2 and 10).
• Customer patch compliance (where patching is performed by the Customer): Where, under the Master Agreement, installation/deployment of Updates/Hotfixes is performed by the Customer, the Customer shall implement the Supplier’s Updates/Hotfixes in accordance with the Supplier’s written instructions and within the timeframe specified by the Supplier (including within a notified Planned Maintenance Window, where applicable). The Customer shall not unreasonably delay, refuse or postpone such implementation, in particular where the Update/Hotfix addresses security, stability or data integrity risks.

5.4. Responsibility Areas Separation

6. Request Priority Determination

The priority is determined based on the impact on business processes and the percentage of Unexpected Errors relative to the average baseline.

7. Time to Provide Solution (SLA Targets)

7.1. The following table defines the resolution targets based on Priority and Service Option:

The timelines for delivering custom improvements and additional software settings shall be agreed separately for each Request.

Response Time, Request Execution Time and Resolution Time are measured only during the applicable Support Hours for the respective Priority:

(a) for Incident Requests of Highest and High priority– twenty-four (24) hours a day, seven (7) days a week;

(b) for Incident Requests and Requests of Medium and Low priority– on Business Days from 10:00 am to 07:00 pm (local time of Supplier).

Outside the applicable Support Hours, the SLA clock is stopped.

7.2. SLA Timing Exclusions

The SLA clock pauses when:

• Waiting for the Customer to perform a requested action;
• Waiting for additional information formally requested;
• Waiting for access (where essential to resolve the issue);
• Waiting for Customer to correct 3rd party faults;
• Waiting for Customer approval and/or implementation of an Update or Hotfix (where such approval/implementation is required from the Customer);
• Waiting for Customer confirmation of request closure;
• Any Incident or Request (including recurring incidents) to the extent caused by, or materially contributed to by, the Customer’s failure to timely implement an Update/Hotfix or to follow the Supplier’s documented update instructions (including operation on unsupported versions);
• During any Planned Maintenance Window carried out in accordance with Section 5.3;
• The following items are added to the SLA Timing Exclusions:
• any Incident or Request caused by Misuse of the Software by the Customer, including use contrary to the documentation, the Master Agreement or the Supplier’s written recommendations
• any Incident or Request caused by changes to the System, interfaces, database structures or configurations performed by Customer or third parties not authorized by Supplier, or performed contrary to Supplier’s documented recommendations.
• In respect of such Incidents or Requests, Supplier may, at its discretion, assist Customer on a time-and-materials basis as Additional Services, subject to prior written approval from Customer.

8. Interaction Procedures & Restrictions

8.1. Release Lifecycle and Sprints

• Release Cycle: The Supplier manages the development lifecycle. The standard release cycle duration is 6 calendar months.
• Scope: During the License Term, the Supplier provides basic kernel updates within the number of scheduled releases specified in the Program.
• Sprints: Request planning and execution follow a two-week Sprint model as set out in Section 8.3 (Man-Hour Accounting Rules).
• Ad-Hoc Updates:
• Hotfixes: The Customer may order an ad-hoc update (hotfix) for an installed version. Costs are determined individually based on the issue, solution method, and timing.
• Extraordinary Releases: The Customer may order an Extra Extraordinary Release. Costs are determined individually based on the scope of updates and development timing.

8.2. Incident Analysis and Resolution Logic

Upon receipt of a Request classified as an Incident, the Supplier shall perform an analysis to determine the appropriate resolution path:

1. Critical Incidents (Highest, High):
• Resolution is performed within the SLA targets.
• The Supplier shall provide the number of hotfixes necessary to resolve the incident without limitation.
2. Standard Incidents (Medium, Low):
• The Supplier assesses the feasibility of including the fix in a scheduled Release and notifies the Customer of the target Release.
• Optional Hotfix: The Customer may request an immediate Hotfix for the incident. If requested, this Hotfix deducts one (1) unit from the annual Hotfix allowance included in the Program.
3. Reclassification: The Request shall be reclassified and processed as a Consultation (deducting from Consultation hours) if the analysis confirms that:
• The incident resulted from incorrect actions by the Customer.
• Standard Software operation was misidentified as an incident.
• The incident cannot be reproduced or confirmed; or
• The Request is substantive in a consultation rather than a defect.
4. Fix Effectiveness: If a fix provided in a Release fails to resolve the reported problem, the Supplier shall provide a remedial Hotfix without deducting from the Program's Hotfix allowance (provided the architecture supports a Hotfix for the current version; otherwise, the fix will be included in the subsequent Release).

8.3. Man-Hour Accounting Rules (Priority Medium and Low Incidents)

• Sprint-based planning of Support work
• Support work under this Program is planned and executed in two-week Sprints (“Sprints”). For each Sprint, the Supplier allocates a capacity of up to 80 (eighty) man-hours in total. Within this capacity:
• no more than 60 (sixty) man-hours per Sprint shall be allocated to Scheduled Tasks agreed with the Customer in advance (including configuration changes, minor improvements and other planned work); and
• up to 20 (twenty) man-hours per Sprint shall be reserved for unforeseen Incidents and Service Requests raised during the Sprint.
• Critical Incidents (Priority 1 – Highest) and High priority Incidents (Priority 2 – High) shall be handled in accordance with the SLA targets set out in this document and are not refused or postponed due to Sprint planning. Any man-hours actually spent on such Incidents shall, however, count towards the total included man-hours as set out in this Agreement.
• The Sprint-based planning mechanism does not increase the total number of included man-hours per Release or calendar month; it only determines how such included man-hours are allocated over time.
• Accrual: Man-hours for resolving Priority Medium and Low incidents accrue within a single scheduled release cycle.
• Fixed Scope: Once agreed, the list of incidents included in a release cannot be modified by the Customer.
• No Carry-Over: Unused incident hours within a release cycle are forfeited and do not carry over to the next release.
• Release Cut-off: During the first two weeks of the month preceding a release, the Supplier may accept Priority Medium and Low incidents for the current release up to a limit of 40 man-hours. The Supplier is not obligated to process incidents exceeding this 40-hour limit or those registered in the final two weeks preceding the release but may do so upon reasonable request.

8.4. Consultation Rules

Upon receipt of a Request classified as a Consultation:

• Scope: The Customer may request advice regarding the performance of the Software covered by the Agreement. Time spent on assessment contributes to the total Consultation time.
• Out of Scope: Consultations regarding issues not covered by the Agreement must be agreed upon separately regarding terms and costs.
• Accounting:
• The monthly allowance is specified in the Program Composition table.
• Man-hours accrue within a single calendar month. Previously agreed consultations cannot be swapped or cancelled by the Customer once scheduled.
• Unused hours do not carry over to the next month.
• Overage: If the monthly allowance is exhausted, the Supplier shall notify the Customer. Further consultations may be requested as paid Additional Services.

8.5. Minor Revision (Change Request) Rules

Upon receipt of a Request classified as a Minor Revision (CR):

• The Supplier analyzes the CR and notifies the Customer of the estimated timing and classification (Included/Not Included, Minor/Major).
• Accounting:
• Time spent on estimation/evaluation counts towards the total Revision time.
• Declined CRs: If the Customer elects not to proceed with a revision after evaluation, the time spent on the evaluation is deducted from the available Consultation hours.
• Man-hours accrue within a single calendar month. Agreed revisions cannot be modified by the Customer within the month.
• Unused hours do not carry over to the next month.
• Overage: If the monthly allowance is exhausted, the Supplier shall notify the Customer. Further revisions may be requested as paid Additional Services.

9. Escalation Procedure

In case of delay in processing Critical Requests (Priorities 1 and 2), the Customer may escalate the issue in accordance with the table below:

If it is necessary to obtain additional information when performing critical requests, the Supplier reserves the right to escalate the issue in accordance with the table below of responsible persons on the part of the Customer:

10. Service Credits

Service credits are a form of compensation, usually discounts or free future services, given to customers when a provider fails to meet agreed-upon performance levels (SLAs). Service credit might be applied to the future services, e.g. enhancements and etc.

The Customer reserves the right to claim Service Credits in accordance with the algorithm described in the table below. Service Credits are calculated separately for each priority and may be aggregated with Service Credits related to other priorities. The maximum total amount of Service Credits for any calendar month may not exceed ten (10) per cent of the Subscription Fee payable for that month under the Program in which the breach occurred.

For the purpose of this section, a “successfully processed Request” means a Request for which the Supplier has met the applicable Response Time and Workaround/Resolution targets under this SLA. Requests to which one or more SLA Timing Exclusions apply shall be excluded from the Service Credit calculation (i.e., they shall not be treated as Successful Requests or Non-successful Requests for the purposes of Section 10).

Service Credits – Conditions

(a) Service Credits are granted only if Customer submits a written claim specifying the month, the metric(s) believed to be below threshold and the requested credit, within thirty (30) days from receipt of the SLA report for the relevant month.

(b) Service Credits shall be applied as a credit against future invoices.

(c) If Customer is in material payment default with respect to any undisputed invoice, Service Credits shall not accrue for the period of such default.

(d) Service Credits shall not apply to the extent that the relevant SLA breach or service impact arises from:

(i) a Planned Maintenance Window notified in accordance with this SLA; and/or (ii) the Customer’s failure to approve and/or implement an Update/Hotfix within the timeframe specified by the Supplier (where such approval/implementation is required from the Customer), or failure to follow the Supplier’s documented update instructions.

Service Credits – Exclusive Remedy

Service Credits constitute Customer’s sole and exclusive financial remedy for any failure by Supplier to meet the service levels set out in this SLA, without prejudice to Customer’s right to terminate the Master Agreement or the relevant Order Form in accordance with its terms.