Service Level Agreement :

This Service Level Agreement ("SLA") provides paid users ("User", "you") of EICRA SOFT LIMITED Service with certain rights and remedies regarding the service levels of EICRA SOFT LIMITED. Users of the EICRA SOFT LIMITED Service are subject to the EICRA SOFT LIMITED Client License and the EICRA SOFT LIMITED Service Terms of Use.

This SLA does not apply to Users of the EICRA SOFT LIMITED Client that are not paid users of the EICRA SOFT LIMITED Service.

This SLA applies only to EICRA SOFT LIMITED. It does not apply to any other services or offerings.

  1. Technical support requests are classified in several service levels (SLA – Service Level Agreement). The service levels differ in response time and other parameters; and depending on technology area and/or operating level agreement with third party vendors.
  2. Technical support requests are processed on a first-come, first-served basis. Maximum response period is defined by the defined service (SLA) level. Priority 1 and 2 requests that require immediate response or direct help of tech support specialists may be processed out of turn. The problem-solving period depends on the request urgency level, problem complexity and the potential need to hand the request over to the development department.
  3. The technical support service cannot guarantee the fixed problem-solving period because there are a number of influencing factors:
    • Client's timely replies
    • Response time of a third party company
    • The need to prepare and release a software update, etc.
  4. The response period depends on the current technical support service workload and can take less time than stated in the regulations. Sometimes, a problem can be solved immediately upon the receipt of a request or additional information from a client or user. The response of technical support specialists should never exceed the maximum response time defined for a given support level. In this or a similar situation, making a phone call to the sales department or creating posts in the forum has no practical consequence because it will not accelerate the problem-solving process. The maximum response times are defined below.

Hours of Coverage and Escalation Procedures

Service Requests
The Helpdesk is the initial contact for all service related requests.

The hours during business sessions are:
Saturday-Thursday: 9AM - 6 PM (GMT +6)

Service will be prioritized on the following scale.

1. SLA Levels

Level of

Description of Severity Response
of the day
in a Week
An issue takes application down, security issues or major malfunction resulting in majority of users unable to perform their normal functions. 8 Hours 08 hours in a day 05 Days in a Week
Priority Critical loss of application functionality or performance resulting in high number of users unable to perform their normal functions. 12 Hours 08 hours in a day 05 Days in a Week
High Moderate loss of application functionality or performance resulting in multiple users impacted in their normal functions. 24 Hours 08 hours in a day 05 Days in a Week
Normal Minor loss of application functionality, improvement, documentation or product feature question. 36 - 48 Hours 08 hours in a day 05 Days in a Week

Definition of priority levels in support tickets

Criticalthe problem results in extremely serious interruptions to a production system. It has affected, or could affect, the entire user community. Tasks that should be executed immediately cannot be executed because of a complete crash of the system or interruptions in main functions of the production system. Data integrity is compromised and the service request requires immediate processing as the issue can result in financial losses.

Priority — !important It does not prevent operation of a production system, or there could be minor degradation in performance. The error is attributed to malfunctioning or incorrect behavior of the software.

Highthe problem will or may result interruptions if not address (no business impact). The issue is currently not causing problem but may result service interruption if not address soon or a security issue raised that need to fixed soon. In summary , any point need to be address soon in order to avoid future downtime or caused service interruptions.

Normalthe problem results in minimal or no interruptions to normal operations (no business impact). The issue consists of "how to" questions including issues related to APIs and integration, installation and configuration inquiries, enhancement requests, or documentation questions.

