Договор на поддержку сайта: SLA, время реакции и что прописать, чтобы не спорить

Короткий ответ: договор на поддержку сайта должен отвечать на пять вопросов — что входит в работу, как быстро подрядчик реагирует на сбои разной важности, как оплачиваются часы, кто отвечает за бэкапы и хостинг и как уйти, забрав всё своё. Время реакции записывайте отдельно от времени решения, доступность — в минутах простоя, а границу между поддержкой и доработкой — списком примеров. Тогда спорить будет не о чем.

Ниже — разбор пунктов договора сопровождения с примерами формулировок, таблицей приоритетов и чек-листом. Цены здесь не разбираем: из чего складываются ежемесячные расходы, мы подробно посчитали в статье «Сколько стоит поддержка сайта в месяц».

Что входит в поддержку, а что — доработка?

Поддержка сохраняет сайт в рабочем состоянии: устранение сбоев, обновления, мониторинг, мелкие правки контента. Доработка меняет сайт: новый раздел, новая интеграция, редизайн блока. Граница должна быть в договоре списком примеров, иначе любая новая задача превращается в спор «это же входит».

Самый частый конфликт в поддержке не про сбои, а про объём. Заказчик считает, что за абонентку можно попросить «небольшой калькулятор на главную», подрядчик считает это отдельной задачей с оценкой. Оба по-своему правы, если в договоре написано только «техническая поддержка сайта».

Рабочий вариант — три списка в приложении к договору:

• Входит всегда: восстановление работы после сбоя, обновление движка и модулей, продление и проверка SSL, контроль бэкапов, правки текстов и картинок на существующих страницах.
• Входит в пределах лимита часов: новые страницы по готовому шаблону, изменение форм, подключение счётчиков и целей, мелкие правки вёрстки.
• Не входит, оценивается отдельно: новые разделы со своей логикой, интеграции с CRM, 1С или оплатой, редизайн, переезд на другую платформу.

Отдельной строкой стоит записать, как поступать с ошибкой, которую внесла сама поддержка: например, после обновления модуля перестала работать форма. Разумная норма — исправление такой ошибки не списывается из часов заказчика.

Что такое SLA простыми словами?

SLA (Service Level Agreement, соглашение об уровне сервиса) — это приложение к договору, где цифрами записаны правила работы: часы работы поддержки, приоритеты обращений, сроки реакции и решения, целевая доступность сайта, каналы связи и последствия нарушений. Без цифр это не SLA, а пожелание.

Минимальный SLA для небольшого сайта помещается на одну страницу. В нём должно быть:

1. Время работы поддержки. Например, будни с 10:00 до 19:00 по московскому времени. Если нужны выходные и ночи, это отдельное условие и отдельная цена.
2. Канал приёма обращений. Один основной: система задач, почта или телефон для критических сбоев. Обращение, отправленное в личный мессенджер разработчика, не должно считаться поданным.
3. Приоритеты с примерами — какие ситуации считаются критическими, а какие плановыми.
4. Сроки реакции и решения для каждого приоритета, в рабочих часах или календарных.
5. Доступность, если подрядчик отвечает и за хостинг, — в процентах и способ её измерения.
6. Отчётность — что подрядчик присылает раз в месяц: список задач, затраченные часы, инциденты.
7. Последствия нарушений — скидка с абонентской платы, право расторгнуть договор после нескольких нарушений подряд.

Проценты доступности выглядят одинаково, но за ними разное время простоя. Переведите их в минуты, прежде чем подписывать: 99 % звучит солидно, а это до семи часов простоя в месяц.

Доступность	Простой в месяц	Простой в год	Кому обычно достаточно
99 %	до 7 ч 12 мин	до 3 сут 15 ч	Сайт-визитка, лендинг под рекламу, которую можно остановить
99,5 %	до 3 ч 36 мин	до 1 сут 19 ч 48 мин	Корпоративный сайт, на который идут заявки
99,9 %	до 43 мин	до 8 ч 46 мин	Магазин, личный кабинет, сервис с оплатой
99,95 %	до 22 мин	до 4 ч 23 мин	Сервис, простой которого останавливает работу клиентов

Время реакции и время решения — в чём разница?

