Partner Technical Support SLA

1. Overview

This Customer Technical Support Service Level Agreement defines the standards and response time parameters for the provision of technical support services to individuals and legal entities holding R7 Partner status.

2. Terms and Definitions

2.1. Agreement Parties and Their Representatives

Partner — an individual or legal entity holding R7 Partner status at any tier under any partner program, with a valid Partner Technical Support Certificate or a corresponding technical support agreement in accordance with the terms set out in this Agreement.

Customer — an individual or legal entity to whom the Partner has supplied R7 software licenses.

Prospective Customer — an individual or legal entity to whom the Partner plans to supply R7 software licenses in connection with a project registered by the Partner.

Partner Authorized Representative — the Partner employee(s) whose full name(s) and email address(es) were provided by the Partner upon activation of the Partner Technical Support Certificate.Partner Authorized Representatives have access to the full service history of all support requests submitted by employees of their organization. The Partner must ensure that at least one Authorized Representative is available to the Service Provider around the clock for the resolution of Emergency priority Incidents. If an Authorized Representative is unreachable for more than 30 minutes when an Incident occurs, the Service Provider’s obligations default to those applicable to low-priority Incidents.

Partner Contact List — the list of Partner employees authorized to submit technical support requests, identified by the Partner’s email address. This list may be defined and/or updated by a Partner Authorized Representative. The list may include no more than 10 contacts, including employees of affiliated legal entities under a centralized support arrangement.

Initiator — the user who initiates a service request on their own behalf. For a Partner, the Initiator must be listed among the Partner’s designated contacts. Requests submitted by other Partner contacts are not registered or processed.

Service Provider — R7 (joint-stock company).

Service Provider’s Support Team — the Service Provider’s technical staff directly engaged in delivering Technical Support services to Partners.

Request Owner — a Service Provider employee responsible for coordinating and overseeing the timely and quality processing of Partner requests by the Service Provider’s Support Team.

Parties — the Partner and the Service Provider collectively.

2.2. Subject of the Agreement

Software — software owned by R7.

Information System (IS) — the equipment and software environment of the Customer to whom the Partner has supplied (or plans to supply) the Software, deployed in accordance with the Software supply specifications and operated in compliance with the Software documentation requirements.

Service Portal — the Service Provider’s information resource used to receive and process support requests for the purpose of delivering Technical Support services.

2.3. Request Categories

Incident — any event that falls outside the normal operation of the Software as defined in the Software documentation (whether for the version currently in use by the Customer and/or the current latest version), which causes or may cause an interruption in Software operation or a degradation in its quality of use.

Consultation Request — questions related to obtaining information about Software functionality, installation, updates, configuration, and administration; questions related to integrating the Software with existing software systems of the Customer or prospective Customer; questions about configuring endpoint devices (printers, display devices, etc.) for use with the Software; questions about Software licensing.

Service Request — requests involving work to be carried out on the Partner’s Customer’s side.

Change Request — requests proposing changes as part of the development of business processes, configurations, reports, or other implemented Software functionality.

2.4. Incident Priorities

Incident priority is determined by the Service Provider’s Technical Support specialists based on the severity criteria described in Table 1 and the information provided in the Initiator’s request.

Incident Priority
Criticality Description
Emergency

The core declared functionality of the software is unavailable, and no workaround exists. The software is completely non-functional, with a critical impact on the Customer. The operational capability of the information system cannot be restored by the Customer even to a limited extent. Incidents classified as Emergency priority include: 

— a defect causing damage to or corruption of the operating system 

— a defect making it impossible to continue using or launching the information system as a whole 

— discovery of RCE, SSTI, or other CRITICAL security vulnerabilities that have become known to third parties (via bug bounty programs, social media, or chats) and pose a risk of private data exposure.

High

The core declared functionality of the software is completely unavailable for some users, or certain important features are non-functional for all users. The software is largely non-operational, with a serious impact on the Customer. The software can still be used for some core functions. Normal operation of the information system cannot be restored by the Customer. Incidents classified as High priority include: 