2. Chat Support SLA

  1. Purpose and Priority (Chat)
    • Eicra chat is intended to provide individuals with an online, interactive method to request and receive basic information and troubleshooting assistance. Support is provided on a first-come, first-served basis.
    • Incoming chat requests to Eicra support will be answered on a first-come first-serve basis and may be queued for response as technicians become available.
  2. Individuals Supported (Chat)
    • Eicra chat is intended for partners, prospects and trials of Eicra who have an active subscription, trial or demo license.
  3. Scope of Service (Chat)
    • Eicra chat is intended to offer quick assistance on simple questions. Technicians will attempt to address any issue that an individual might call Eicra Support for or open a normal ticket via email/portal.
    • Eicra chat can provide a status on an existing ticket. However, if that ticket needs further work that is outside the scope of the chat session, or requires referral to another department, the request will be transferred to dispatch.
    • Individuals asking complex questions that will require in-depth troubleshooting, configuration or instruction may be transferred to an engineer with availability for the subject matter or transferred to dispatch for scheduling purposes. High priority issues such as server downs or critical business-affecting conditions will be transferred to dispatch for proper handling.
    • Chat sessions are intended for Eicra to offer quick assistance and may not be the most efficient method to handle complex troubleshooting situations. If such a complicated session lasts longer than 15 minutes, we may refer or transfer the request for service as outlined above.
    • If a chat session goes 10 minutes or longer without a response from partner, we reserve the right to end the chat in order to provide prompt service to all waiting chat sessions.
    • Chat availability is 12 hours in a day for 5 days in a week. ; we do reserve the right to triage chat service based on the need to meet complex or server down issues. If chat service is unavailable, please call or email via normal methods for contacting support.

3. Technical Support Scope

  1. The following problems are outside of the technical support scope:
    • Training
    • Consulting
    • Implementation
    • Custom Solutions
    • Development
    • Product Management
  2. Product Updates & Maintenance
    The following topics are within the scope of technical support:
    • Investigation and elimination of license key problems occurring during software update
    • Detection and elimination of problems that might be caused by an incorrect product update installation process The following topics are outside of the technical support scope:
    • Managed upgrades or migrations
  3. Eicra Soft Products Errors
    • Errors caused by the that are unrelated to environmental, hardware, or OS errors The following problems are outside of the technical support scope:
    • Environmental, Hardware or OS errors not caused by
  4. Development Questions The following problems are within the technical support scope:
    • Explanation of general principles of integration of Eicra Soft Ltd products in the design using the software documentation or training materials The following problems are outside of the technical support scope:
    • Consultation on general principles of programming
    • Implementation of custom, user defined logical operations and algorithms
    • Diagnosis of any 3rd party software code or any of its components
    • Development of custom components or scripts and software modules
    • Modification of code of the existing system modules or components to adapt them for specific business tasks
  5. Miscellaneous Questions
    The following problems are within the scope of technical support:
    • Explanation of functions of the system modules not included in the documentation
    • Software licensing policy explanation
    • Eicra Soft Ltd built-in system security enhancement questions
      The following problems are not within the technical support scope:
    • Requests for development of new product features or product improvement requests.
    • Requests for additional product documentation.
    • Requests for additional training, walk-throughs, video issues, or university questions.

4. Integration - 3rd Party Guidelines

  1. SLAs are excluded from the support scope of 3rd party vendors. Response times vary depending on vendor.
    • Level 1 Support Definition (In Scope) L1 Support for 3rd Party Products is defined as:
      • Failed Installation
      • Error Messages
      • General Usage (limited to documented procedures)
      • Standard/Known Issues
      • Non-Critical or Production Level Outages are not included
      • Support personnel will troubleshoot for a maximum of 30 minutes for any issue
    • Level 1 Support Definition (Out of Scope)
      All other responsibilities not listed above are considered out of scope and will be escalated on client behalf the Vendor.
    • Requirements
      1. will provide L1 Support based solely on pre-provided documentation in the form of knowledge base articles, product documentation and known issues.
      2. will provide L1 Support in the form of reviewing and working through documented issues with the client until all documented troubleshooting data has been exhausted.
      3. will escalate any undocumented, incorrectly documented or confirmed issue based that is outside of any documentation.
        Issue - "When I install, I get this error message"

        Actions Taken - Walk through steps and verify documented procedures have been taken properly. If issue has been properly followed per documentation and issue still is present, the item will be escalated directly to the vendor.

      4. will submit the issue on behalf of the client, with the full expectation that the Vendor will then take over the issue and effectively handle client requests.
      5. will work through documented processes only, and will not perform actions on the clients' production environment at any time.
        Example Bare Metal Restores - We will advise and walk through documented process, we will not perform the process for the client.

        Antivirus - We will advise walk through documented process, but will not perform any analysis or actions to remove viruses/malware, etc.

      6. will work to broker any client issues on behalf of the partner.
      7. will work to analyze and define the core issue to the best of their abilities based on pre-provided documentation and training.
      8. reserves the right to forward specific issues directly to the vendor for resolution.
      9. Support personnel will not be expected to remain on any brokered call upon LT being eliminated from the root cause of the issue.
      10. Support personnel will not be expected to remain on any brokered call based on incorrect documentation or items not pertaining to integration with Vendor Product.
      11. Support personnel will not be responsible for follow up communications post-escalation regarding initial issue.
      12. will not advise Partner to contact Partner directly at any time unless issue or purchase are entirely outside of the above guidelines or purchased directly from Vendor.
      13. Upon escalation to the Vendor will no longer be responsible for the resolution past that point.

