Правовая информация
Соглашение об уровне сервиса Платформы gro.now (b2b)
Редакция v.1.0 от 23.10.2025
1. Общие положения
1.1.
Настоящее Соглашение об уровне сервисного обслуживания (SLA) устанавливает показатели качества, доступности и поддержки Платформы gro.now, а также порядок предоставления сервис-кредитов при их нарушении.
1.2. - 1.5.
1.2. SLA является неотъемлемой частью Пользовательского соглашения (b2b) и применяется ко всем Клиентам с активной Подпиской. Термины используются в значениях, определенных в Пользовательском соглашении.
1.3. SLA регулирует:
(i) доступность и стабильность работы Платформы;
(ii) классификацию и обработку инцидентов;
(iii) порядок взаимодействия со службой поддержки;
(iv) условия расчета и предоставления сервис-кредитов.
1.4. SLA не применяется к пробным, тестовым и бета-версиям, дополнительным услугам вне тарифа, а также к сбоям, вызванным действиями Клиента, внешними сервисами или обстоятельствами, не зависящими от Провайдера.
1.5. Провайдер ведет мониторинг состояния Платформы, фиксирует инциденты и публикует отчеты о доступности. В спорных случаях приоритет имеют данные Провайдера, если Клиент не представит достоверные встречные доказательства.
1.3. SLA регулирует:
(i) доступность и стабильность работы Платформы;
(ii) классификацию и обработку инцидентов;
(iii) порядок взаимодействия со службой поддержки;
(iv) условия расчета и предоставления сервис-кредитов.
1.4. SLA не применяется к пробным, тестовым и бета-версиям, дополнительным услугам вне тарифа, а также к сбоям, вызванным действиями Клиента, внешними сервисами или обстоятельствами, не зависящими от Провайдера.
1.5. Провайдер ведет мониторинг состояния Платформы, фиксирует инциденты и публикует отчеты о доступности. В спорных случаях приоритет имеют данные Провайдера, если Клиент не представит достоверные встречные доказательства.
2. Общие положения
2.1. - 2.21.
- 2.1. Платформа – совокупность программных и технических средств gro.now, предоставляемых Провайдером по модели SaaS и обеспечивающих доступ Клиентов к функциональности и данным в соответствии с Пользовательским соглашением.
- 2.2. Сервисы – функции и возможности Платформы, обеспечивающие выполнение Провайдером обязательств по доступности, поддержке и обновлению в рамках действующего Тарифа Клиента.
- 2.3. Доступность (Uptime) — доля времени в расчетном периоде, в течение которого Платформа функционирует в нормальном режиме и позволяет выполнять ключевые пользовательские операции.
- 2.4. Простой (Downtime) — период недоступности Платформы или существенного ограничения ее функций, подтвержденный системным мониторингом Провайдера.
- 2.5. Исключаемый простой – периоды недоступности, не подлежащие включению в расчет доступности (в том числе плановые и экстренные работы, форс-мажор, сбои внешних сервисов или действий Клиента).
- 2.6. Инцидент – подтвержденное событие, влияющее на доступность, производительность, безопасность или целостность Платформы и требующее вмешательства специалистов Провайдера.
- 2.7. Категория инцидента – уровень серьезности инцидента, определяемый по степени влияния на Клиентов и функции Платформы.
- 2.8. Плановые работы (Maintenance) – заранее запланированные технические операции по обновлению, резервированию или модернизации Платформы, о которых Клиенты уведомляются заранее.
- 2.9. Экстренные работы – технические действия Провайдера, необходимые для предотвращения или устранения критического сбоя, угрозы безопасности или нарушения закона, проводимые без предварительного уведомления с последующим информированием Клиентов.
- 2.10. Время реакции (Time to Acknowledge / TTA) – период между регистрацией инцидента и началом его обработки специалистом Провайдера.
- 2.11. Время восстановления (Time to Restore Service / TTRS) – период, необходимый для восстановления нормальной работы Платформы после инцидента.
- 2.12. Сервис-кредит – компенсация в виде зачета (скидки) в будущих платежах за Подписку Клиента, предоставляемая при невыполнении Провайдером целевых показателей SLA.
- 2.13. Мониторинг — совокупность автоматизированных средств и процессов Провайдера, обеспечивающих постоянное наблюдение за состоянием Платформы, регистрацией инцидентов и фиксацией времени простоя.
- 2.14. Поддержка — процесс взаимодействия Клиента и Провайдера по вопросам инцидентов, обращений, уведомлений и технического сопровождения, включая регистрацию тикетов и обратную связь через установленные каналы.
- 2.15. Расчетный период – календарный месяц, используемый для измерения доступности, классификации инцидентов и предоставления сервис-кредитов.
- 2.16. Клиент – юридическое лицо или индивидуальный предприниматель, имеющий активную Подписку и пользующийся Сервисами Платформы.
- 2.17. Рабочие часы поддержки — период, в течение которого сотрудники Провайдера принимают и обрабатывают обращения Клиентов через установленные каналы поддержки.
- 2.18. Рабочие дни – рабочие дни согласно производственному календарю на текущий год, утвержденный Министерством труда и социальной защиты населения Республики Казахстан.
- 2.19. Отчет об инциденте (RCA) – документ, содержащий описание инцидента, его влияние, первопричину, предпринятые меры и корректирующие действия.
- 2.20. Обходное решение (Workaround) – временная мера или изменение конфигурации, позволяющее снизить влияние инцидента до приемлемого уровня до внедрения окончательного исправления.
- 2.21. AUP - Правила допустимого использования, размещенные на https:/app./gro.now/legal/aup, определяющие запреты и ограничения при пользовании Платформой.
3. Целевые показатели и методика измерения
Таблица показателей
| Показатель / | Целевое значение | Методика измерения | Комментарии / Исключения |
|---|---|---|---|
| Доступность (Uptime) | ≥ 95% за Расчетный период | Мониторинг Провайдера. Учитываются интервалы недоступности более 5 мин. | Не учитываются плановые и экстренные работы, внешние сбои, действия Клиента, форс-мажор, пробные/бета-среды. |
| Расчетный период | Календарный месяц (UTC+5) | Ведется непрерывный мониторинг | Uptime = 1 - (время Downtime + время периода). |
| Плановые работы (Maintenance) | Уведомление ≥ 24 ч заранее; суммарно ≤ 4 ч в месяц | По графику и уведомлениям Провайдера | Выполняются преимущественно 02:00–06:00 (UTC+5). Подробнее в Разделе 9. |
4. Классификация инцидентов, время реагирования и восстановления
| Категория (приоритет) | Описание | Типичное влияние | Примеры ситуаций | Целевые сроки (реакция / восстановление) |
|---|---|---|---|---|
| P1 - Критическая | Полная недоступность Платформы или ее ключевых функций. | Большинство Клиентов не могут использовать сервис. | Платформа не загружается; АРІ не отвечает; критические операции | Реакция (ТТА) – до 1 ч (24×7) Восстановление (TTRS) – до 4 ч |
| P2 – Высокая | Значительная деградация или ограничение ключевых модулей. | Существенное снижение производительности или ограничение доступа для части | Ошибки при загрузке проектов, сбои аналитических модулей, массовые тайм-ауты. | Реакция (ТТА) – до 2 ч Восстановление (TTRS) – до 8 ч |
| P3 – Средняя | Сбой отдельных функций, не влияющий критически на основные функции Платформы. | Нарушена работа отдельных компонентов или операций. | Ошибки интерфейса, некорректные отчеты, сбой уведомлений. | Реакция (ТТА) – до 4 ч Восстановление (TTRS) – до 24 ч |
| P4 – Низкая | Некритичные дефекты или запросы улучшений. | Влияние минимально, сервис работает. | Неточность в интерфейсе, запрос на настройку или документирование. | Реакция (ТТА) – до 1 раб. дня Исправление – по плану релиза |
5. Поддержка и порядок обращения
5.1. - 5.9.
5.1. Провайдер обеспечивает техническую поддержку Клиентов по вопросам доступности, инцидентов, конфигурации и работы Платформы в пределах действующего Тарифа.
5.2. Поддержка осуществляется через следующие каналы: (i) систему тикетов в интерфейсе Платформы (если доступна); (ii) электронную почту: t@gro.now; (iii) форму обратной связи на сайте или в личном кабинете.
5.3. Обращение Клиента должно содержать: (i) идентификатор аккаунта и контактное лицо; (ii) описание проблемы, предполагаемую категорию инцидента; (iii) технические детали (дата, время, скриншоты, логи, URL или ID задачи).
5.4. Все обращения регистрируются с присвоением номера тикета и категории инцидента. Провайдер информирует Клиента о начале обработки и дальнейшем ходе решения.
5.5. Для инцидентов категории Р1 поддержка оказывается круглосуточно (24×7). Для остальных категорий – в рабочие часы поддержки: 09:00-19:00 (UTC+5) в рабочие дни.
5.6. Клиент обязуется обеспечивать доступность контактного лица и, при необходимости, предоставлять дополнительную информацию или тестовые данные для воспроизведения инцидента.
5.7. При получении уведомления о решении инцидента Клиент подтверждает его закрытие или сообщает о необходимости дополнительной проверки.
5.8. При повторном возникновении аналогичной проблемы в течение 7 календарных дней Клиент вправе запросить Отчет об инциденте (RCA). Провайдер предоставляет его в течение 5 рабочих дней после стабилизации сервиса.
5.9. Если инцидент вызван действиями Клиента, его пользователей, подрядчиков или сторонних сервисов, Провайдер вправе отнести обращение к категории консультационного и обработать его в рамках обычной поддержки без применения SLA-сроков.
5.2. Поддержка осуществляется через следующие каналы: (i) систему тикетов в интерфейсе Платформы (если доступна); (ii) электронную почту: t@gro.now; (iii) форму обратной связи на сайте или в личном кабинете.
5.3. Обращение Клиента должно содержать: (i) идентификатор аккаунта и контактное лицо; (ii) описание проблемы, предполагаемую категорию инцидента; (iii) технические детали (дата, время, скриншоты, логи, URL или ID задачи).
5.4. Все обращения регистрируются с присвоением номера тикета и категории инцидента. Провайдер информирует Клиента о начале обработки и дальнейшем ходе решения.
5.5. Для инцидентов категории Р1 поддержка оказывается круглосуточно (24×7). Для остальных категорий – в рабочие часы поддержки: 09:00-19:00 (UTC+5) в рабочие дни.
5.6. Клиент обязуется обеспечивать доступность контактного лица и, при необходимости, предоставлять дополнительную информацию или тестовые данные для воспроизведения инцидента.
5.7. При получении уведомления о решении инцидента Клиент подтверждает его закрытие или сообщает о необходимости дополнительной проверки.
5.8. При повторном возникновении аналогичной проблемы в течение 7 календарных дней Клиент вправе запросить Отчет об инциденте (RCA). Провайдер предоставляет его в течение 5 рабочих дней после стабилизации сервиса.
5.9. Если инцидент вызван действиями Клиента, его пользователей, подрядчиков или сторонних сервисов, Провайдер вправе отнести обращение к категории консультационного и обработать его в рамках обычной поддержки без применения SLA-сроков.
6. Исключения из расчета доступности
6.1.
Из расчета показателей SLA исключаются периоды, когда недоступность или сбои вызваны обстоятельствами, находящимися вне контроля Провайдера.
6.2. К таким случаям относятся:
a) плановые и экстренные технические работы, проведенные с соблюдением порядка уведомления;
b) инциденты, вызванные действиями или настройками Клиента, его пользователей либо подрядчиков;
c) сбои и задержки в работе внешних интеграций, сетей связи, облачных или платежных сервисов третьих лиц;
d) нарушения AUP или превышение лимитов/квот;
e) инциденты в пробных, демо- или бета-средах;
f) отказ Клиента от предложенного обходного решения (workaround);
g) требования госорганов, юридические ограничения или регуляторные меры;
h) форс-мажор.
b) инциденты, вызванные действиями или настройками Клиента, его пользователей либо подрядчиков;
c) сбои и задержки в работе внешних интеграций, сетей связи, облачных или платежных сервисов третьих лиц;
d) нарушения AUP или превышение лимитов/квот;
e) инциденты в пробных, демо- или бета-средах;
f) отказ Клиента от предложенного обходного решения (workaround);
g) требования госорганов, юридические ограничения или регуляторные меры;
h) форс-мажор.
6.3. - 6.4.
6.3. Такие периоды фиксируются Провайдером как «исключаемые интервалы» и не учитываются при расчете доступности (Uptime). Решение о применении исключения документируется в отчете об инциденте.
6.4. Открытые источники и парсинг. Доступность и состав данных из открытых источников зависят от Владельцев соответствующих площадок (включая их правила, robots.txt, API-политики, антибот-механизмы, капчи и лимиты). Провайдер не гарантирует непрерывную работоспособность парсеров/коннекторов к конкретным источникам и оставляет за собой право:
a) временно приостанавливать или прекращать сбор из источника;
b) не восстанавливать работу конкретного парсера, если владелец источника ограничил доступ, изменил политику/формат или это несоразмерно рискам/затратам;
c) заменять источник функционально эквивалентным или близким по ценности. Такие события не считаются нарушением SLA и не влекут сервис-кредитов.
6.4. Открытые источники и парсинг. Доступность и состав данных из открытых источников зависят от Владельцев соответствующих площадок (включая их правила, robots.txt, API-политики, антибот-механизмы, капчи и лимиты). Провайдер не гарантирует непрерывную работоспособность парсеров/коннекторов к конкретным источникам и оставляет за собой право:
a) временно приостанавливать или прекращать сбор из источника;
b) не восстанавливать работу конкретного парсера, если владелец источника ограничил доступ, изменил политику/формат или это несоразмерно рискам/затратам;
c) заменять источник функционально эквивалентным или близким по ценности. Такие события не считаются нарушением SLA и не влекут сервис-кредитов.
7. Методика расчета доступности (Uptime Formula)
7.1. - 7.9.
- 7.1. Расчетный период – календарный месяц по часовому поясу Провайдера (UTC+5).
- 7.2. Uptime отражает долю времени, в течение которого Платформа функционировала в нормальном режиме, без подтвержденных инцидентов недоступности, за исключением «исключаемых интервалов».
- 7.3. Формула расчета: Доступность = (1 - Td / (Tt - Te)) x 100% где:
- Td - суммарная продолжительность подтвержденных периодов недоступности (Downtime), выраженная в минутах;
- Tt - общее время расчетного периода;
- Те - суммарная продолжительность исключаемых интервалов, определенных в Разделе 6.
- 7.4. В расчет включаются только подтвержденные инциденты недоступности, длительностью не менее 5 минут подряд, влияющие на ключевые пользовательские операции. Кратковременные перебои, не зафиксированные мониторингом Провайдера или не подтвержденные Клиентом с предоставлением данных, не учитываются.
- 7.5. Мониторинг ведется на уровне прикладного слоя (доступность интерфейсов, ключевых сервисов). Сетевые сбои или ошибки доступа со стороны инфраструктуры Клиента, локальных провайдеров связи или интеграций третьих лиц не включаются в расчет.
- 7.6. При проведении плановых или экстренных работ Провайдер указывает конкретное окно и длительность, которое исключается из времени расчета.
- 7.7. Итоговый показатель Uptime округляется до двух знаков после запятой и фиксируется в ежемесячном отчете Провайдера.
- 7.8. При спорных расчетах приоритет имеют данные системного мониторинга Провайдера, если Клиент не представит достоверные и подтвержденные метрики сопоставимого уровня точности.
- 7.9. При выявлении ошибок в расчетах Провайдер корректирует отчетность и, при необходимости, пересчитывает сервис-кредиты в следующем расчетном периоде.
8. Сервис-кредиты и порядок их предоставления
8.1. Сервис-кредит – форма компенсации Клиенту за недостижение целевых показателей доступности, выраженная в виде скидки, применяемой к оплате последующих расчетных периодов Подписки. Денежные выплаты не производятся.
8.2. Размер сервис-кредита определяется исходя из фактического значения доступности (Uptime) за расчетный месяц по данным мониторинга Провайдера:
8.3. Кредит предоставляется по письменному запросу Клиента, направленному в течение 15 календарных дней после окончания расчетного месяца. Запрос должен содержать обоснование и при необходимости подтверждения инцидентов (ID тикетов или даты событий).
8.4. Кредит засчитывается при оплате следующего периода Подписки, либо, если Подписка прекращается, – в виде зачета в счет окончательных расчетов между Сторонами.
8.5. Кредиты не предоставляются, если:
a) недоступность возникла в периоды, исключаемые из расчета согласно Разделу 6;
b) Клиент не выполнил свои обязательства по предоставлению информации для расследования инцидента;
c) недоступность связана с действиями Клиента, его пользователей или подрядчиков;
d) инцидент не был зарегистрирован или не подтвержден в системе поддержки Провайдера.
8.6. Сервис-кредиты являются единственным и исключительным средством правовой защиты Клиента за нарушения SLA и не подлежат кумуляции с другими требованиями о возмещении убытков, неустойке или штрафах, если иное не предусмотрено индивидуальным соглашением Сторон.
8.7. Предоставление сервис-кредита не освобождает Провайдера от обязанности устранить причины инцидента и принять меры для предотвращения его повторения.
8.2. Размер сервис-кредита определяется исходя из фактического значения доступности (Uptime) за расчетный месяц по данным мониторинга Провайдера:
| Фактический Uptime за месяц | Размер сервис-кредита |
|---|---|
| от 95,0 % до 97,99 % | 5 % стоимости Подписки за месяц |
| от 90,0 % до 94,99 % | 10 % стоимости Подписки за месяц |
| ниже 90,0 % | 20 % стоимости Подписки за месяц |
8.3. Кредит предоставляется по письменному запросу Клиента, направленному в течение 15 календарных дней после окончания расчетного месяца. Запрос должен содержать обоснование и при необходимости подтверждения инцидентов (ID тикетов или даты событий).
8.4. Кредит засчитывается при оплате следующего периода Подписки, либо, если Подписка прекращается, – в виде зачета в счет окончательных расчетов между Сторонами.
8.5. Кредиты не предоставляются, если:
a) недоступность возникла в периоды, исключаемые из расчета согласно Разделу 6;
b) Клиент не выполнил свои обязательства по предоставлению информации для расследования инцидента;
c) недоступность связана с действиями Клиента, его пользователей или подрядчиков;
d) инцидент не был зарегистрирован или не подтвержден в системе поддержки Провайдера.
8.6. Сервис-кредиты являются единственным и исключительным средством правовой защиты Клиента за нарушения SLA и не подлежат кумуляции с другими требованиями о возмещении убытков, неустойке или штрафах, если иное не предусмотрено индивидуальным соглашением Сторон.
8.7. Предоставление сервис-кредита не освобождает Провайдера от обязанности устранить причины инцидента и принять меры для предотвращения его повторения.
9. Плановые и экстренные работы
- 9.1. Плановые работы (maintenance). Проводятся преимущественно в 02:00–06:00 (UTC+5). Провайдер уведомляет Клиента не менее чем за 24 часа с указанием даты, окна и затронутых функций. Время плановых работ относится к исключаемым интервалам и не учитывается при расчете Uptime.
- 9.2. Экстренные работы. Выполняются без предварительного уведомления, если необходимы для предотвращения/устранения критического инцидента или уязвимости безопасности. Провайдер размещает последующее уведомление с ключевыми деталями и фактической длительностью окна; такие интервалы исключаются из расчета Uptime.
- 9.3. Изменения без влияния. Краткие технические/уточняющие изменения конфигурации и инфраструктуры, не влияющие на права Клиента и доступность Платформы, могут выполняться немедленно и без уведомления.
- 9.4. Откат изменений. При негативном влиянии релиза Провайдер вправе откатить изменения (rollback) или применить обходное решение (Workaround) до полного исправления.
- 9.5. Коммуникации. Информация о статусе работ и инцидентов публикуется через статус-страницу/интерфейс Платформы и/или направляется на контактные e-mail адреса администраторов Клиента.
- 9.6. Перенос и «черные даты». Провайдер по возможности учитывает критичные для Клиента периоды (по заранее полученным уведомлениям) и может переносить окно работ, если это совместимо с безопасностью и графиком релизов.
- 9.7. Обязанности Клиента. Клиент обеспечивает сохранение несохраненных данных до начала окна работ, корректно завершает активные операции/интеграционные задания и воздерживается от запуска длительных задач на время технического окна.
10. Ответственность и ограничения
10.1. - 10.7.
10.1. Провайдер несет ответственность за соблюдение целевых показателей SLA в пределах своей зоны контроля, определенной настоящим документом и Пользовательским соглашением.
10.2. Провайдер не отвечает за сбои, задержки и иные последствия, вызванные:
a) действиями или бездействием Клиента, его пользователей или подрядчиков;
b) неисправностью оборудования, сетей или программного обеспечения, находящихся вне управления Провайдера;
c) ограничениями, установленными владельцами внешних источников, платформ или АРІ, включая изменения форматов данных и политик доступа;
d) обстоятельствами непреодолимой силы (форс-мажором) либо действиями государственных органов.
10.3. Совокупная ответственность Провайдера по всем требованиям, связанным с нарушением SLA, ограничивается суммой сервис-кредитов, предусмотренных разделом 7, и не может превышать размер ежемесячной платы Клиента за соответствующий расчетный период.
10.4. Провайдер не несет ответственности за:
a) упущенную выгоду, потерю данных или репутационного вреда;
b) косвенные, случайные или последующие убытки, даже если был уведомлен о возможности их возникновения;
c) отказ Клиента от предложенного обходного решения (workaround).
10.5. Сервис-кредиты являются единственным и исключительным средством защиты Клиента за нарушения SLA. Клиент не вправе требовать иных форм возмещения или неустоек, если иное не установлено письменным соглашением Сторон.
10.6. Провайдер вправе временно ограничить доступ Клиента к Платформе при нарушении AUP, угрозе безопасности, превышении лимитов или иных рисках, влияющих на стабильность системы. Такие меры не считаются нарушением SLA.
10.7. Провайдер обязуется добросовестно устранять причины инцидентов и предпринимать разумные меры для предотвращения их повторного возникновения, включая обновления, улучшение архитектуры и аудит процессов.
10.2. Провайдер не отвечает за сбои, задержки и иные последствия, вызванные:
a) действиями или бездействием Клиента, его пользователей или подрядчиков;
b) неисправностью оборудования, сетей или программного обеспечения, находящихся вне управления Провайдера;
c) ограничениями, установленными владельцами внешних источников, платформ или АРІ, включая изменения форматов данных и политик доступа;
d) обстоятельствами непреодолимой силы (форс-мажором) либо действиями государственных органов.
10.3. Совокупная ответственность Провайдера по всем требованиям, связанным с нарушением SLA, ограничивается суммой сервис-кредитов, предусмотренных разделом 7, и не может превышать размер ежемесячной платы Клиента за соответствующий расчетный период.
10.4. Провайдер не несет ответственности за:
a) упущенную выгоду, потерю данных или репутационного вреда;
b) косвенные, случайные или последующие убытки, даже если был уведомлен о возможности их возникновения;
c) отказ Клиента от предложенного обходного решения (workaround).
10.5. Сервис-кредиты являются единственным и исключительным средством защиты Клиента за нарушения SLA. Клиент не вправе требовать иных форм возмещения или неустоек, если иное не установлено письменным соглашением Сторон.
10.6. Провайдер вправе временно ограничить доступ Клиента к Платформе при нарушении AUP, угрозе безопасности, превышении лимитов или иных рисках, влияющих на стабильность системы. Такие меры не считаются нарушением SLA.
10.7. Провайдер обязуется добросовестно устранять причины инцидентов и предпринимать разумные меры для предотвращения их повторного возникновения, включая обновления, улучшение архитектуры и аудит процессов.
11. Обновление SLA и порядок вступления в силу
11.1. Провайдер вправе вносить изменения в настоящее SLA для уточнения терминов, показателей, процедур, а также при изменении технической архитектуры или сервисной модели Платформы.
11.2. Новая редакция SLA публикуется на сайте https://app.gro.now/legal/sla и вступает в силу:
(i) через 5 календарных дней после публикации – по умолчанию;
(ii) в более короткий срок, если это указано в уведомлении и обусловлено необходимостью оперативного обновления условий;
(iii) немедленно – если изменения носят технический или уточняющий характер и не затрагивают права Клиента.
11.3. Изменения применяются к новым и текущим Подпискам, начиная с ближайшего расчетного периода, если иное прямо не указано в уведомлении.
11.4. Клиент считается уведомленным об изменениях с момента публикации новой редакции SLA на сайте Провайдера. Продолжение использования Платформы после вступления изменений в силу означает согласие Клиента с обновленной редакцией.
11.5. В случае несогласия Клиент вправе прекратить использование Платформы в порядке, предусмотренном Пользовательским соглашением.
11.6. Настоящая редакция SLA вступает в силу с даты ее публикации и действует до замены новой версией.
11.2. Новая редакция SLA публикуется на сайте https://app.gro.now/legal/sla и вступает в силу:
(i) через 5 календарных дней после публикации – по умолчанию;
(ii) в более короткий срок, если это указано в уведомлении и обусловлено необходимостью оперативного обновления условий;
(iii) немедленно – если изменения носят технический или уточняющий характер и не затрагивают права Клиента.
11.3. Изменения применяются к новым и текущим Подпискам, начиная с ближайшего расчетного периода, если иное прямо не указано в уведомлении.
11.4. Клиент считается уведомленным об изменениях с момента публикации новой редакции SLA на сайте Провайдера. Продолжение использования Платформы после вступления изменений в силу означает согласие Клиента с обновленной редакцией.
11.5. В случае несогласия Клиент вправе прекратить использование Платформы в порядке, предусмотренном Пользовательским соглашением.
11.6. Настоящая редакция SLA вступает в силу с даты ее публикации и действует до замены новой версией.