— a defect that only manifests after a specific sequence of actions, after which continued use of the core declared functionality is significantly impaired

 — the software is partially unavailable; functional buttons and links are non-functional (for non-core declared functionality), images are not displayed, files cannot be opened or saved with no workaround available 

— a defect causing data loss in specific files with no possibility of recovery 

— a software defect leading to an information security breach that poses a risk of private data exposure, not known to third parties (but known internally).

Normal

The operational capability of the information system has decreased significantly, but most core functions remain available. The Customer can use the software by applying workarounds or operating with a reduced feature set. Software and information system defects are not critical to most of the declared functionality and do not seriously impede its use. Incidents classified as Normal priority include: 

— incorrect messages appearing, or expected messages not appearing, as a result of software operation 

— a distorted user interface appearance that hampers the user’s work but still allows the software to be used 

— a defect that occurs infrequently, has no clear reproducible sequence of steps, and does not produce the effects described under Emergency priority defects.

Low

Errors that do not affect operational capability — for example, typos in interface text or system messages, document layout changes that do not prevent the document from being used, performance degradation with large data volumes, and other minor defects.

2.5. Service Time Parameters

Business Day — the period from 9:00 AM to 6:00 PM Moscow time, excluding weekends and public holidays in accordance with the legislation of the Russian Federation.

Business Hour — a clock hour falling within a Business Day.

Working time on a request — the period during which active work is performed on a request, based on the service level specified in the Customer’s Certificate.

Request Submission Time – the moment an email is received at the R7 user support address, an electronic form is submitted via the support portal (in the Technical Support account), or a phone call to the support line is completed reporting an incident, consultation request, service request, or change request.

Request Registration Time – the period within which the request initiator will be notified that their ticket has been registered and assigned a preliminary category.

Response Time – the period within which the service provider will take the request into work and provide a response, or ask for any additional information needed to resolve the issue described in the request. Response Time is measured from the end of the Registration Time. If a request was registered outside of working hours, the Response Time begins at the first minute of the next available working period. Response Time is calculated exclusively within working hours.

Closure Time – the date and time at which a request or incident is assigned the status “Closed.”

3. Service Levels

Appendix A describes the technical support services provided to Partners.

Appendix B describes the time parameters applicable to Partner requests.

4. Request Submission Channels and Conditions

To receive support, a request must be submitted. Requests are accepted around the clock. Available channels and submission hours:

Request Channel
Channel Access
Service Desk in the service provider’s request management system
4.1. Portal and Service Desk Support

The Service Desk allows users to submit service requests and track their status in real time.

4.2. Email Communication

When contacting support by email, the email address used must be listed in the Partner’s Contact List in order to receive service under the active certificate. The Partner’s Contact List must be kept up to date by the Partner’s authorized representatives.

If an email is sent from an address not included in the Partner’s Contact List, the service provider reserves the right to leave the request unprocessed.

Requests sent to any address other than support@r7-office.ru will not be registered.

4.3. Phone Communication

Phone support is an emergency communication channel intended for notifying the Support Team of Emergency and Urgent incidents.

Incident requests by phone are accepted only from the Partner’s designated Contact Persons. When calling, the caller must provide:

  • the company name and technical support certificate number;
  • their full name;
  • a detailed description of the issue.

The service provider reserves the right to place the call on hold and connect the caller with a person from the Partner’s Contact List for additional verification of the request’s legitimacy.

The Service Provider reserves the right to record calls for quality assurance purposes.

5. Service Provider Obligations

5.1. Response Times

Response times for inquiries submitted by the Partner’s designated contacts depend on the type of inquiry and the Partner’s time zone.

Within the applicable response time from receipt of the Partner’s request, the Service Provider sends an email confirmation to the address specified in the request, communicates the assigned ticket number, and takes one of the following actions:

  • provides the outcome of the inquiry review and supplies the requested information (for non-incident inquiries);
  • confirms that a Service Provider engineer has been assigned to resolve the Incident, and communicates the expected resolution or response timeline.

6. Partner Obligations

6.1. Partner Obligations Regarding Operating Conditions

