Service Level Agreement for Megaladata Software Support

Last modified: April 2024

1. Definitions

  1. "Megaladata" is a computer program.
  2. "Rightsholder" refers to MEGALADATA LLC, holding exclusive rights to Megaladata.
  3. "Software" means Megaladata, its components, and application solutions developed by the Rightsholder.
  4. "User" is a person or entity acquiring the Software or services for their use and all the individuals (staff members) who are direct users of the Software.
  5. "Support" means assistance to the User with the use of the Software provided under this "Service Level Agreement for Megaladata Software Support" (hereinafter SLA) by the Rightsholder’s department (hereinafter Support Desk).
  6. "User Representative" means an agent authorized by the User to represent the User’s interests in the interaction with the Rightsholder when receiving Support under the SLA. The agent shall be included in the List of User Premises and Authorized Representatives.
  7. "Software Version" is a distribution of the Software that is specified in the License Agreement: The version is indicated by the first two groups of digits, separated with dots, in the name of the Software.
  8. "Software Build" is a modification (update) of the Software Version or its component: It is indicated by the preceding word "build" or by the last two groups of digits separated with dots in the name.
  9. "Workflow" is a sequence of connected data processing components in Megaladata.
  10. "Service Level" means the performance metric(s) set forth in this SLA.
  11. "End-of-life (EOL)" refers to the moment when the Support of the Software Versions under the pre-defined terms is ceased due to the obsolescence of those Versions.
  12. "Normal Software Functioning" is the state of conformity with the functions and parameters specified in the technical documentation of the Software Version (including performance characteristics).
  13. "Metric" is a measurable score used for assessing the performance of the Software under the conditions of Normal Software Functioning.
  14. "Reference Dataset" is a dataset provided along with the Software or used during User acceptance testing of the Software. It is intended for generating the Metrics.
  15. "Insufficient Software Performance" refers to significant (by two or more times) deviation from the Metrics under the same operating conditions of the Software.
  16. "Error" means the impossibility of Normal Software Functioning of the Software installed on the User’s device, which leads to a failure of one or more IT services or configuration items.
  17. "Confirmed Error" is a reproducible Error that can be repeated and demonstrated to the Support Desk in a Software instance of the same version and build as the User’s, using a copy of the User’s database or the Reference Dataset.
  18. "Critical Error" is an Error that makes it impossible for the User to use the Software (due to complete or partial failure of the main functions) or leads to considerable deterioration resulting in Insufficient Software Performance.
  19. "Non-critical Error" is an Error that leads to temporarily acceptable limitations of the Software use or allows for performing the needed Software functions in an alternative way.
  20. "Update" means the necessary Software adjustment to real-life operational conditions: adding, modifying, or deleting some parts that can influence the services.
  21. "Report" is a situation of a User Representative contacting the Support Desk in order to receive the Support services. Types of Reports:
    • "Incident" is a Report in the case of Error, unplanned termination of service, or decline in service quality.
    • "Request" is a query in the conditions of Normal Software Functioning. For example, a request for an Update or additional information on the Software.
  22. "Issue" is a cause of one or more Incidents.
  23. "Critical Report" is a Report resulting from a significant (from the User’s perspective) impediment to the operation of the Software and requiring immediate response.
  24. "Ticket" is a Report registered by the Support Desk, with a unique number assigned.
  25. "Ticket Resolution" refers to the actions taken to eliminate the main cause of an Incident or an Issue or to find a workaround solution.
  26. "Ticket Closure" means assigning the status "Closed" for a Ticket.
  27. "Website" is the information resource of the Rightsholder on the Internet (located at https://megaladata.com/). It serves the following purposes:
    • Enables the User Representatives to work with the information on the Software.
    • Makes it possible to get the Software components.
  28. "User Premises" is the location of the User Representatives, with the related mailing address, contact information, and opening hours (including the time zone) provided.
  29. "Working Hour" is a clock hour within the service time.

2. Handling Reports

  1. This Service Level Agreement (SLA) determines:
    • The means of contact and the language of communication.
    • Days and time of service (hereinafter Work Day, Service Hours).
    • Standard response time of the Support Desk.
    • The legitimate types of Reports (situations) and the ways of handling them at the Support Desk.
    • The number of User Premises and User Representatives.
  2. The Support Desk shall accept Reports only from the authorized User Representatives included in the corresponding list, with their contact details provided. The User Representative shall provide the Support Desk with the information that allows the person to be identified as an authorized User Representative.
  3. The personnel of the Support Desk shall be contacted only as specified in paragraphs 2.1-2.9 of this SLA; any other contact shall not be responded to in line with the Service Level.
  4. The User Representative (the Report submitter) assumes the responsibility for timely and qualified contact with the Support Desk under this SLA. When necessary, the User Representative shall inform other Representatives of the same User about the Report and the related situation or delegate the work with the Report to them, having notified the Support Desk.
  5. The Reports to the Support Desk are registered as Tickets by assigning them a unique number. The Ticket number is communicated to the Report submitter by a Support Desk staff member or via technical means of the Website. The number confirms the registration of the Report. Upon re-contacting the Support Desk, the User Representatives can provide the original Ticket number so that the Support personnel can quickly understand the context of the particular Report. In the process of handling, the Tickets can be merged into one Ticket or linked into a causality chain.
  6. The main stages of handling a Report:
    • Confirmation of the Ticket acceptance by a staff member of the Support Desk — within the specified time from the moment of receiving and registering the Report (creating a Ticket).
    • Notification (repeated interaction) in the process of the Ticket Resolution — within the specified time from the moment of the previous interaction with the Support Desk concerning the Ticket.
    • Fix suggestion — within the specified time from the moment of the Report registration (Ticket creation) or the moment of receiving a User Representative’s message that responds to the previously suggested solution for the Ticket and enables further handling of the Ticket.
  7. The main means of promptly notifying the Report submitter about the process of handling the Ticket by the Support Desk, as well as any Ticket Resolution found, are the email and the Ticket-related information on the Website.
  8. As proper email delivery is not guaranteed, neither for the initial Report nor for the Ticket registration response, in case of sending a Report by email, the User Representative shall also contact the Support Desk by phone to get definite confirmation of the Ticket registration.
  9. The Rightsholder includes the known email addresses of the User Representatives in the permitted correspondence lists of unsolicited email filters (anti-spam tools). The User shall do the same for the email addresses of the Support Desk.
  10. The handling conditions for a Ticket and the terms of Ticket Resolution may change in the process of resolving the Ticket with regard to the newly received information about the Report situation. If the User Representative does not agree with the Ticket handling conditions communicated by the Support Desk, the User Representative shall immediately inform the Support Desk hereof.
  11. The initiator of a Critical Report (as defined in this SLA) can also be notified by the Support Desk via their known phone number.
  12. A message confirming the Ticket acceptance by a Support Desk staff member shall indicate the moment when the search for the Ticket fix starts.
  13. Searching for the solution, the Support Desk may suggest the User Representative the following:
    • To provide additional Report-related information, including a fragment of a Workflow and/or data used in the situation of the Report.
    • To perform by themself the actions necessary for resolving the situation, such as installing and running a special Software Build, changing the Software settings and/or operating conditions, correcting scripts that are not part of the Software, and the like.
  14. The practical implementation of the suggested solution is the responsibility of the User Representatives.
  15. The User Representative shall be responsible for promptly informing other User Representatives about the Ticket status, considering the suggested solution in time, ensuring the fulfillment of all suggested fix actions through the User’s resources, and collecting and providing the additional necessary information in line with the existing rules and regulations of the User. The results of considering and applying the Ticket Resolution shall be communicated to the Support Desk in order to enable finishing the Ticket handling (Ticket Closure) or continuing work with the Ticket on the basis of the presented results.
  16. The waiting time for the User Representatives to respond about considering and implementing the suggested solution shall not be included in the Support Desk Report response time specified in the SLA.
  17. A solution shall be waiting for the confirmation of its successfulness and assessment of its effectiveness by the User Representative not more than 15 (fifteen) calendar days since the Support Desk has suggested the solution. After the indicated period, the Ticket Closure will happen automatically, and the Ticket related to the Report will be deemed resolved.
  18. Upon a repeated Report related to the Ticket that has been closed, a new Ticket shall be created.
  19. In the case when finding an efficient solution within the specified timeframe is impossible, the Support Desk shall suggest a temporary or workaround solution or provide the User with a reasoned explanation of why their Report cannot be resolved.
  20. The User Representatives shall ensure using the most recent of the Software Builds offered by the Rightsholder if the modifications in them are related to the Report fixes suggested.

3. Software Life Cycle

  1. The nature of Support for a Software Version is subject to change depending on the phase of its life cycle and the existence of a valid SLA.
  2. The Rightsholder shall announce the End-of-life (EOL) of a Software Version not less than one (1) year before the EOL date.
  3. The possibility of providing licenses for a Software Version update within the term of the SLA is described in paragraph “License Update” of section “Service Parameters”.
Software Version Life Cycle Phase Support
Preliminary (before the start of sales) Support of the Software Version and all the Updates (Builds)
Commercial (after the start of sales) Support of the Software Version and all the Updates (Builds)
Debugging (if necessary) Support of the Software Version and all the Updates (Builds)
Commercial, the sales are over, EOL date is announced Support of the Software Version and all the Updates (Builds)
Commercial, after the date of EOL (auto-prolongation of Support is over) None

4. Use of Technical Means and Systems

In the event of damage to the electronic license key, it can be replaced by a working equivalent with the same set of licenses if so stipulated by paragraph “Electronic License Key Backup” of section “Service Parameters.” The transportation costs of sending the replacement electronic license key will be borne by the sender.

5. Service Parameters

Main Parameters

Language of communication: English

Means of contact

Email: [email protected]

Website: https://megaladata.com/

Phone: +49 (0)6102 574 386 0

Service Hours

Service Hours: 09:00 to 17:00 Armenia Time (AMT, UTC +4)

Work Days: All days within the term of SLA, except statutory weekends and public holidays of the Republic of Armenia.

Electronic License Key Backup

One-time replacement in case of damage.

License Update

Provision of a new Software Version does not require additional payment.

Number of User Representatives

Six (6) User Representatives.

Response Time

 

Priority level Response time — within the specified number of Working Hours
Confirmation of the Ticket acceptance (1) Repeated interaction in the process of Ticket Resolution (2) Fix Suggestion (3)
Incident (with Megaladata Desktop)
Critical 1 4 24
Non-critical 1 8 40
Incident (with Megaladata Server)
Critical 1 4 16
Non-critical 1 8 40

 

 

 

Severity level Response time — within the specified number of Working Hours
Confirmation of the Ticket acceptance (1) Repeated interaction in the process of Ticket Resolution (2) Fix Suggestion (3)
Incident (with an application solution)
Critical 1 4 24
Non-critical 1 8 40
Request
Critical 8 8 24
Non-critical 8 None 40

 

1. from the moment of receiving and registering a Report (creation of a Ticket).

2. from the moment of the previous response from the Support Desk concerning the Ticket.

3. from the moment of the Report registration (creation of the Ticket) or from the moment of receiving a User Representative’s response (regarding a previously suggested Ticket Resolution) needed for further work on the open Ticket.

 

Types of Reports

Request:

  • Consultation on the preparation for the Software use.
  • Selection of the Software features and components.
  • Consultation on the Software installation and initial setup.
  • Consultation on the Software updates.
  • Consultation on the Software use and maintenance.
  • Consultation on optimizing the Software performance.
  • Recommendations concerning a particular User workflow.
  • Consultation on the Software recovery after misuse.
  • Consultation on the interaction between the Software and the User’s environment.
  • Consultation on selecting/changing the environment parameters.
  • Consultation on the Software recovery after a change or malfunction in the User’s environment.
  • Questions about the Software licensing, changing the combination/number of licenses.
  • Consultation in case of damaging or losing the license medium.
  • Provision of a Software distribution.
  • Explanation of the Software documentation.
  • Explanation of special implementation features regarding the Software functionality.

Incident:

  • An Error occurring during the analyst’s work with the Software.
  • An Error during the viewer’s operation of the Software.
  • An Error of the Software when executing a Workflow.
  • An Error in interaction between the Software and the User’s environment components.
  • An Error in interaction between the Software and databases.
  • An Error during the administrator’s work with the Software.
  • A Software license Error.
  • A Software distribution flaw.
  • Insufficient Software Performance.
  • An Error during installation or updating the Software.
  • Errors or deficiencies in the Software documentation.

List of User Premises and Authorized Representatives

No. Name of User Premises User Premises Address Users at the premises, with their contact details and position Users’ working hours at the premises (with time zone)
1        
2        
3        

Notes:

  1. The list shall include at least two User Representatives who can substitute for one another in case of absence or business.
  2. Examples of possible User Representatives:
  • Head of a department where the Software is used.
  • A leading specialist responsible for the use of the Software.
  • Chief Information Officer (CIO)
  • The staff member responsible for IT support (administration) of the Software.
  • The User’s service desk (group contact).