Время реакции — срок, за который подрядчик подтвердил обращение и начал работу. Время решения — срок, за который сайт снова работает. «Реакция 15 минут» без срока решения ничего не обещает: можно ответить «принято» и чинить три дня, формально не нарушив договор.

Поэтому для каждого приоритета пишите обе цифры. И ещё три детали, на которых чаще всего спорят:

• С какого момента идёт время. С момента регистрации обращения в системе задач, а не с момента, когда разработчик его прочитал.
• Рабочие или календарные часы. «4 часа» в пятницу в 18:00 при рабочих часах означают понедельник, при календарных — вечер пятницы. Это нужно записать словами.
• Обходное решение. При критическом сбое разумно разделить срок восстановления работы (например, откат на прошлую версию) и срок постоянного исправления. Иначе подрядчик вынужден чинить быстро и плохо.

Кто назначает приоритет, тоже стоит записать. Обычно это делает заказчик при подаче обращения, а подрядчик вправе его изменить по критериям из договора и сообщить об этом. Без критериев каждый сбой у заказчика будет критическим, а у подрядчика — обычным.

Таблица ниже — модель, с которой удобно начинать переговоры. Цифры в ней — пример, их нужно подогнать под ваш сайт и под часы работы подрядчика, а не переносить как есть.

Приоритет	Пример	Время реакции	Цель по решению
Критический	Сайт не открывается, не проходит оплата, заявки не доходят до CRM	В пределах часа в оговорённое время работы	Обходное решение в тот же день, постоянное — по плану
Высокий	Не работает один раздел, фильтр каталога или форма на одной странице	В течение рабочего дня	1–2 рабочих дня
Обычный	Ошибка вёрстки на одном экране, неверный текст, битая ссылка	1 рабочий день	По очереди задач, обычно в течение недели
Плановый	Новый блок, раздел, правка дизайна, новая интеграция	Оценка в течение 2–3 рабочих дней	Срок согласуется отдельно для каждой задачи

Абонентская плата или пакет часов?

Абонентка подходит, когда сайту нужен регулярный уход и быстрая реакция на сбои: вы платите за готовность подрядчика работать, даже если месяц прошёл спокойно. Пакет часов или оплата по задачам выгоднее, когда сайт меняется редко и сбой не стоит денег каждый час.

Юридически это разные конструкции. Договор, где вы вносите периодические платежи за право затребовать работу в нужном объёме, — абонентский. По п. 2 ст. 429.4 ГК РФ абонент платит независимо от того, затребовал ли он исполнение, если законом или договором не предусмотрено иное. Значит, если договор абонентский и о переносе ничего не сказано, плата за спокойный месяц не возвращается — перенос часов нужно договорить отдельно. Верно и обратное: если из текста неясно, абонентский договор или нет, Пленум ВС РФ (постановление от 25.12.2018 № 49, п. 33) указывает, что нормы ст. 429.4 не применяются. Поэтому слово «абонентский» и порядок оплаты стоит записать прямо.

Что прописать про часы:

• сколько часов входит в месяц и какой шаг учёта: 15 минут, полчаса или час;
• переносятся ли неиспользованные часы и на сколько месяцев — частый компромисс: не больше месячного объёма и не дольше одного месяца;
• сколько стоит час сверх лимита и нужна ли оценка до начала работ сверх лимита;
• как подтверждается списание: отчёт по задачам с часами, который вы можете оспорить в оговорённый срок;
• входят ли в лимит сами переговоры и созвоны.

Последний пункт кажется мелочью, но именно он съедает часы на небольших абонентках: полчаса созвона на каждую правку текста за месяц складываются в рабочий день.

Кто отвечает за бэкапы и хостинг?

Тот, кто прямо назван в договоре. Если там написано только «поддержка сайта», при потере данных каждая сторона будет уверена, что копии делала другая. Запишите, кто делает резервные копии, как часто, где они хранятся, сколько дней живут и как часто проверяется восстановление.

Копия, из которой ни разу не восстанавливали сайт, — это надежда, а не бэкап. Хорошая формулировка выглядит так: ежедневная копия файлов и базы, хранение 14 дней, копии лежат не на том же сервере, что сайт, раз в квартал подрядчик восстанавливает копию на тестовый сервер и сообщает результат.

