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 No. 2 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.
• 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.
• 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).
• 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.
• 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.
• Service Center – the Supplier’s business unit responsible for providing support and maintenance services under this SLA.
• 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.
• Submitting a Request – the act of delivering a Request from the Customer to the Supplier via the agreed communication channels.
• Registered 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.
• 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.
• Open Request – a Request for which processing has started and which has not yet been completed and closed in accordance with this SLA.
• 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 analyse and resolve a Request.
• 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.
• Temporary Solution / Workaround – 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.
• 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).
• Completed 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.
• 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.
• 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 agreed scope of minor changes.
• 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 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.
• Resolution Time – the time from registration of an Incident-type Request until provision of a permanent solution implemented in the Production environment, excluding SLA Timing Exclusions.
• Misuse of Software by the Customer – 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.
• 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.
• 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.
• 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 normalise expected values.
• 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).
• Expected Errors / Expected Error – diagnostic errors or rejections that are a normal consequence of business logic (for example, call rejection due to insufficient balance, tariff restrictions, or other expected and documented reasons).
• Percentage of Unexpected Errors (% 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.
• SSH – Secure Shell, a network protocol for secure remote login and tunnelling (for example, to transfer files).
• SCP – Secure Copy Protocol, a Linux utility for securely copying files between hosts over SSH.
• 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.

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 (for example, GUI issues, client tools), the Customer shall provide the Supplier with:
• 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 provided to the Supplier under this SLA:

• shall be controlled and logged by the Customer in accordance with the Customer’s internal security policies; and
• shall be limited to the minimum level required 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 (for example, 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 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 by e-mail, the sender’s e-mail address must belong to one of the authorised representatives of the Customer as defined under the Master Agreement or other 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 is caused by malfunction of software or components not falling 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 are treated as 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.
• If new issues arise that are not directly related to the original Request, they are 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 No. 2:

 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

1. Incidents of Priority 3 and 4:

• The Supplier's man-hours to eliminate incidents of priorities 3 and 4 are accumulated on an accrual basis within one scheduled release.
• The list of incidents included in the release cannot be changed by the Customer once agreed.
• Unused incident hours within a release do not carry over to the next release.

1. 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.

1. 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.

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.

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 approval to install an update or hotfix.
• Waiting for Customer confirmation of request closure.

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 processing is conducted in 2-week sprints. The agreed capacity per sprint is capped at 60 man-hours for scheduled Requests, with a reserve of 20 man-hours for unforeseen tasks arising during the sprint.
• 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 (Priority 1 & 2):
• 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 (Priority 3 & 4):
• 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 3 & 4 Incidents)

• Accrual: Man-hours for resolving Priority 3 and 4 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 3 and 4 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 a delay in the execution of Critical Requests (Requests of priorities 1 and 2), the Customer may escalate the issue, the Customer reserves the right to escalate the issue in accordance with the table below of responsible persons on the part of the Supplier:

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

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.