5. Technical Support Procedure

  1. Contacting Support
    The technical support procedure is initiated by a technical support request posted in a technical support ticket. A technical support ticket can be submitted by a Software partner, Software Service+ partner or commercial client in a number of ways:
  2. Ticket Expectations
    Each technical support ticket should include the following information in order to reduce the resolution time:
    • The problem description and the step-by-step procedure to reproduce the error (if possible)
    • Component, Location or Technology Area only.
    • The technical support specialists may inquire about information concerning the server software configuration and versions, and the configuration of a client's software
    • All problems should be described using commonly accepted software or hardware terminology
    • Each time a client submits a technical support ticket or sends a message that is further accepted and regarded by the Software technical support staff as a technical support ticket, the system automatically generates and sends a notification stating that the issue will be taken care of according to the service level assigned
    • After the Software technical support staff has received a ticket, the client receives a notification, which includes the technical support ticket information with a unique service ticket ID. If technical support is done via email, partners must preserve the ticket ID in the e-mail message subject field during the whole period of correspondence with the Software technical support staff. The forthcoming messages are appended to the initial message automatically. Partners can view the full correspondence in the technical support section at the portal.
    • When creating a ticket or sending a support request via e-mail, partners can include screenshots and other images that can help to identify and resolve the problem. Screenshots are to be created in PNG, GIF, JPG formats
    • Answers to the common FAQs may be given in the form of web links to corresponding pages of the online documentation, documentation download page, Software forum topics or the FAQ section answers.
  3. Reasons for Ticket Delays
    There are a number of circumstances that can delay or even abort the problem solving process:
    • Lack of information required to resolve the problem
    • A problem cannot be reproduced using a similar hardware configuration or a client's website cannot be accessed using the authorization information provided in the technical support ticket
    • The problem requires custom improvements of Software products that are currently being developed or not planned to be included into a later product release at all
    • Improper use of Software products, exceeding of the allowed number of software installations, or general violation of terms and conditions of Software EULA (End User License Agreement) and/or Software SLA (Service Level Agreement)
    • Use of unlicensed copies of Software products
    • The question is beyond the Software technical support service scope
    • Incorrect, incomplete or misleading information given by the client
  4. Bug Fix Policy
    Cumulative patch release (bug fixes) come out more frequently than major releases (2 major release a year in Q2 and Q4 generally) and attempt to target the most critical bugs affecting our customers. The notation for a maintenance release is the last set of numbers right of the (.) decimal point (i.e. v51.155) via Help-About.

    If a bug is critical (production application down or major malfunction causing business revenue loss or high numbers of staff unable to perform their normal functions), then it will generally be fixed in the next cumulative patch release provided that:
    • The fix is technically feasible (i.e., it doesn't require a major architectural change and a root cause has been identified).
    • It does not impact the quality or integrity of a product.
      For non-critical bugs, Development prioritizes the non-critical bugs according to these factors:
    • How many of our supported configurations are affected by the problem.
    • Whether there is an effective workaround or patch.
    • How difficult the issue is to fix.
    • Whether many bugs in one area can be fixed at one time.
  5. Patch Policy will only provide software patches in extremely unusual circumstances. If a problem has been fixed in a newer release of the product, will request that you upgrade your instance to fix the issue. If it is deemed necessary to provide a patch, a patch will be provided for the current release only. Patches are considered cumulative, so they may contain a combination of other fixes as part of a single patch release and not just associated with one contained issue.
    Patches are issued under the following conditions:
    • The bug is critical (production application down or major malfunction causing business revenue loss or high numbers of staff unable to perform their normal functions)
    • It does not impact the quality or integrity of a product.
      For non-critical bugs, Development prioritizes the non-critical bugs according to these factors:
    • A patch is technically feasible (i.e., it doesn't require a major architectural change and a root cause has been identified)
    • A patch is technically feasible (i.e., it doesn't require a major architectural change and a root cause has been identified)
    • The issue is a security issue does not provide patches for non-critical bugs.
    Partners should monitor the Known Issues Tracker in order to view when an issue has been slated for a patch release.
  6. The Technical Support Quality Rating
    • Software, LLC places high emphasis on the technical support service quality and provides the highest possible support service for all categories of users
    • After resolving a problem, we kindly ask you to estimate the service quality for each incident by responding to the survey for service ticket ID
    • If you suppose that a ticket has been prematurely closed, you can re-open the ticket and define your question more exactly within seven days of closure. After seven days, all requests are considered new requests

6. Rules of Engagement

  1. Audience Service Delivery Teams
    • Customer Service
    • Support
    • Consulting
    • Implementation
    • Training
    • Dispatch
      Partners, clients, customers, and channel partners
  2. Definition
    This is a mutually beneficial two way cooperative effort with service delivery and the partner, client, customers and channel partners.
    There is no "us" and "them", there is only "we".
    Both parties should agree on standards of conduct and diplomacy during the times we interact.
  3. Standards
    • Treat each other with respect and courtesy.
    • Hostile communications or insulting behavior will not be acceptable.
    • We must remain professional at all times.
    • Each party should keep the engagement to a high degree of professionalism at all times.
    • Profane language or rude comments will not be tolerated.
    • Honesty is paramount.
    • Mindful of appointment times and/or scheduled engagements.
    • Proper notification to either party as prompt as possible of the need to cancel or reschedule a meeting/engagement.

6. SLA Exclusions

6.1 This SLA and any applicable Service Levels do not apply to any performance or availability issues:
  1. Due to factors outside Company’s reasonable control;
  2. That resulted from Customer’s or third party hardware or software;
  3. That resulted from actions or inactions of Customer or third parties;
  4. Caused by Customer’s use of the Service after Company advised Customer to modify its use of the Service, if Customer did not modify its use as advised;
  5. During beta and trial Service (as determined by Company); Or
  6. Attributable to the acts or omissions of Customer or Customer’s employees, agents, contractors, or vendors, or anyone gaining access to Company’s Service by means of Customer’s Authorized Users’ accounts or equipment.
  7. Attacks by viruses or hackers, including Distributed Denial of Service (dDoS) attacks against Eicra's network or license server.
  8. Scheduled maintenance and system upgrades, or emergency maintenance;.
  9. Client's acts or omissions (or acts or omissions of others engaged or authorised by the Client), including, without limitation, custom scripting or coding (e.g., CGI, Perl, HTML, PHP etc), any negligence, willful misconduct, or use of the Services in breach of Eicra's Terms and Conditions;.
  10. Outages elsewhere on the Internet that hinder access to your account. ReZolve is not responsible for browser or DNS caching that may make your site.
    appear inaccessible when others can still access it. Eicra will guarantee only those areas considered under the control of Eicra, eicra's servers and Eicra's routers.