Что проверить в договоре на техническую поддержку сайта
Практический разбор договора на техническую поддержку сайта: лимит часов, порядок заявок, аварийные сбои, срочные доработки, права на доступы, резервные копии и судьба незакрытых задач после прекращения обслуживания.
ОглавлениеБыстрый переход по разделам статьи.
Практические ориентиры
- В поддержке сайта главный спор не о названии услуги, а о том, что входит в абонентский пакет, а что уходит в отдельную доработку по ТЗ.
- Если в договоре нет нормальной логики по доступам, резервным копиям и передаче админских прав на выходе, конфликт почти всегда вспыхивает уже после прекращения услуг.
- Лимит часов полезен только тогда, когда понятно, как учитываются аварийные задачи, срочные работы и накопившийся остаток по периоду.
Что входит в техподдержку, а что уже отдельная доработка
Для сайта опаснее всего договор, где абонентская поддержка описана общими словами. Пока задачи мелкие, стороны живут мирно. Но как только появляются интеграции, большие правки, срочные баги или запрос на новый функционал, выясняется, что у сторон разное понимание базового пакета.
Поэтому полезно сразу развести регулярную поддержку, аварийные сбои, консультации, резервные копии, обновления системы управления сайтом, мониторинг и отдельные доработки по ТЗ. Тогда спор не переезжает в бесконечную переписку о том, что должно входить в ежемесячный платеж.
- Разведите абонентскую поддержку и отдельные доработки.
- Соберите базовый перечень услуг и критические исключения.
- Не оставляйте аварийные задачи внутри общей расплывчатой формулы.
Как проверить заявки, сроки реакции и порядок закрытия задач
Если техподдержка идет по заявкам, договор должен отвечать на вопрос, где именно они регистрируются, кто вправе их ставить, как считается срок реакции и что считается закрытой задачей. Иначе исполнитель считает задачу завершенной после ответа, а заказчик - только после публикации правки на рабочем сайте.
Для зрелой поддержки важен не только срок исполнения, но и уровень срочности. Критический сбой, обычная правка контента и консультационный вопрос не должны жить по одному режиму. Именно поэтому порядок сроков реакции и категории заявок обычно полезнее общей фразы о разумном сроке.
- Опишите канал заявок и состав обязательных данных.
- Разведите критические сбои, обычные задачи и консультации.
- Определите, что считается закрытием задачи, а не только ответом на нее.
Почему доступы, резервные копии и выходной слой важнее красивых обещаний по срокам
Даже хорошие обещания по срокам слабо работают, если в договоре неясно, кто держит доступы к хостингу, домену, панели администратора, почте, аналитике и резервным копиям. Именно здесь спор после прекращения услуг становится особенно болезненным: сайт еще формально работает, но контроль над инфраструктурой уже размыт.
Поэтому полезно заранее определить, какие доступы должны оставаться у заказчика, кто хранит резервные копии, как проходит смена паролей, в какой срок передаются материалы и что происходит с незакрытыми заявками в последний период сопровождения.
- Соберите карту доступов и владельцев до старта работ.
- Определите режим резервных копий и порядок передачи на выходе.
- Не оставляйте незакрытые задачи и админские права без финальной процедуры.
Публикации, релизы и кто отвечает за падение сайта после изменений
Поддержка сайта почти всегда включает живые изменения: обновления системы управления сайтом, выкладки, правки шаблонов, контентные публикации и подключение внешних сервисов. Если это не развести по уровням риска, исполнитель считает это обычной поддержкой, а заказчик - безопасной рутиной без особых последствий.
Нужен отдельный слой про релизы: кто согласует публикацию, когда делается резервная копия, как проходит откат и что считается дефектом поддержки, а что - риском нового функционала или контента заказчика.
- Как согласуются релизы, обновления и публикации на рабочем сайте.
- Когда подрядчик обязан делать резервную копию и план отката.
- Как разделяются дефект поддержки, новый функционал и контентный риск заказчика.
Смена подрядчика, передача сайта и как не потерять проект на выходе
Самая болезненная часть техподдержки часто наступает в момент смены исполнителя. Если нет нормальной процедуры передачи, заказчик получает сайт, который формально его, но по факту завязан на старого подрядчика: доступы разбросаны, документация неполная, резервные копии не переданы, а незавершенные задачи висят в воздухе.
Поэтому в договоре полезно отдельно проверить финальный пакет передачи: доступы, документацию, список открытых задач, актуальные интеграции и подтверждение, что старый подрядчик действительно отключен без скрытого контроля.
- Какой пакет документов и доступов должен быть передан новому подрядчику или заказчику.
- Как закрываются незавершенные задачи и открытые сбои на дату выхода.
- Кто подтверждает, что старый подрядчик больше не контролирует рабочий контур сайта.
Внешние сервисы, чужие учетные записи и что делать, если половина сайта живет у третьих лиц
Поддержка сайта редко ограничивается одним хостингом и панелью управления. Почта, сервисы ускорения загрузки, метрики, платежные модули, защита от ботов, клиентские системы, внешние интерфейсы обмена и рекламные кабинеты часто оформлены на разных владельцев и подрядчиков. Если этот набор не описан, при конфликте выясняется, что часть критических узлов вообще не контролируется заказчиком.
Поэтому полезно заранее понимать, какие сервисы относятся к периметру поддержки, на чьих учетных записях они находятся и кто обязан обеспечивать их нормальную передачу при смене исполнителя или аварии.
- Какие внешние сервисы и учетные записи входят в периметр сопровождения сайта.
- Кто юридически и технически владеет критичными кабинетами и интеграциями.
- Как передаются и проверяются доступы к внешним сервисам на выходе или при аварийной смене подрядчика.
Падение сайта, ночной сбой и кто реально держит непрерывность работы
Техподдержка сайта по-настоящему проверяется ночью или в пиковый момент продаж, когда сайт падает, каскадно ломается интеграция, корзина перестает оформлять заказы или внешний сервис убивает критичный маршрут. Если договор не различает обычную заявку и сбой, который останавливает бизнес, он бесполезен именно тогда, когда нужен больше всего.
Полезно заранее определить, кто поднимает кризисный режим, какой канал связи считается экстренным, кто принимает решения об откате релиза, временном отключении функционала и включении резервного маршрута. Без этого поддержка превращается в хаотичную переписку на фоне уже идущих потерь.
- Какой сбой считается критичным для бизнеса, а не просто срочной задачей.
- Кто принимает решения об откате, временной заглушке или срочном исправлении на рабочем сайте.
- Как подрядчик и заказчик поддерживают непрерывную связь в период критического падения сайта.
История проекта, рабочая база знаний и как не потерять понимание сайта при смене команды
Даже если доступы формально переданы, сайт может остаться непонятным: нестандартные скрипты без комментариев, неполная карта интеграций, устные договоренности о задачах по расписанию, неочевидная логика выкладок. В такой ситуации новый подрядчик получает не живой проект, а набор входов без знания внутренней истории.
Поэтому полезно заранее определить, какие элементы рабочей базы знаний обязан вести исполнитель: карта интеграций, история релизов, список нестандартных решений, особенности рабочей среды. Это резко снижает зависимость от одного подрядчика, даже если проект технически давно уже на стороне заказчика.
- Какая документация по архитектуре, интеграциям и релизам должна вестись в ходе поддержки.
- Как заказчик получает историю проекта, а не только пароли и доступы.
- Что происходит с рабочей базой знаний при смене команды или резком прекращении услуг.
Выдержки из законов РФ
По договору возмездного оказания услуг исполнитель обязуется по заданию заказчика оказать услуги, а заказчик обязуется оплатить эти услуги.
Норма задает базовую модель техподдержки сайта как услуги, а не как разовой разработки. Практически это означает, что процесс, заявки и приемка должны быть описаны прямо в договоре.
Основание: ГК РФ, статья 779
Важно
Этот материал носит исключительно информационный характер и не является юридической консультацией.
Информация актуальна по состоянию на июнь 2026 г. и подготовлена на основе действующего законодательства Российской Федерации.
Законодательство и правоприменительная практика могут измениться.
Для решения вашей конкретной ситуации обращайтесь к квалифицированному юристу или налоговому консультанту.
Связанные документы
Откройте нужный шаблон и проверьте, внесены ли туда сроки, деньги, уведомления и остальные спорные пункты из статьи.
Связанные материалы
Здесь собраны материалы по соседним ситуациям, чтобы можно было быстро перейти к следующему вопросу без повторов и лишнего поиска.