С хостингом и доменом правило другое: договор с провайдером и регистратором оформляйте на вашу компанию, а подрядчику давать доступ, который можно отозвать. Почему это важно и как оформить, разобрано в статье «На кого оформлять домен и хостинг сайта». В договоре поддержки тогда остаётся пункт: подрядчик следит за сроками продления и предупреждает заранее, а оплачиваете вы.

Если сайт хранит заявки, заказы или личные кабинеты, у подрядчика будет доступ к персональным данным клиентов. По ч. 3 ст. 6 закона 152-ФЗ оператор поручает такую обработку на основании договора — с согласия субъекта данных, если федеральный закон не предусматривает иное. В поручении должны быть перечень данных и действий с ними, цели, обязанность соблюдать конфиденциальность, меры защиты по ст. 19 и обязанность по запросу оператора подтверждать соблюдение требований. Это можно оформить разделом договора поддержки или отдельным документом — но не пропустить.

Как прекратить договор и забрать сайт?

Заказчик вправе отказаться от договора услуг в любой момент, оплатив исполнителю фактически понесённые расходы — это ст. 782 ГК РФ. Поэтому главное в договоре не право уйти, а порядок: срок уведомления, что подрядчик передаёт и в какие сроки.

Пункт о выходе стоит расписать по шагам:

1. Срок уведомления — например, 30 дней. Столько же разумно дать и подрядчику, если уходит он: вам нужно время найти замену.
2. Передача доступов: хостинг, сервер, панель сайта, репозиторий, почта, счётчики, CRM, платёжный кабинет. Подрядчик подтверждает, что его учётные записи удалены или переданы.
3. Передача кода и данных: актуальная версия в вашем репозитории, свежая копия базы, список сторонних сервисов и где оплачивается каждый.
4. Короткая документация: как развернуть сайт, где лежат настройки, какие задачи по расписанию работают на сервере.
5. Расчёт: что оплачивается за неполный месяц и что происходит с перенесёнными часами.

Если код изначально лежит в вашем репозитории, а доступы оформлены на вас, выход занимает дни, а не месяцы. Что ещё проверить на случай, если подрядчик перестанет отвечать, — в статье «Что будет с сайтом, если студия пропадёт». О правах на код при смене подрядчика — в материале «Кому принадлежит код сайта после разработки».

Чем гарантия по договору разработки отличается от поддержки?

Гарантия — это обязанность разработчика бесплатно исправить свои ошибки в течение гарантийного срока. Поддержка — отдельная платная услуга. Если их смешать, вы либо платите абонентку за то, что должны исправить бесплатно, либо ждёте бесплатного исправления того, что гарантией не покрыто.

В наших типовых договорах на разработку гарантия — 30 календарных дней с даты акта: ошибки, возникшие по вине исполнителя, устраняются безвозмездно. Гарантия не распространяется на изменения, внесённые заказчиком или третьими лицами, и на сбои сторонних сервисов. Если в эти 30 дней действует и договор поддержки, запишите, что гарантийные исправления не списываются из часов.

Как поддержка устроена в Roboweb.team?

Поддержка у нас стоит от 7 900 ₽ в месяц по абонентке или оплачивается разово по задачам; состав абонентки считаем после брифа. Работаем в рабочее время. Задачи ставятся не в переписке, а на доске проекта в личном кабинете заказчика.

Доска разбита на колонки «Пожелания → Бэклог → В работе → На проверке → Готово»: видно, что принято, что в работе и что ждёт вашей проверки. Готовую задачу вы принимаете сами или возвращаете на доработку. Сразу после запуска мелкие правки бесплатны: 7 дней для лендинга, бота, интеграций и ИИ-ассистента, 14 дней для магазина, веб-приложения и мобильного приложения, 1 месяц для корпоративного сайта. Подробнее о формате — на странице поддержки и развития.

Если вашему проекту нужна реакция ночью или в выходные — например, магазин с оплатой и обменом с 1С, — скажите об этом до подписания: обсудим, возможно ли это для вашего проекта и на каких условиях, и запишем в договор отдельно.

Когда подробный SLA не нужен и какие ошибки встречаются?

