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

В договоре на техподдержку сайта фиксируют пять вещей. Объём часов в месяц и судьбу остатка. Время реакции по приоритетам — это и есть SLA (соглашение об уровне обслуживания). Кто владеет доступами и кодом. Как делаются и проверяются резервные копии. И как расторгнуть договор без потери сайта. Цены пакетов на 2026 год — в таблице ниже, а полный список пакетов техподдержки с фиксированным временем реакции — на странице услуги.

Пять пунктов, без которых договор не защищает

Устная договорённость «мы быстро реагируем» ничего не гарантирует. В момент, когда сайт лежит и заказы не оформляются, выясняется, что «быстро» у подрядчика и у вас — разные числа. Договор — это не формальность для бухгалтерии. Это список конкретных обязательств, которые можно предъявить.

Пять пунктов из вступления — это минимум. Дальше в статье — как выбрать формат оплаты, как читать пакет с прода, что такое приоритеты P1–P4, кто отвечает за доступы и копии, и готовый шаблон-оглавление на 12 пунктов, по которому можно свериться с текстом своего договора.

Абонентская плата, пакет часов или оплата за задачу

Формат оплаты определяет, кто несёт риск простоя — вы или подрядчик.

Таблица 1 — три формата: при каком объёме задач что выгоднее

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

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

Часы, реакция и цена в месяц: как читать пакет

Ниже — три пакета техподдержки с прода Toimi, цены сверены на 29.09.2026.

Таблица 2 — пакеты поддержки

Цены указаны без НДС: ставка НДС 5% предъявляется дополнительно и включается в счёт (данные FAQ страницы /prices/, сверено 29.09.2026). При остановке проекта пакет 50 часов даёт паузу на 2 недели, пакет 100 часов — на 3 недели с переносом остатка часов; у пакета 20 часов такой опции нет. Разовые работы вне пакета — с той же страницы: перенос на новый хостинг от 7 000 ₽, разовое резервное копирование от 3 500 ₽, технический аудит сайта от 56 000 ₽, тестирование функционала от 10 500 ₽, интеграция с внешним сервисом от 10 500 ₽.

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

SLA: время реакции и время решения — не одно и то же

Время реакции — это когда специалист откликнулся на заявку и начал разбираться. Время решения — когда проблема фактически устранена. Разница критична: подрядчик может формально уложиться в SLA по реакции и потратить сутки на само исправление, если срок решения нигде не прописан.

Таблица 3 — приоритеты

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

Доступы, код и данные: кто владелец

Перед подписанием договора проверьте один факт: доступы к хостингу, домену и панели администратора должны регистрироваться на аккаунт компании-заказчика, а не подрядчика. Иначе смена исполнителя превращается в переговоры о возврате контроля над собственным сайтом.

В договоре прописывают: кто владеет правами на код после сдачи доработок, в каком виде и в какой срок передаются доступы при расторжении, и что происходит с наработками, сделанными за счёт пакетных часов. Если подрядчик получает доступ к персональным данным пользователей сайта — например, к базе заказов интернет-магазина, — по части 3 статьи 6 закона о персональных данных (152-ФЗ) в договор включают отдельным документом или разделом поручение на обработку персональных данных (текст статьи на consultant.ru).

Резервные копии и мониторинг: что прописать, чтобы копия была проверенной

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

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

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

Поддержка или администрирование

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

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

Шаблон-оглавление договора: 12 пунктов

Сверьте свой проект договора по списку. Рядом — типичная слабая формулировка, которую стоит заменить на конкретную.

1. Предмет и состав работ — в приложении к договору — что входит в регламент техподдержки таблицей работ по пунктам, а не общей фразой «поддержка сайта», под которую можно списать что угодно.
2. Объём часов и перенос остатка — слабая формулировка — «часы в пределах пакета» без цифры; рабочая — точное число часов в месяц и явное условие, переносится остаток на следующий месяц или сгорает.
3. SLA по приоритетам — вместо обещания «реагируем оперативно» в договоре должна стоять таблица с минутами и часами реакции по каждому из приоритетов P1–P4, как в разделе выше.
4. Каналы обращений и часы работы — куда писать при инциденте ночью и в выходные, а не только рабочий адрес почты, который никто не читает после шести вечера.
5. Доступы и их хранение — на чьё юридическое лицо регистрируются хостинг, домен и панель администратора, и где именно хранятся пароли от них.
6. Права на код и доработки — кому принадлежит код после оплаты работ — по умолчанию заказчику, но формулировка должна быть в тексте, а не подразумеваться.
7. Резервные копии и проверка восстановления — частота копирования, срок хранения версий и, отдельной строкой, регулярный тест восстановления, а не разовое обещание при подписании.
8. Мониторинг доступности — каким инструментом отслеживают, что сайт отвечает, какой порог считается инцидентом и кто дежурит ночью.
9. Отчётность — формат и периодичность отчёта: что сделано за период, какие были инциденты и какое было фактическое время реакции по каждому.
10. Персональные данные и конфиденциальность — поручение на обработку по части 3 статьи 6 152-ФЗ, если подрядчик по роду задач видит данные пользователей сайта.
11. Порядок приостановки — на сколько можно поставить пакет на паузу без расторжения и что при этом происходит с остатком оплаченных часов.
12. Расторжение и передача дел — срок уведомления о расторжении, срок передачи доступов и кода, и отсутствие штрафных условий за уход к другому подрядчику.

Юридическая основа самого договора — глава 39 Гражданского кодекса РФ, «Возмездное оказание услуг», статьи 779–783: заказчик оплачивает не результат, а совершение оговорённых действий, и это прямо влияет на то, что можно требовать по факту, если работы выполнены, а желаемый эффект не достигнут (текст статьи 779 ГК РФ на consultant.ru).