To ensure the quality of services provided under this agreement, where the software is operated on the Partner’s own infrastructure, the Partner agrees to:

  • deploy the software on servers and/or workstations that meet the system requirements specified in the product documentation;
  • maintain the infrastructure supporting the software in accordance with hardware manufacturer requirements;
  • ensure sufficient packet network bandwidth and apply the recommended endpoint device settings.

Where the software is operated on the Customer’s infrastructure, the Partner must monitor the Customer’s compliance with the above requirements and notify the Service Provider of any violations. In such cases, the SLA terms set out in this agreement will not apply.

6.2. Partner Obligations Regarding Incident Resolution

Some Incidents related to software functionality or to the interaction of the software with the Customer’s or Partner’s hardware and other software systems require reproducing the conditions under which the Incident occurred in order to isolate and identify its root cause.

When working with the Service Provider’s support team to resolve an Incident, the Partner must promptly provide all information in its possession that is requested by the support team and necessary for resolution, and must assist the support team in obtaining from the Customer any information needed to reproduce and resolve the Incident.

In the event of an Incident involving the Partner’s IS, the Partner must grant the Service Provider’s Technical Support team access to the IS upon request, if all other diagnostic methods have proven ineffective.

The Service Provider’s Technical Support team may downgrade the priority of an Incident in the following cases:

  • the Partner has not provided access to the test environment (or IS), or has not supplied sufficient data to reproduce the issue within 3 (three) calendar days of a request from a technical support specialist;
  • the recommendations provided by the Service Provider’s Technical Support team allow the software to operate at a performance level sufficient to continue core business operations (confirmed as effective by the request initiator, or automatically after 5 (five) calendar days with no response from the initiator);
  • the submitted request is not related to defects in the declared functionality or specifications of the software.

An Incident’s priority is downgraded automatically when the Partner has not responded to a technical support specialist’s request for information:

  • within 2 (two) business days for a Request with “Emergency” priority;
  • within 3 (three) business days for a Request with “High” priority;
  • within 10 (ten) calendar days for a Request with “Normal” priority.

A Request for which the Partner shows no activity (does not respond in the Service Portal to inquiries from the Contractor’s Technical Support team) will be closed automatically 20 (twenty) calendar days after the Contractor’s last comment.

6.3. Technical Support Limitations

Technical support does not include:

  • resolution of Incidents where the Partner fails to fulfill its obligations to participate in Incident resolution, as defined in the Partner’s Obligations for Incident Resolution section;
  • resolution of Incidents whose conditions cannot be reproduced by either the Partner or the Contractor’s Support team.

Within the scope of Technical Support services, the Contractor’s Support team does not perform:

  • performance and security analysis of hardware-software systems, or provide consultations on such matters;
  • configuration and administration of hardware-software systems, except as explicitly specified in Appendix A;
  • other work not directly related to the operation of the IS and not specified in Appendix A.

The Partner and the Contractor agree to classify situations in which System failures may occur as not constituting an Incident if such failures result from:

  • scheduled IS maintenance agreed upon in advance with the Customer or Partner, or related to software updates at the request of the Customer or Partner, occurring within the agreed maintenance or update window;
  • circumstances that disrupted IS operation caused by the fault of the Customer or Partner;
  • interference by the Customer, Partner, or a third party with hardware or software located on the Customer’s or Partner’s premises that supports the operation of the IS and related components of the Customer’s or Partner’s infrastructure, without prior coordination with the Contractor’s Support team;
  • failure of equipment belonging to the Customer, Partner, or the internet service provider used by the Customer or Partner;
  • IS downtime caused by force majeure circumstances as defined by applicable law.

7. Miscellaneous Provisions

The Contractor reserves the right to amend this Agreement at any time. The current version of the Agreement is available on the official website https://r7-office.ru at https://r7-office.ru/doc/sla_partner. Technical support is provided in accordance with the current version of the Agreement published at the above URL.

The User acknowledges that a request will not be processed if it does not comply with the terms of this Agreement.

The parties may establish alternative technical support service levels by way of separate agreements.

APPENDIX A. Services Provided

Services Provided

Partner Technical
Support Service ¹
1. Incident Resolution
1.1. Resolution of incidents related to software operation ²

✓

1.2. On-site engineer dispatch to the Customer’s or Partner’s premises to resolve incidents with “Critical” and “Urgent” priorities (when remote resolution is not possible) ³

