После запуска сайта, приложения, SaaS-сервиса, CRM, личного кабинета или внутренней IT-системы работа с подрядчиком не заканчивается.
Наоборот, начинается самый чувствительный этап: продукт уже используется бизнесом, через него идут заявки, пользователи, платежи, документы, отчеты, сотрудники, клиенты и интеграции. Если система падает, ошибка становится не «технической проблемой», а потерей денег, заявок, клиентов и доверия.
Именно поэтому техническую поддержку нельзя оформлять фразой «исполнитель оказывает сопровождение проекта».
Нужно заранее определить, что входит в поддержку, в какие часы она оказывается, как подаются заявки, как классифицируются инциденты, за сколько исполнитель должен ответить, за сколько восстановить работу, что считается критической ошибкой, какие работы оплачиваются отдельно, какие исключения есть у исполнителя, какие доказательства фиксируются и какая ответственность наступает за нарушение SLA.
SLA — это соглашение об уровне сервиса. По сути, это измеримые правила технической поддержки: время реакции, время устранения или восстановления, доступность сервиса, приоритеты заявок, каналы связи, отчетность, штрафы, сервисные кредиты и исключения.
ZLATA LEGAL помогает предпринимателям, IT-проектам и компаниям во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России готовить и проверять договоры технической поддержки, сопровождения сайтов, SaaS-сервисов, приложений, CRM, маркетплейсов, личных кабинетов, Telegram-ботов и внутренних IT-систем.
Короткий ответ
Чтобы защитить заказчика, в договоре технической поддержки нужно прописать не только обязанность «поддерживать систему», а конкретные измеримые параметры.
Нужно указать состав системы, зоны ответственности исполнителя, часы поддержки, каналы обращений, порядок регистрации заявок, приоритеты инцидентов, время реакции, время восстановления, время устранения ошибки, порядок эскалации, плановые технические работы, резервное копирование, мониторинг, обновления, безопасность, отчетность, ответственность, неустойку или сервисные кредиты и исключения, когда исполнитель не отвечает.
Главная ошибка — обещать или принимать SLA без конкретных метрик. Фраза «оперативно устраняет ошибки» не защищает заказчика. В споре нужно понимать, что такое «оперативно»: 15 минут, 2 часа, 1 рабочий день или следующая неделя.
Для заказчика важно не просто наказать исполнителя после сбоя, а получить управляемую поддержку: понятный канал связи, предсказуемые сроки реакции, техническую фиксацию инцидента и реальный механизм восстановления сервиса.
Что такое техническая поддержка
Техническая поддержка — это сопровождение уже созданного цифрового продукта.
Она может включать консультации, исправление ошибок, мониторинг, резервное копирование, обновления, настройку сервера, проверку логов, восстановление после сбоя, работу с интеграциями, мелкие доработки, администрирование, помощь пользователям, контроль безопасности и взаимодействие с внешними сервисами.
Но в каждом проекте состав поддержки разный.
Для сайта-визитки поддержка может означать обновление CMS, резервные копии и исправление ошибок. Для интернет-магазина — еще платежи, каталог, заказы, интеграции с доставкой и CRM. Для SaaS — доступность сервиса, личный кабинет, база данных, роли, подписка, API, мониторинг, логи, инциденты и безопасность. Для B2B-системы — еще корпоративные пользователи, документы, отчеты, интеграции с 1С, ЭДО, складом, логистикой или банком.
Поэтому договор должен описывать поддержку именно конкретной системы, а не абстрактного «IT-проекта».
Что такое SLA простыми словами
SLA — это правила качества технической поддержки.
В нем обычно фиксируются: когда поддержка работает, через какие каналы принимаются заявки, как быстро исполнитель отвечает, как быстро начинает работу, как быстро восстанавливает сервис, какие инциденты считаются критическими, какие ошибки низкоприоритетными, как считается простой, какие есть исключения и что получает заказчик при нарушении SLA.
Например, критический инцидент — сервис полностью недоступен, пользователи не могут войти или оплатить. Время реакции — 15 минут. Время восстановления — 2 часа. Средний инцидент — не работает отдельная функция, но основной сервис доступен. Время реакции — 2 часа. Время восстановления — 1 рабочий день.
Без таких параметров SLA превращается в красивое слово без юридического смысла.
Чем поддержка отличается от доработки
Поддержку и доработки нужно разделять.
Поддержка — это сохранение работоспособности уже согласованного функционала: исправление ошибок, восстановление доступа, консультации, обновления, мониторинг, устранение сбоев.
Доработка — это изменение или расширение функционала: новая форма, новый отчет, новая интеграция, новый дизайн, новая роль пользователя, новый сценарий оплаты, новый модуль или изменение бизнес-логики.
Если это не разделить, конфликт почти гарантирован. Заказчик будет считать любую правку частью поддержки, а исполнитель — дополнительной разработкой.
В договоре нужно прямо указать: баги и инциденты входят в поддержку, новые функции оформляются отдельной заявкой, оценкой сроков и стоимости.
Почему SLA нужен заказчику
SLA нужен не только крупным корпорациям.
Если сайт или сервис влияет на деньги, заявки, клиентов, продажи, логистику, документы или внутренние процессы, заказчику нужно понимать, что будет при сбое.
Кто отвечает ночью, если платежи не проходят. Кто поднимает сайт, если хостинг лег. Кто проверяет, почему пользователи не получают письма. Кто восстанавливает базу. Кто отвечает за интеграцию с CRM. Кто исправляет ошибку после обновления. Кто уведомляет бизнес о плановых работах. Кто компенсирует нарушение сроков.
Без SLA заказчик зависит от доброй воли исполнителя: «посмотрим завтра», «разработчик занят», «это не наша зона», «это внешний сервис», «пишите в понедельник».
Для бизнеса такая неопределенность может быть дороже самой поддержки.
Почему SLA нужен исполнителю
Хороший SLA защищает не только заказчика, но и исполнителя.
Он ограничивает ожидания. Исполнитель не обязан отвечать круглосуточно, если договором предусмотрена поддержка только в рабочее время. Он не обязан бесплатно делать новые функции, если они не входят в сопровождение. Он не отвечает за сбой платежного агрегатора, если проблема на стороне агрегатора. Он не обязан восстанавливать систему за 10 минут, если согласованный срок восстановления — 4 часа.
SLA превращает поддержку из бесконечного потока сообщений в управляемый процесс.
Исполнитель понимает, какие заявки критические, какие обычные, какие платные, какие вне зоны ответственности и как фиксируется выполнение.
Что включить в договор поддержки
В договоре нужно указать объект поддержки: сайт, приложение, сервер, база, CRM, личный кабинет, SaaS, интеграции, бот, API, админка или конкретные модули.
Далее нужно описать состав услуг: консультации, исправление ошибок, мониторинг, резервные копии, обновления, серверное администрирование, безопасность, работа с интеграциями, поддержка пользователей, мелкие изменения, аварийное восстановление.
Затем — SLA: часы поддержки, каналы обращений, приоритеты, время реакции, время восстановления, время устранения, плановые работы, отчетность и ответственность.
Отдельно нужно указать, что не входит в поддержку: новые функции, редизайн, изменение бизнес-логики, перенос на другую платформу, работа с чужим кодом, исправление последствий действий третьих лиц, восстановление после нарушения заказчиком инструкций, платные лицензии, услуги хостинга и внешних сервисов, если они не включены в договор.
Объект поддержки
Объект поддержки нужно описать конкретно.
Плохо: «исполнитель оказывает техническую поддержку сайта».
Лучше: «исполнитель оказывает техническую поддержку сайта zzz.ru, размещенного на таком-то хостинге, включая CMS, frontend, backend, базу данных, формы заявок, интеграцию с CRM, Яндекс Метрику, почтовые уведомления и платежный модуль».
Для SaaS: «поддержка веб-приложения, личного кабинета пользователей, административной панели, API, базы данных, серверной инфраструктуры, платежной интеграции, email-уведомлений и системы логирования».
Если объект поддержки не определен, исполнитель может говорить, что спорный модуль не входил в поддержку. Заказчик будет говорить обратное.
Зона ответственности
Зона ответственности — ключевой раздел.
Нужно определить, за что отвечает исполнитель: код, сервер, база, CMS, интеграции, платежи, резервные копии, обновления, безопасность, мониторинг, админка, API, техническая консультация.
И за что не отвечает: интернет у пользователя, устройство пользователя, ошибки сотрудников заказчика, действия другого подрядчика, сбой внешнего сервиса, блокировка аккаунта третьей платформой, неоплата хостинга, изменение API внешней системы, вирус на компьютере заказчика, нарушение инструкций, самостоятельное изменение кода заказчиком.
Но исключения должны быть разумными. Нельзя написать «исполнитель ни за что не отвечает». Если исполнитель администрирует сервер, он не может полностью снять с себя ответственность за базовую настройку и резервные копии. Если он отвечает за интеграцию, он должен хотя бы диагностировать, где проблема: в коде заказчика или во внешнем сервисе.
Часы поддержки
Нужно указать, когда исполнитель принимает и обрабатывает заявки.
Варианты разные: 5/2 с 9:00 до 18:00, 7/7 в рабочее время, расширенная поддержка, круглосуточная аварийная линия, отдельный режим для критических инцидентов.
Если бизнес работает только днем, достаточно обычной поддержки. Если сервис принимает платежи, заявки или бронирования круглосуточно, может понадобиться аварийный режим.
Важно разделить прием заявки и начало реакции. Например, пользователь может отправить заявку в любое время, но SLA начинает течь только в рабочие часы, кроме критических инцидентов. Или критические инциденты обрабатываются 24/7, а обычные — в рабочее время.
Без этого ночное сообщение в Telegram может стать спором: заказчик ждал реакции сразу, исполнитель увидел утром.
Каналы обращений
Каналы поддержки нужно закрепить.
Это может быть helpdesk, email, личный кабинет, Telegram-чат, телефон, система задач, Jira, YouTrack, Bitrix24, GitLab Issues или другая система.
Для SLA важно, чтобы заявка была зарегистрирована. Если заказчик написал голосовое сообщение в личный Telegram разработчика, а потом спорит о сроках, доказательства слабые.
Лучше указать официальный канал: заявка считается поданной после регистрации в helpdesk или направления на support-email. Telegram можно использовать для оперативного уведомления, но юридически значимый срок начинается с регистрации заявки в согласованном канале.
Для критических инцидентов можно предусмотреть отдельный аварийный канал: телефон или специальный чат.
Приоритеты заявок
Все заявки не могут быть одинаковыми.
Нужно ввести приоритеты. Например: критический инцидент, высокий, средний, низкий, консультационный запрос.
Критический — сервис полностью недоступен, не работают платежи, пользователи не могут войти, потеряна база, есть риск утечки данных.
Высокий — важная функция не работает, но сервис частично доступен; существенная группа пользователей затронута; ошибка влияет на продажи или обработку заказов.
Средний — ошибка отдельной функции, есть временный обходной путь, бизнес-процесс не остановлен.
Низкий — косметическая ошибка, небольшое неудобство, консультация, вопрос по настройке, minor bug.
Для каждого приоритета нужно указать время реакции и восстановления. Иначе заказчик будет считать любую проблему критической, а исполнитель — обычной.
Время реакции
Время реакции — это срок, в течение которого исполнитель должен подтвердить получение заявки и начать разбор.
Это не всегда время полного исправления.
Например, по критическому инциденту время реакции 15 минут, по высокому — 1 час, по среднему — 4 часа, по низкому — 1 рабочий день.
В договоре нужно написать, что считается реакцией: подтверждение заявки, назначение ответственного, начало диагностики, запрос дополнительной информации или создание инцидента в системе.
Плохой вариант — считать реакцией любое сообщение «принято». Тогда исполнитель формально уложился, но ничего не сделал. Лучше связать реакцию с началом диагностики или назначением ответственного.
Время восстановления
Время восстановления — это срок, в течение которого исполнитель должен вернуть сервис в рабочее состояние или обеспечить временный обходной путь.
Для бизнеса это часто важнее полного исправления.
Например, платежи не проходят. Полное исправление интеграции может занять день, но временно можно включить резервный способ оплаты или отключить проблемный модуль. Сайт упал из-за обновления — можно откатить релиз. База повреждена — можно восстановить резервную копию.
В SLA нужно различать восстановление работоспособности и окончательное устранение причины. Исполнитель может быстро восстановить сервис, а потом уже спокойно разбираться с первопричиной.
Время устранения
Время устранения — это срок полного исправления ошибки.
Не всякую ошибку можно устранить за два часа. Иногда нужен анализ кода, тестирование, исправление интеграции, обновление библиотеки, участие внешнего сервиса или согласование с заказчиком.
Поэтому в SLA можно указывать разные сроки: время реакции, время восстановления и целевой срок устранения. Для критических инцидентов сначала важно восстановить сервис, а полное исправление может занять больше времени.
Если срок устранения зависит от внешнего сервиса, заказчика или третьей системы, это нужно указать как исключение или основание для приостановки SLA.
Доступность сервиса
Для SaaS и онлайн-сервисов можно прописывать доступность, например 99%, 99,5% или 99,9% в месяц.
Но обещать доступность нужно только тогда, когда исполнитель реально контролирует инфраструктуру и мониторинг. Если хостинг, облако, платежный агрегатор и часть инфраструктуры находятся вне контроля исполнителя, обещать общую доступность без исключений опасно.
В договоре нужно указать, как считается доступность, какие периоды исключаются, что считается недоступностью, какой мониторинг является источником данных и какие последствия наступают при нарушении.
Из доступности обычно исключают плановые работы, сбои внешних сервисов, проблемы интернета у пользователя, DDoS сверх согласованной защиты, действия заказчика, неоплату инфраструктуры, форс-мажор и инциденты вне зоны контроля исполнителя.
Плановые технические работы
Плановые работы нужно отделять от аварий.
Обновления, миграции, перезапуск сервера, установка патчей, обновление CMS, перенос базы, настройка интеграций и другие работы могут временно ограничивать доступность сервиса.
В договоре нужно указать, как исполнитель уведомляет заказчика о плановых работах: за сколько часов или дней, в какие окна, какой максимальный простой допустим, какие работы можно проводить без уведомления, если они не влияют на пользователей.
Для B2B-сервиса лучше согласовывать плановые работы в периоды низкой нагрузки. Для сайта с рекламой — учитывать активные кампании. Для платежного сервиса — не делать миграцию в пик продаж.
Аварийные работы
Аварийные работы проводятся, когда нужно срочно предотвратить ущерб: взлом, утечка, падение сервера, повреждение базы, критическая ошибка, угроза безопасности или массовый сбой.
В договоре нужно дать исполнителю право проводить аварийные работы без предварительного согласования, если промедление может увеличить вред.
Но после таких работ исполнитель должен уведомить заказчика: что произошло, какие меры приняты, какие последствия, что нужно сделать дальше.
Это особенно важно для систем с персональными данными, платежами, B2B-клиентами и бизнес-критичными процессами.
Мониторинг
Если заказчик хочет реальный SLA, нужен мониторинг.
Нельзя управлять доступностью сервиса только по сообщениям пользователей. Нужно понимать, когда сайт недоступен, когда API не отвечает, когда платежи падают, когда база перегружена, когда заканчивается место на диске, когда сертификат истекает, когда ошибки растут.
В договоре нужно указать, кто настраивает мониторинг, какие параметры отслеживаются, кто получает уведомления, какие события создают инцидент и входит ли мониторинг в стоимость поддержки.
Если мониторинг не включен, исполнитель может отвечать только на заявки заказчика. Тогда SLA по доступности будет слабее, потому что исполнитель узнает о сбое не автоматически.
Резервное копирование
Резервные копии — один из главных элементов поддержки.
В договоре нужно указать, кто отвечает за backup, как часто делаются копии, где хранятся, сколько времени, проверяется ли восстановление, кто имеет доступ, шифруются ли копии, как быстро можно восстановить систему.
Плохо, когда в договоре написано «исполнитель обеспечивает резервное копирование», но не указано, ежедневно это или раз в месяц, хранится одна копия или десять, проверялось ли восстановление и что именно копируется: файлы, база, конфигурации, медиа, настройки сервера.
Для бизнеса важно не наличие папки backup, а возможность реально восстановить сервис.
Обновления
Обновления могут быть частью поддержки, но их нужно описать.
CMS, плагины, библиотеки, сервер, фреймворки, зависимости, мобильные SDK, платежные модули и внешние интеграции требуют обновлений. Но обновление может сломать продукт.
В договоре нужно определить, кто принимает решение об обновлении, как оно тестируется, где проводится сначала — на тестовой среде или сразу в продакшене, кто отвечает за несовместимость, как делается откат и входит ли обновление в абонентскую плату.
Если обновления не включены, заказчик должен понимать риск устаревания продукта. Если включены, исполнитель должен иметь разумную процедуру, а не обновлять все вслепую.
Безопасность
Поддержка часто связана с безопасностью.
Исполнитель может отвечать за обновления безопасности, настройку доступа, защиту админки, резервные копии, SSL, контроль подозрительной активности, закрытие известных уязвимостей, базовые рекомендации и реагирование на инциденты.
Но безопасность нельзя обещать абстрактно. Нужно указать, что именно входит: базовые меры, мониторинг, обновления, аудит, pentest, реагирование, консультации, настройка прав, двухфакторная аутентификация.
Если заказчик хочет серьезный уровень безопасности, это отдельная услуга и отдельный бюджет. Нельзя ожидать банковский уровень защиты от договора поддержки сайта за несколько тысяч рублей в месяц.
Персональные данные
Если в системе есть персональные данные, поддержка должна учитывать их обработку.
Исполнитель может видеть базу пользователей, заявки, платежные сведения, логи, обращения, документы, аккаунты и переписку. Значит, в договоре нужен блок о поручении обработки персональных данных: какие данные доступны исполнителю, для каких целей, какие меры защиты применяются, кто имеет доступ, можно ли использовать реальные данные в тестовой среде, как удаляются копии и что делать при инциденте.
Также нужно указать, что исполнитель не вправе использовать данные пользователей для своих целей, передавать их третьим лицам или сохранять после окончания договора без основания.
Для SaaS, маркетплейса, CRM, приложения и личного кабинета это критический блок.
Инциденты безопасности
Инцидент безопасности — это не обычная ошибка.
Это взлом, утечка, компрометация пароля, подозрительная активность, несанкционированный доступ, вредоносный код, массовая ошибка прав доступа, потеря данных или иное событие, которое может затронуть безопасность системы и данных.
В договоре нужно указать, как исполнитель сообщает об инциденте, в какой срок, кому, какие сведения передает, какие первичные меры принимает, как сохраняет логи и доказательства, кто принимает решение о внешних уведомлениях.
Если исполнитель молчит об инциденте или сообщает через неделю, заказчик может не успеть выполнить свои обязанности перед пользователями, контрагентами или регулятором.
Отчетность
В договоре поддержки полезно предусмотреть отчетность.
Отчет может включать список заявок, время реакции, время устранения, инциденты, плановые работы, обновления, резервные копии, рекомендации, превышение лимитов, остаток часов, нарушения SLA и предложения по улучшению.
Для маленького сайта достаточно ежемесячного краткого отчета. Для SaaS или B2B-системы отчетность должна быть подробнее.
Отчет помогает не спорить на эмоциях: видно, сколько заявок было, как быстро исполнитель отвечал, какие проблемы повторяются и где нужно улучшать систему.
Абонентская плата и лимит часов
Поддержка часто оплачивается абонентской платой.
В договоре нужно указать, что входит в абонентскую плату: количество часов, типы работ, консультации, мониторинг, резервные копии, мелкие правки, аварийные работы, обновления, отчетность.
Если есть лимит часов, нужно описать, что происходит при превышении: дополнительные часы по ставке, отдельное согласование, перенос неиспользованных часов, сгорание часов, приоритет аварийных работ.
Если лимита нет, нужно особенно четко описать объем услуг. Иначе заказчик может ожидать бесконечную поддержку за фиксированную сумму, а исполнитель будет считать половину задач дополнительными.
Дополнительные работы
Дополнительные работы нужно оформлять отдельно.
Например, новая функция, редизайн, интеграция, миграция, доработка личного кабинета, новый отчет, изменение бизнес-логики, разработка API, перенос на другой сервер, исправление чужого кода, восстановление после действий третьих лиц.
В договоре нужно указать порядок: заявка, оценка, стоимость, срок, подтверждение заказчика, выполнение, приемка, оплата.
Это защищает обе стороны. Заказчик не получает неожиданный счет, исполнитель не выполняет бесплатные работы сверх поддержки.
Приемка услуг поддержки
Приемка поддержки отличается от приемки разработки.
Поддержка может оказываться постоянно: заявки, консультации, мониторинг, обновления, исправления. Поэтому акт обычно подписывается за период: месяц, квартал или иной срок.
В договоре нужно указать, как заказчик принимает услуги, в какой срок направляет возражения, что считается подтверждением оказания услуг, как учитываются заявки и отчеты.
Если заказчик молчит и пользуется результатом, договор может предусматривать, что услуги за период считаются принятыми при отсутствии мотивированных возражений.
Но исполнитель должен иметь доказательства: отчет, список заявок, переписка, логи, акты, закрытые тикеты.
Неустойка
Неустойка — понятный инструмент ответственности.
Можно предусмотреть штраф или пеню за нарушение времени реакции, времени восстановления, срока устранения критической ошибки, непредоставление отчета, нарушение конфиденциальности, неуведомление об инциденте, потерю данных по вине исполнителя или необоснованный отказ от поддержки.
Но неустойка должна быть разумной и привязанной к важным обязательствам. Если поставить огромный штраф за любую мелкую ошибку, это может осложнить переговоры и не всегда даст реальную защиту.
Для SLA часто используют не прямой штраф, а сервисные кредиты: уменьшение платы за следующий период при нарушении доступности или сроков реакции.
Сервисные кредиты
Сервисный кредит — это компенсация в виде скидки, зачета или уменьшения платы за будущий период.
Например, если доступность сервиса за месяц ниже согласованного уровня, заказчик получает 5%, 10% или 20% скидки на следующий месяц поддержки. Если критический инцидент восстановлен с просрочкой, часть абонентской платы уменьшается.
Для исполнителя сервисные кредиты удобнее, чем открытая неустойка за каждый сбой. Для заказчика — это хотя бы автоматический механизм компенсации без доказывания убытков.
Но сервисные кредиты не всегда должны заменять все убытки. Для критичных проектов нужно отдельно решить, сохраняет ли заказчик право требовать убытки сверх сервисных кредитов или сервисный кредит является единственным средством компенсации.
Убытки
Убытки в IT-поддержке могут быть существенными.
Простой сайта, потеря заявок, невозможность оплаты, остановка CRM, срыв поставки, потеря данных, расходы на восстановление, срочное привлечение новой команды, штрафы перед клиентами, репутационные потери.
Но убытки нужно доказывать: факт нарушения, размер убытков, причинную связь и разумность расходов.
В договоре можно ограничить ответственность исполнителя, например размером абонентской платы за определенный период. Для B2B это обычная практика, но заказчик должен понимать, достаточно ли такого лимита для критичной системы.
Если сервис влияет на крупные деньги, лимит ответственности «одна месячная плата» может быть слабой защитой.
Ограничение ответственности
Исполнитель обычно хочет ограничить ответственность.
Это нормально, если ограничение разумное и не превращает договор в «мы ни за что не отвечаем».
Можно ограничить ответственность размером оплаты за 1, 3, 6 или 12 месяцев поддержки. Можно исключить упущенную выгоду, косвенные убытки и потери из-за внешних сервисов. Можно установить отдельный лимит для обычных ошибок и более высокий для грубой неосторожности, утечки данных или умышленного нарушения.
Заказчику важно смотреть, не обнуляет ли ограничение весь SLA. Если исполнитель обещает реакцию за 15 минут, но за нарушение отвечает максимум 500 рублей, такое SLA скорее декоративное.
Исключения из ответственности
Исключения нужны обязательно.
Исполнитель не должен отвечать за сбои, которые вызваны действиями заказчика, третьих лиц, другого подрядчика, хостинга вне зоны контроля исполнителя, внешнего API, платежного агрегатора, DDoS сверх согласованной защиты, неоплатой сервисов, отсутствием доступов, нарушением инструкций, устаревшей инфраструктурой, отказом заказчика согласовать обновления или форс-мажором.
Но исключения должны быть конкретными.
Плохая формулировка: «исполнитель не отвечает за любые обстоятельства, не зависящие от него». Лучше перечислить основные сценарии и указать, что исполнитель обязан помочь в диагностике, даже если первопричина вне его зоны.
Обязанности заказчика
SLA работает только если заказчик тоже выполняет свои обязанности.
Заказчик должен предоставить доступы, оплачивать хостинг и внешние сервисы, не менять код без уведомления, не привлекать третьих лиц без координации, назначить ответственных, своевременно отвечать на запросы, предоставлять информацию об ошибке, согласовывать плановые работы и соблюдать инструкции.
Если исполнитель не может устранить инцидент из-за отсутствия доступа или ответа заказчика, SLA должен приостанавливаться.
Это нужно прямо прописать. Иначе исполнитель будет отвечать за задержку, которую сам не мог устранить.
Эскалация
Для критических инцидентов нужен порядок эскалации.
Кто первый принимает заявку. Кто подключается при критическом сбое. Кто принимает решение об откате релиза, отключении функции, восстановлении backup, остановке платежей, уведомлении пользователей или аварийной миграции.
В договоре можно указать контактных лиц с обеих сторон, резервные контакты, аварийный канал и порядок принятия решений.
Без эскалации критический инцидент может зависнуть между менеджером, разработчиком, DevOps, заказчиком и внешним сервисом.
Изменение SLA
SLA может меняться.
На старте проекта достаточно поддержки 5/2. Когда сервис растет, появляется оплата, пользователи, B2B-клиенты и критичные интеграции, нужен более высокий уровень.
В договоре стоит предусмотреть возможность изменить SLA: перейти на другой тариф поддержки, добавить круглосуточный режим, мониторинг, аварийную линию, security support, выделенного инженера или повышенную доступность.
Также нужно указать, что изменение архитектуры, нагрузки, количества пользователей или критичности сервиса может требовать пересмотра стоимости поддержки.
SLA для сайта
Для обычного сайта SLA может быть простым.
Входит: мониторинг доступности, резервные копии, обновление CMS и плагинов, исправление ошибок, восстановление после сбоя, консультации, мелкие правки в пределах часов, проверка форм заявок, базовая безопасность.
Критический инцидент: сайт полностью недоступен, формы не отправляются, сайт заражен вредоносным кодом. Средний: не работает отдельный блок, ошибка верстки, проблема с письмами. Низкий: косметическая правка, консультация, изменение текста.
Для сайта важно закрепить домен, хостинг, резервные копии, обновления и ответственность за формы заявок, потому что именно заявки обычно имеют коммерческую ценность.
SLA для SaaS
Для SaaS SLA должен быть серьезнее.
Нужно описать доступность, личный кабинет, API, базу данных, роли пользователей, подписку, платежи, email-уведомления, мониторинг, логи, резервные копии, восстановление данных, обновления, инциденты безопасности и поддержку пользователей.
Также нужно определить, что считается простоем: недоступность всего сервиса, недоступность ключевой функции, невозможность оплаты, массовые ошибки входа, падение API.
Для SaaS важно разделять инфраструктуру, код, внешние интеграции и действия клиента. Если сервис зависит от платежного агрегатора или внешнего API, SLA должен объяснять, как такие сбои учитываются.
SLA для внутренней CRM
Для внутренней CRM или B2B-системы важны другие параметры.
Главное — не публичная доступность, а непрерывность бизнес-процесса: заявки, клиенты, статусы, отчеты, документы, роли сотрудников, интеграции с почтой, телефонией, 1С, складом, логистикой или платежами.
В SLA нужно определить критичные функции. Например, если не работает отчет — это средний приоритет. Если менеджеры не могут видеть заявки — высокий. Если база недоступна всей компании — критический.
Также нужно отдельно описать резервные копии и восстановление данных, потому что потеря CRM-данных может быть серьезнее временного простоя сайта.
SLA для мобильного приложения
Для приложения поддержка включает backend, API, мобильные сборки, публикацию обновлений, push-уведомления, магазины приложений, аналитику, crash-логи и совместимость с версиями iOS и Android.
В договоре нужно указать, кто отвечает за ошибки в приложении, кто готовит обновления, кто проходит модерацию магазинов, кто контролирует сертификаты и ключи, кто отвечает за backend и API.
Если приложение не работает из-за изменения правил App Store или Google Play, это отдельный сценарий. Если из-за ошибки кода исполнителя — другой. Если пользователь не обновил приложение — третий.
SLA для интеграций
Интеграции — частый источник проблем.
Платежи, CRM, 1С, склад, доставка, карты, SMS, email, банки, ЭДО, маркетплейсы, внешние API могут ломаться по причинам на стороне внешнего сервиса.
В SLA нужно указать, кто диагностирует проблему, кто общается с внешним сервисом, сколько времени исполнитель должен реагировать, что считается восстановлением, кто отвечает за изменения API, кто оплачивает доработки из-за изменений внешней системы.
Если исполнитель не контролирует внешний API, он не должен отвечать за его недоступность как за свою ошибку. Но он может отвечать за корректную обработку таких сбоев и своевременную диагностику.
SLA и релизы
Многие сбои возникают после обновлений.
В договоре поддержки стоит описать релизный процесс: тестовая среда, согласование обновлений, резервная копия перед релизом, окно релиза, план отката, проверка после релиза, кто принимает решение о выкладке.
Если исполнитель выкатывает обновление без теста и ломает сервис, это его зона ответственности. Если заказчик требует срочно выкатить непроверенную доработку, нужно фиксировать риск.
Для серьезных сервисов релиз без rollback-плана — плохая практика.
Тестовая среда
Тестовая среда помогает снижать риски.
В договоре можно указать, что изменения сначала проверяются на тестовом контуре, а потом переносятся в продуктивную среду. Также нужно определить, кто оплачивает тестовую инфраструктуру и насколько она совпадает с боевой.
Если тестовой среды нет, заказчик должен понимать, что любые изменения вносятся с повышенным риском.
Для SaaS, CRM, платежей и B2B-систем тестовая среда часто важнее, чем кажется на старте.
Документация поддержки
Для поддержки нужна документация.
Доступы, архитектура, схема сервера, список внешних сервисов, инструкции по развертыванию, backup-процедуры, контактные лица, порядок релизов, список критичных функций, карта интеграций, инструкции администратора.
Если документации нет, поддержка зависит от конкретного человека. Он ушел — знания ушли вместе с ним.
В договоре можно указать, что исполнитель ведет и обновляет документацию в пределах поддержки. Для заказчика это отдельная защита от зависимости.
Смена исполнителя
Договор поддержки должен предусматривать передачу дел при прекращении отношений.
Исполнитель должен передать актуальную документацию, доступы, резервные копии, инструкции, список открытых задач, сведения о проблемах, настройки мониторинга, ключи, контакты внешних сервисов и информацию, необходимую для перехода к новой команде.
Также нужно указать срок передачи и ответственность за удержание доступов.
Иначе заказчик может оказаться в ситуации: поддержка закончилась, исполнитель ушел, а новый подрядчик не может разобраться в системе.
Что нельзя обещать в SLA
Нельзя обещать то, что технически и экономически невозможно.
Если у исполнителя нет круглосуточной команды, не надо писать 24/7. Если нет мониторинга, не надо обещать мгновенное обнаружение сбоев. Если сервер дешевый и без резервирования, не надо обещать 99,99% доступности. Если нет тестовой среды, не надо обещать безопасные релизы. Если внешняя интеграция нестабильна, не надо брать на себя ответственность за ее работу.
SLA должен быть реалистичным. Хороший договор не продает иллюзию надежности, а честно описывает уровень сервиса за конкретные деньги.
Частые ошибки
Первая ошибка — написать «исполнитель оказывает техническую поддержку» без состава услуг. Вторая — не определить часы поддержки. Третья — не указать время реакции и восстановления. Четвертая — не разделить критические и обычные заявки. Пятая — не описать исключения. Шестая — не отделить поддержку от новых доработок. Седьмая — не закрепить резервные копии. Восьмая — обещать SLA без мониторинга. Девятая — не прописать персональные данные и безопасность. Десятая — не установить последствия нарушения SLA.
Почти всегда спор возникает не потому, что исполнитель вообще ничего не делает. Спор возникает потому, что стороны по-разному понимают слово «поддержка».
Как правильно прописать SLA
Сначала нужно определить критичность системы для бизнеса. Сайт-визитка, интернет-магазин, SaaS, CRM, платежный сервис и внутренняя панель требуют разного уровня поддержки.
Затем нужно описать объект поддержки и зоны ответственности. После этого — часы работы, каналы обращений, приоритеты инцидентов, время реакции, время восстановления, время устранения, плановые работы, мониторинг, backup, обновления, безопасность и отчетность.
Далее нужно прописать ответственность: сервисные кредиты, неустойку, убытки, лимиты ответственности и исключения. Отдельно — обязанности заказчика, доступы, персональные данные, конфиденциальность и передачу дел при расторжении.
Так SLA становится не рекламной фразой, а рабочим инструментом управления IT-рисками.
Локальный аспект: Владивосток, Приморье и Дальний Восток
Во Владивостоке и Приморском крае бизнес все чаще использует цифровые системы не как «дополнение», а как часть операционной работы: CRM, сайты с заявками, личные кабинеты, сервисы для логистики, ВЭД, поставок из Китая, складов, морской отрасли, B2B-платформы, Telegram-боты, внутренние панели и сервисы учета.
Для таких проектов техническая поддержка — это не просто «поправить сайт». Это вопрос непрерывности бизнеса.
Если не работает форма заявки, теряются лиды. Если падает CRM, менеджеры не видят клиентов. Если не работает интеграция с платежами, деньги не проходят. Если потеряна база, бизнес теряет историю работы. Если подрядчик отвечает через три дня, простой становится коммерческой проблемой.
Поэтому для регионального бизнеса важно заранее оформлять поддержку и SLA: кто отвечает, за что отвечает, как быстро реагирует, как восстанавливает, что компенсирует и как передает проект при смене подрядчика.
Как ZLATA LEGAL помогает с технической поддержкой и SLA
ZLATA LEGAL помогает заказчикам и IT-проектам подготовить договоры технической поддержки, сопровождения и SLA для сайтов, приложений, SaaS-сервисов, CRM, маркетплейсов, личных кабинетов, Telegram-ботов, интеграций и внутренних IT-систем.
Мы прописываем объект поддержки, состав услуг, часы работы, каналы обращений, приоритеты инцидентов, время реакции, время восстановления, время устранения, доступность сервиса, плановые и аварийные работы, мониторинг, резервные копии, обновления, безопасность, персональные данные, отчетность, сервисные кредиты, неустойку, убытки, лимиты ответственности и исключения.
Проверяем, чтобы договор не был декоративным: поддержка отделена от новых доработок, SLA измерим, ответственность исполнителя понятна, обязанности заказчика учтены, персональные данные защищены, а порядок передачи проекта при смене подрядчика заранее описан.
Работаем с компаниями, предпринимателями и IT-проектами во Владивостоке, Приморском крае, на Дальнем Востоке и дистанционно по России.
Техническая поддержка и SLA должны не создавать иллюзию надежности, а давать понятные правила: кто реагирует, когда реагирует, что восстанавливает, за что отвечает и что происходит, если уровень сервиса нарушен.
Частые вопросы
Что такое SLA в договоре поддержки?
SLA — это соглашение об уровне сервиса. В нем прописываются измеримые параметры поддержки: время реакции, время восстановления, доступность сервиса, приоритеты инцидентов, каналы обращений и ответственность за нарушение.
Чем поддержка отличается от доработки?
Поддержка сохраняет работоспособность уже согласованного функционала. Доработка добавляет или меняет функции, дизайн, интеграции или бизнес-логику. Доработки лучше оформлять отдельно.
Что обязательно указать в SLA?
Объект поддержки, часы работы, каналы заявок, приоритеты, время реакции, время восстановления, время устранения, плановые работы, исключения, ответственность и порядок отчетности.
Что такое время реакции?
Это срок, в течение которого исполнитель должен подтвердить заявку и начать диагностику. Реакция не всегда означает полное исправление проблемы.
Что такое время восстановления?
Это срок, за который исполнитель должен вернуть сервис в рабочее состояние или обеспечить временный обходной путь.
Что такое время устранения?
Это срок полного исправления ошибки или причины инцидента. Он может быть больше времени восстановления.
Можно ли требовать поддержку 24/7?
Можно, если исполнитель реально готов ее обеспечить и это отражено в стоимости. Если команды 24/7 нет, такое обещание будет декоративным.
Что такое сервисный кредит?
Это компенсация за нарушение SLA в виде скидки, зачета или уменьшения платы за следующий период поддержки.
Можно ли взыскать убытки за простой сайта?
Можно, если доказать нарушение, размер убытков и связь между простоем и потерями. В договоре может быть лимит ответственности, поэтому его нужно проверять заранее.
Кто отвечает за сбой внешнего сервиса?
Зависит от договора. Обычно исполнитель не отвечает за недоступность платежного агрегатора, хостинга или внешнего API, если они вне его контроля, но может отвечать за диагностику и корректную обработку сбоя.
Нужно ли прописывать резервные копии?
Да. Нужно указать частоту backup, состав копий, срок хранения, место хранения, проверку восстановления и ответственность за потерю данных.
Нужен ли SLA для обычного сайта?
Если сайт приносит заявки или продажи — да, хотя SLA может быть простым. Нужно хотя бы прописать поддержку форм, доступность, backup, обновления, сроки реакции и восстановление.
Нужен ли отдельный договор на поддержку после разработки?
Лучше да. Разработка и поддержка — разные этапы. После запуска нужно отдельно оформить сопровождение, SLA, оплату, часы поддержки и ответственность.
Что делать, если исполнитель не соблюдает SLA?
Фиксировать заявки, время обращения, время реакции, время восстановления, последствия сбоя, направлять претензию и применять договорные механизмы: сервисные кредиты, неустойку, убытки, расторжение или смену подрядчика.
Когда обращаться к юристу?
Лучше до подписания договора поддержки или SLA. На этой стадии можно прописать измеримые обязательства исполнителя, а не спорить после первого серьезного сбоя.
Связанные материалы