За восемь лет разработки я перечитал десятки версий договора обслуживания сайта, и большинство написаны так, чтобы прикрыть подрядчика, а не защитить заказчика. Клиент подписывает документ с формулировкой «техническая поддержка сайта», платит каждый месяц и через полгода узнаёт, что правка баннера в абонемент не входит, а доступы к хостингу оформлены на почту разработчика, которая давно не отвечает. Ниже список пунктов, которые я проверяю в любом договоре на обслуживание, прежде чем подписать его самому или показать клиенту.
9 пунктов договора обслуживания сайта, которые проверяю перед подписанием
Если хотя бы один из пунктов ниже отсутствует или сформулирован обтекаемо, договор стоит вернуть на доработку до подписи.
- Перечень работ - конкретный список того, что входит в абонемент, а не общая фраза «поддержка сайта».
- Сроки реакции (SLA) - отдельно для аварий и для плановых заявок.
- Доступы к хостингу, домену, CMS и репозиторию оформлены на заказчика, а не на исполнителя.
- Резервное копирование - кто делает бэкапы, с какой периодичностью и где они хранятся.
- Обработка персональных данных - где физически находятся серверы с базой клиентов.
- Реакция на заражение сайта - что входит в диагностику и кто платит за восстановление.
- Стоимость доработок сверх абонемента - почасовая ставка или фиксированная цена, а не «по договорённости».
- Ответственность за интеграции - кто чинит связку с эквайрингом, службой доставки или CRM, если у них меняется API.
- Условия расторжения - срок уведомления и порядок передачи проекта.
Перечень работ и сроки реакции: что обязано быть в тексте
Самая частая проблема, которую я вижу в чужих договорах, это расплывчатые формулировки. Заказчик читает «техническая поддержка сайта» и представляет себе что угодно, от правки текста до разработки нового раздела. Подрядчик читает ту же фразу и понимает её как «отвечаю на письма и раз в месяц обновляю плагины». Конфликт заложен уже на этапе подписи.
| Расплывчатая формулировка | Конкретная формулировка |
|---|---|
| Техническая поддержка сайта | Правки текста и изображений до 2 часов в месяц, обновление CMS и плагинов, мониторинг доступности, консультации по контенту |
| Оперативное устранение неисправностей | Реакция на аварию (сайт недоступен, форма не отправляется, оплата не проходит) в течение 4 часов, устранение в течение 24 часов |
| Работы выполняются в разумный срок | Плановая заявка берётся в работу за 1-2 рабочих дня |
В своих договорах на техподдержку я прописываю именно так: часы на правки, отдельный срок реакции на аварию и отдельный на плановую заявку. Абонемент на техническую поддержку у меня стоит от 15 000 ₽ в месяц, и в договоре сразу указано, сколько часов входит и что происходит, если лимит исчерпан раньше конца месяца.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Доступы к хостингу, домену, CMS и репозиторию
Это пункт, из-за которого чаще всего рвутся отношения с подрядчиком. Видел ситуацию, когда владелец сайта на WordPress решил сменить разработчика, а домен оказался зарегистрирован на личную почту прежнего исполнителя, репозиторий лежал в его приватном GitHub-аккаунте, а хостинг был оплачен с карты студии-подрядчика. Формально сайт принадлежал заказчику, фактически он не мог сделать с ним ничего без согласия человека, с которым уже не хотел работать.
В договоре должно быть прямо написано, что домен регистрируется на юрлицо или физлицо заказчика, доступы к хостингу и CMS передаются заказчику при подписании или в течение оговорённого срока, а исходный код хранится в репозитории, к которому у заказчика есть собственный доступ администратора, а не гостевой. Если подрядчик настаивает на том, чтобы всё оставалось «на его стороне ради удобства поддержки», это повод спросить, что произойдёт при расторжении.
Резервные копии и ответственность за данные и вирусы
Договор должен фиксировать периодичность бэкапов, место их хранения и то, что копии реально проверяются на восстановление, а не просто складываются архивом, который никто не открывал год. Отдельно стоит прописать, где физически находятся серверы с персональными данными клиентов, если сайт собирает заказы, телефоны или почту. По 152-ФЗ такие данные должны обрабатываться на серверах в России, и это одна из причин, по которой я не советую заводить контакты покупателей в зарубежных таблицах или базах вроде Google Sheets или Airtable, даже если это кажется удобным для отчётности.
Отдельная тема, которую в договорах часто вообще не упоминают, это заражение сайта. У меня был случай, когда клиент на устаревшей версии WordPress получил редиректы на сторонние ресурсы через взломанный плагин, а его прежний подрядчик разводил руками, потому что в договоре про такие ситуации не было ни слова. Хорошая формулировка описывает, что входит в диагностику при подозрении на заражение и что лечение сайта после заражения, включая чистку файлов, смену доступов и восстановление из чистой копии, оплачивается отдельно от абонемента, поскольку объём работ заранее не известен. У меня такая услуга стоит от 15 000 ₽ и цена зависит от глубины заражения и того, сколько файлов и таблиц базы пришлось восстанавливать.
Доработки сверх абонемента и сторонние интеграции
Абонемент почти никогда не покрывает разработку новых модулей, только текущее сопровождение. Важно, чтобы стоимость доработок сверх абонемента была зафиксирована заранее, а не обсуждалась каждый раз заново. У меня простая правка скрипта на Tilda стоит от 3 000 ₽, а комплексная интеграция вроде связки эквайринга T‑Bank с WooCommerce или расчёта зон доставки СДЭК на Tilda-сайте оценивается от 40 000 ₽, и эти цифры сразу указаны в приложении к договору.
Отдельно стоит прописать ответственность за сторонние интеграции. Эквайринг, СДЭК, CRM, телеграм-бот на aiogram для уведомлений о заказах, сценарий в n8n, который перекладывает заявки из формы в таблицу или CRM, все они завязаны на чужие API, которые меняются без предупреждения подрядчика. Если банк обновил протокол, а СДЭК поменял формат ответа по тарифам, кто-то должен отреагировать в разумный срок, и в договоре должно быть указано, входит ли такая правка в абонементные часы или оплачивается отдельно как аварийная доработка. Если задача разовая и стандартная, часто дешевле не заказывать индивидуальную разработку, а взять готовые скрипты для Tilda, например расчёт зон доставки, вместо того чтобы каждый раз платить за написание с нуля.
Расторжение договора: как передать проект без потерь
Хороший договор описывает не только начало работы, но и её завершение. Срок уведомления о расторжении, обычно 30 дней, даёт обеим сторонам время подготовиться. В момент расторжения подрядчик обязан передать заказчику исходный код, полный доступ к хостингу, домену, CMS, репозиторию и актуальную резервную копию, а не архив полугодовой давности. Если в проекте использовались кастомные скрипты или интеграции, полезно, чтобы к договору прилагалась хотя бы краткая техническая справка о том, что и как настроено, иначе следующий подрядчик потратит несколько часов только на то, чтобы разобраться в чужом коде.
Если сомневаетесь, что действующий договор с текущим подрядчиком закрывает эти девять пунктов, разумнее один раз оплатить разбор документа, чем потом разбираться с последствиями постфактум. Консультация с разбором договора и текущей инфраструктуры сайта у меня стоит от 3 000 ₽.
Частые вопросы
Можно ли обслуживать сайт без официального договора?
Можно, но при первом же споре о том, что входит в оплаченные работы, устная договорённость ничего не доказывает. Особенно это критично для интернет-магазинов и сайтов с эквайрингом, где простой в несколько часов означает прямые потери в деньгах.
Что делать, если подрядчик отказывается передавать доступы?
Если в договоре чётко прописано, что домен и хостинг оформлены на заказчика, отказ передать доступы это нарушение условий договора, и с этим можно идти в претензионном порядке. Именно поэтому пункт про доступы должен быть зафиксирован письменно ещё до начала работ, а не обсуждаться постфактум.
Входит ли лечение сайта от вирусов в абонемент техподдержки?
Обычно нет. Абонемент покрывает плановое сопровождение и мониторинг, а восстановление после заражения это отдельная работа с непредсказуемым объёмом. У меня такая услуга стоит от 15 000 ₽, и итоговая цена зависит от того, сколько файлов и таблиц базы затронуто.
Сколько стоит абонемент на техническую поддержку сайта?
У меня техподдержка стоит от 15 000 ₽ в месяц, конкретная цена зависит от объёма работ, числа правок и того, есть ли в проекте интеграции с CRM, эквайрингом или службами доставки, которые нужно держать под наблюдением.