Подробный SLA не нужен сайту-визитке, который меняется пару раз в квартал и не принимает оплату: хватит оплаты по задачам и пункта о сроке ответа. Многоуровневые приоритеты и штрафы оправданы там, где час простоя — это потерянные заказы или остановленная работа ваших клиентов.

Ошибки, которые встречаются чаще всего:

• Доступность 99,9 % при хостинге заказчика. Подрядчик не может отвечать за сервер, которым не управляет. Либо хостинг в зоне его ответственности, либо доступность вообще не пишется.
• Круглосуточная реакция за абонентку рабочего дня. Такая цифра в договоре не будет выполняться — это лишь повод для спора.
• Штрафы без верхней границы. Подрядчик заложит риск в цену или откажется подписывать. Скидка с абонентки в пределах её суммы для обеих сторон честнее неограниченной неустойки.
• Нет канала для критических сбоев. Обращение тонет в общей очереди задач.
• Нет отчёта по часам. Через полгода невозможно понять, за что платили.

Чек-лист пунктов договора

Перед подписанием пройдитесь по списку: если пункта нет или он сформулирован общими словами, попросите дописать. Хороший подрядчик сам предложит такие формулировки — отказ их обсуждать тоже информация.

1. Состав работ: что входит всегда, что в пределах часов, что оценивается отдельно.
2. Часы работы поддержки и часовой пояс.
3. Канал подачи обращений и отдельный канал для критических сбоев.
4. Приоритеты с примерами и кто их назначает.
5. Время реакции и время решения для каждого приоритета, рабочие или календарные часы.
6. Доступность в процентах и способ измерения — только если подрядчик отвечает за хостинг.
7. Лимит часов, шаг учёта, перенос остатка, цена часа сверх лимита.
8. Ежемесячный отчёт: задачи, часы, инциденты.
9. Резервные копии: кто, как часто, где, сколько хранятся, проверка восстановления.
10. Продление домена, хостинга и SSL: кто следит и кто платит.
11. Поручение на обработку персональных данных, если у подрядчика есть к ним доступ.
12. Гарантийные исправления не списываются из часов.
13. Последствия нарушения SLA и их предел.
14. Выход из договора: срок уведомления, передача доступов, кода, базы и документации.
15. Претензионный порядок и срок ответа на претензию.

Если вы ещё выбираете подрядчика на разработку, эти же пункты стоит обсудить заранее: как будет устроена поддержка после запуска, выясните до предоплаты. Что проверить у студии до первого платежа — в статье «Как проверить студию разработки до предоплаты».

Короткие ответы на частые вопросы

Что такое SLA в договоре на поддержку сайта?

Это приложение к договору, где цифрами записано, как быстро подрядчик отвечает на обращения разной важности, в какие часы он работает, как считается доступность сайта и что будет при нарушении сроков.

Чем время реакции отличается от времени решения?

Время реакции — срок, за который подрядчик подтвердил обращение и начал работу. Время решения — срок, за который сайт снова работает. В договоре нужны обе цифры, иначе «ответили за 15 минут» формально выполнит условие при сайте, лежащем сутки.

Можно ли отказаться от договора поддержки досрочно?

Да. По ст. 782 ГК РФ заказчик вправе отказаться от договора возмездного оказания услуг, оплатив исполнителю фактически понесённые расходы. В договоре стоит прописать срок уведомления и порядок передачи доступов и документации.

Сгорают ли неиспользованные часы поддержки?

Зависит от договора. Если это абонентский договор, по ст. 429.4 ГК РФ плата вносится независимо от того, были ли запросы, если договор не говорит иное. Перенос часов на следующий месяц и его лимит нужно записать явно.

Гарантия и поддержка — это одно и то же?

Нет. Гарантия по договору на разработку — бесплатное исправление ошибок исполнителя в течение срока гарантии. Поддержка — отдельная платная услуга: обновления, мониторинг, правки и новые задачи.

Сколько стоит поддержка сайта в Roboweb.team?

От 7 900 ₽ в месяц по абонентке или разово по задачам. Состав абонентки для конкретного сайта считаем после брифа.

Услуги и кейсы по теме: поддержка сайта от 7 900 ₽/мес · цены и сроки