✓

2. Consultations ⁴
2.1. Explanations and consultations on software functionality and capabilities

✓

2.2. Remote access and consultations on installation, configuration, and setup of software deployed within the Customer’s or Partner’s internal corporate network, from computers on an external network

✓

3. Service Request Fulfillment
3.1. Remote installation and configuration of software within the Customer’s or Partner’s internal corporate network, from computers on an external network

✓

3.2. Remote software version updates for software deployed within the Customer’s or Partner’s internal corporate network, from computers on an external network

✓

3.3. On-site software installation, configuration, and version updates performed by a vendor specialist at the Customer’s or Partner’s premises

✓

3.4. Remote access and assistance with configuring the Customer’s or Partner’s peripheral equipment for use with the software

✓

3.5. Consulting on Disaster Recovery plan creation and implementation

✓

3.6. Consulting and execution of an agreed scope of work for migrating the Customer’s or Partner’s information system to new hardware

✓

3.7. Consulting and execution of an agreed scope of work for DBMS administration, backup configuration, metrics collection enablement, and alert configuration

✓

3.8. Organization and execution of software load testing on the Customer’s or Partner’s hardware

✓

3.9. Consulting and execution of an agreed scope of work for software installation and monitoring setup

✓

4. Change Request Processing ⁶
4.1. Notification upon implementation of software changes made on the basis of a registered change request submitted by the Partner ⁷

✓

5. Monitoring and Control
5.1. Access to the Service Portal and automated reports within the Service Portal covering request resolution statistics and quality ⁸

✓

5.2. Weekly summary report on prepaid hours consumed and the projected need to expand the package based on estimated workload (if applicable)

✓

¹ Work requiring remote access to the Customer’s or Partner’s internal corporate network is performed subject to the Customer or Partner (as applicable) providing such remote access from the internet, for example via VPN.

² If the Partner is acting on behalf of and/or in the interests of a customer with an active software update entitlement (active software warranty), incident response times for requests submitted by initiators are described in Annex B. In all other cases, the incident is registered and handled without SLA. If the Partner and the vendor have separately agreed on priority incident registration timeframes, the vendor’s work on such incidents is charged against the prepaid hours of the Partner’s Technical Support Certificate.

³ Work performed between 20:00–22:00 and 06:00–08:00 is billed at a rate of 1.5×; between 22:00 and 06:00 the following day — at 2×; work on weekends — at 2.5×. For the purposes of calculating request registration time and response time, the active working hours window is used.

⁴ Access to the continuously updated Knowledge Base (https://support.r7-office.ru), which contains articles on working with the office suite, training materials, notifications of new software versions, and current installation/configuration/usage documentation, is provided without restriction to all interested parties regardless of whether they hold software licenses or Technical Support certificates.

⁵ If an on-site visit is required outside of Moscow or the Moscow Region, the travel expenses of the service provider’s employee are reimbursed by the Partner.

⁶ Not counted against the hours actually used under the partner certificate.

⁷ Software change requests are registered for the purpose of collecting user feedback on desired software improvements, and are accepted from all interested parties regardless of whether they hold software licenses or Technical Support certificates. Where the Partner and the service provider have agreed on priority software enhancements at the Partner’s request, such enhancements are carried out under separate agreements concluded with the Partner.

⁸ Upon expiration of the Partner Technical Support Certificate, access to the Service Portal is limited to viewing previously submitted requests only.

APPENDIX B. SLA Parameters

SLA Parameters

⁹ Applicable to warranty requests.

¹⁰ All times are provided in the Moscow time zone. Business days are determined in accordance with the Russian Federation production calendar.

¹¹ Work performed between 18:00–22:00 and 06:00–09:00 is billed at a rate of 1.5×; between 22:00 and 06:00 the following day — at 2×; work on weekends — at 2.5×. For the purposes of calculating request registration time and response time, the active window is: 8 hours on business days (09:00–18:00).

¹² Calculated from the moment the request is registered. If the request is registered outside active working hours, the response time countdown begins at the first minute of the next active working hours window. Response time is measured within active working hours only.