Техническое сопровождение сайта с фиксированным перечнем задач

Что входит в перечень, как оформить договором и когда этот формат выгоднее абонентки или SLA

Техническое сопровождение сайта с фиксированным перечнем задач — это формат работы, при котором в договоре или приложении к нему заранее прописан закрытый список работ (мониторинг, обновления CMS, резервное копирование, контроль домена и SSL, мелкие правки), а всё, что выходит за этот список, оформляется отдельным техническим заданием и оплачивается дополнительно [1][2]. Такой формат отличается от «абонентки» с пулом часов и от SLA-поддержки прежде всего границей ответственности: заказчик заранее знает, что именно будет сделано, а что — нет [3][4]. Единственное существенное условие такого договора по гражданскому законодательству — предмет, то есть согласованный перечень действий исполнителя; расплывчатая формулировка предмета — главный источник споров [5][6].

Кому и зачем нужна эта статья

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

Статья разбирает, чем формат с фиксированным перечнем задач отличается от смежных моделей сопровождения, что обычно входит в такой перечень, как его правильно оформить с учётом норм ГК РФ, какие ошибки чаще всего приводят к спорам, и когда вместо регулярного сопровождения достаточно одной точечной работы за фиксированную цену.

Что такое сопровождение с фиксированным перечнем задач

Технически «сопровождение сайта» — собирательное понятие: в него в разных компаниях включают то, что угодно, от мониторинга сервера до наполнения каталога и продвижения [7]. Поэтому смысловое ядро формата — не набор конкретных работ, а способ их зафиксировать: закрытый, перечисленный список действий, который исполнитель обязан выполнять регулярно за согласованную плату, и прямой запрет требовать от исполнителя работ, не описанных в этом списке [1][2].

Формулировка в типовых договорах звучит примерно так: заказчик не вправе требовать от исполнителя выполнения работ, не описанных в соответствующем разделе договора; дополнительные работы проводятся по мере необходимости и оформляются отдельным дополнительным соглашением, техническим заданием и сметой, которые подписывают обе стороны [1][2]. Это и есть юридическая суть фиксированного перечня: он одновременно очерчивает обязанности исполнителя и защищает его от бесконечного расширения задач без дополнительной оплаты.

Практикующие юристы, готовящие такие договоры, обычно советуют разносить общий (рамочный) текст договора и конкретный состав работ по разным документам: рамочная часть одинакова для всех клиентов, а перечень услуг, сроки и стоимость выносятся в приложение или спецификацию, которую проще менять без переподписания всего договора [8][9]. Такая спецификация может называться «Заказ», «Приложение №1» или «Спецификация услуг» — суть одна: это список конкретных пунктов, по которому и заказчик, и исполнитель одинаково понимают объём обязательств [8][9].

Как это устроено на практике

Обычно формат фиксированного перечня задач выстраивается в несколько шагов.

Сначала стороны фиксируют исходное состояние сайта: какая CMS используется, какие модули и интеграции подключены, кто отвечает за хостинг и домен. Дальше согласовывается сам перечень работ — либо в тексте основного договора, либо, что удобнее для последующих изменений, в отдельном приложении [9][10]. По каждому пункту разумно сразу договориться о периодичности (ежедневно, еженедельно, ежемесячно) и о результате, который подтверждает выполнение — отчёт, скриншот мониторинга, акт.

Сдача работ по регулярному сопровождению чаще всего происходит помесячно: по итогам периода исполнитель передаёт акт с перечнем выполненных работ, а заказчик либо подписывает его, либо направляет мотивированный отказ в оговорённый срок; если возражений нет, работа считается принятой и подлежит оплате [2][11]. Именно поэтому формулировка перечня работ в договоре и в акте должна быть достаточно конкретной — не «техническая поддержка», а, например, «еженедельная проверка резервных копий и контроль срока действия SSL-сертификата» [12].

Если у заказчика возникает задача за пределами согласованного перечня — новый раздел сайта, доработка, требующая изменения программного кода интеграции, — это не расширяет действующий договор автоматически. Такие работы оформляются отдельным техническим заданием, часто с отдельной сметой, и оплачиваются сверх суммы регулярного сопровождения [1][13]. Разработчики веб-практики прямо предупреждают: смешивать в одном договоре создание сайта и его последующее сопровождение — плохая идея, так же как объединять сопровождение с наполнением контентом или продвижением: у этих работ разная природа, разные сроки и разная ответственность сторон [14].

Российская специфика

Правовая база. Договор на техническое сопровождение сайта — разновидность договора возмездного оказания услуг и регулируется главой 39 Гражданского кодекса РФ [5][12]. По ст. 779 ГК РФ исполнитель обязуется по заданию заказчика оказать услуги, а заказчик — оплатить их; правила главы 39 применяются к информационным, консультационным и аналогичным услугам, если иное прямо не предусмотрено другими главами кодекса [15]. Судебная практика последовательно указывает, что единственное существенное условие такого договора — предмет: стороны должны достичь согласия по кругу действий исполнителя или по конкретной работе, которая подлежит выполнению [6]. Срок оказания услуг существенным условием, как правило, не признаётся [6], а вот отсутствие ясного перечня работ создаёт риск того, что договор в принципе будет признан незаключённым либо возникнут споры о том, что именно должен был сделать исполнитель [6].

Акт и первичные документы. Гражданский кодекс не обязывает стороны договора услуг оформлять акт по каждому периоду, но на практике без него заказчик не сможет учесть расходы для целей налогообложения, а исполнитель — доказать факт оказания услуг при споре; поэтому акт по итогам месяца или иного согласованного периода фактически стал деловым стандартом [12]. Многие компании переводят подписание таких актов и договоров в электронный документооборот (ЭДО), что ускоряет ежемесячную приёмку работ по сопровождению.

Персональные данные и формы на сайте. Если в фиксированный перечень задач входит работа с формами обратной связи, личным кабинетом или интеграциями с CRM и 1С, стоит отдельно предусмотреть контроль соответствия требованиям 152-ФЗ «О персональных данных»: согласия на обработку персональных данных, политику конфиденциальности, корректную настройку передачи данных между сайтом и внешними системами. Нарушения в этой части чаще обнаруживаются не на этапе разработки, а именно в процессе сопровождения, когда в формы или интеграции вносятся изменения без пересмотра совместимости с требованиями закона.

Российские CMS и хостинг. Значительная часть коммерческих сайтов в России работает на «1С-Битрикс», и у самого вендора есть публичный регламент технической поддержки с чёткими метриками: например, максимальное время реакции на обращение может быть ограничено 8 рабочими часами по стандартному тарифу или не превышать одного часа для специальных обращений по купону, при этом такая поддержка не покрывает работы по доработке продукта, бухгалтерские, юридические и иные нетехнические вопросы [16]. Это хороший ориентир того, как выглядит чётко разграниченный перечень услуг у крупного российского вендора, и того, что даже официальная техподдержка платформы не подменяет собой сопровождение конкретного сайта на этой платформе.

Фиксированный перечень задач и другие форматы сопровождения

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

Разовые работы. Заказчик обращается по конкретному поводу — упала форма, не проходит оплата, нужно поставить редирект. Оплата за фактически выполненную работу, без регулярных обязательств сторон [3].

Сопровождение с фиксированным перечнем задач. Регулярная плата за закрытый список плановых работ (мониторинг, бэкапы, обновления, мелкие правки в рамках лимита), всё сверх перечня — по отдельному ТЗ и смете [1][2][13]. Стоимость базового пакета такого типа на рынке обычно начинается от 10–15 тысяч рублей в месяц за минимальный набор (мониторинг, бэкапы, обновления, небольшие правки) и растёт в зависимости от объёма работ и числа привлечённых специалистов [17].

Абонентское обслуживание с пулом часов. Заказчик оплачивает фиксированное количество часов в месяц, которые могут расходоваться на разные виды работ — от технических до контентных, — в границах пула; крупные задачи оцениваются и согласовываются отдельно [3][18]. Разница с фиксированным перечнем задач в гибкости: здесь состав работ не закрыт, а лимитирован временем.

SLA-поддержка. Отдельное соглашение об уровне сервиса, которое фиксирует не только состав работ, но и измеримые метрики качества — время реакции на обращение, время устранения инцидента, доступность сайта — обычно с разделением приоритетов инцидентов и, в некоторых случаях, компенсациями за нарушение метрик [4][19][20]. SLA обычно оформляется как дополнение к основному договору [19] и стоит дороже: например, переход на строгие метрики (99,9% доступности, реакция в течение 15 минут) может увеличивать стоимость поддержки на 50–100% по сравнению с базовым форматом, а круглосуточный режим 24×7 обходится в два-три раза дороже, чем поддержка в рабочее время (8×5) [20][21].

Ядро плановых работ у всех этих форматов почти всегда совпадает — мониторинг доступности, обновления CMS и модулей, резервное копирование с проверкой восстановления, устранение мелких ошибок и поддержка типовых интеграций; отличаются они тем, как оформлено взаимодействие сторон, какой объём закрыт ценой и какие метрики качества гарантированы [22]. Поэтому выбор формата — это в первую очередь выбор способа управления рисками и предсказуемости, а не выбор принципиально разных технических работ.

Что обычно входит в фиксированный перечень

Состав перечня всегда индивидуален для конкретного сайта, но в большинстве типовых договоров и практических материалов повторяется одна и та же основа:

• мониторинг доступности сайта и сервера, отслеживание ошибок 4xx/5xx и скорости загрузки [22][23];
• контроль срока действия домена, хостинга и SSL-сертификата, продление при необходимости [24][25];
• установка обновлений CMS, плагинов и модулей, включая обновления безопасности [13][25];
• резервное копирование данных и файлов сайта с определённой периодичностью и хранением копий в течение согласованного срока, а также периодическая проверка того, что из бэкапа действительно можно восстановиться [22][25];
• поиск и исправление технических ошибок и багов в коде сайта [12][13];
• контроль работы форм обратной связи, оформления заказа, оплаты и типовых интеграций (CRM, 1С, эквайринг, службы доставки) [22][26];
• консультирование сотрудников заказчика по работе с сайтом [24];
• мелкие правки контента и интерфейса в рамках небольшого лимита времени, без нового технического задания [22].

За пределами этого ядра почти всегда остаются: изменение дизайна, добавление новых разделов и модулей, требующих доработки программного кода, глубокий аудит безопасности, миграция на другой хостинг или CMS, продвижение и SEO-работы — такие задачи вынесены в отдельные договоры или дополнительные соглашения с отдельным ТЗ и оплатой [13]. Наличие этой границы в самом перечне — не формальность, а способ избежать ситуации, когда одна и та же фиксированная сумма должна покрывать и плановое обслуживание, и незапланированную разработку.

Практические этапы: как составить и оформить перечень

Шаг 1. Зафиксировать исходное состояние. До подписания договора стоит провести короткий технический аудит: какая CMS, какие интеграции, кто хостинг-провайдер, когда истекают домен и SSL, есть ли актуальные резервные копии. Это исходная точка, от которой считается объём работ.

Шаг 2. Составить перечень работ и вынести его в приложение. Юридически проще прописать общие условия (порядок оплаты, ответственность, конфиденциальность) в основном тексте договора, а конкретный состав услуг, периодичность и лимиты — в отдельном приложении или спецификации, которую можно обновлять без переподписания всего договора [8][9][10]. Формулировки должны быть предметными: не «техническая поддержка сайта», а конкретное действие, периодичность и критерий выполнения [12].

Шаг 3. Договориться о процедуре приёмки. Обычно это ежемесячный акт с перечнем выполненных работ и правом заказчика на мотивированный отказ в оговорённый срок; если отказа нет, работа считается принятой [2][11]. Стоит заранее решить, в каком канале и формате подрядчик отчитывается о работах — это может быть простой список в письме, таблица в трекере или отдельный отчёт.

Шаг 4. Прописать порядок работы с задачами вне перечня. Указать в договоре прямо: заказчик не вправе требовать выполнения работ, не описанных в согласованном перечне; дополнительные работы оформляются отдельным дополнительным соглашением с техническим заданием и сметой [1][13]. Это защищает обе стороны — заказчика от произвольного расширения стоимости, исполнителя от бесплатного расширения обязательств.

Шаг 5. Отдельно решить вопрос доступов. Для планового сопровождения обычно нужны учётные данные к административной панели сайта, хостингу и, при необходимости, FTP/SSH; передавать их стоит после подписания договора, а не на этапе обсуждения задачи.

Шаг 6. Пересматривать перечень по мере роста сайта. Если сайт активно развивается — добавляются новые интеграции, растёт каталог, — фиксированный перечень стоит периодически пересматривать вместе с ценой, а не оставлять неизменным на годы вперёд.

Ограничения, ошибки и риски

Расплывчатые формулировки. Формулировка вроде «техническая поддержка сайта» без конкретизации периодичности, состава действий и режима реакции — частая причина споров о том, что именно обязан был сделать исполнитель; юристы прямо рекомендуют заменять общие фразы конкретным описанием действия и условий его выполнения [12][6].

Отсутствие акта или процедуры приёмки. Хотя закон не требует акта как обязательного документа для договора услуг, его отсутствие резко ослабляет позицию обеих сторон в возможном споре и мешает учитывать расходы для налоговых целей [12].

Смешение сопровождения с разработкой и наполнением в одном договоре. Специалисты по договорной работе в digital советуют не объединять создание сайта с его последующим обслуживанием, а наполнение контентом, изготовление графики и продвижение — оформлять отдельными договорами: у этих работ разная динамика загрузки, ответственность и порядок оплаты [14].

Игнорирование лимита на неучтённые уточнения. Даже при чётком перечне у заказчика периодически возникают мелкие уточнения, прямо не описанные заранее (добавить поле в форму, изменить формат уведомления). Разумная практика — заранее закладывать в фиксированную стоимость небольшой резерв времени именно на такие уточнения, отдельно от объёма основных работ и без изменения срока их выполнения [27][28].

Непроверенные резервные копии. Наличие расписания бэкапов не гарантирует, что восстановление реально сработает; практика периодической тестовой раскатки бэкапа на отдельном (staging) окружении снижает риск того, что в критический момент архив окажется повреждённым или неполным [22].

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

Как выбрать формат сопровождения

Фиксированный перечень задач обычно подходит для сайтов со стабильным функционалом, где основная цель — не допустить деградации (взлом, устаревание CMS, потеря бэкапов, истечение SSL), а не постоянно развивать новый функционал. Это разумный выбор для корпоративных сайтов, лендингов, небольших интернет-магазинов с устоявшимся набором интеграций.

Абонентка с пулом часов лучше подходит, если сайт активно меняется — часто нужны новые страницы, доработки, эксперименты с контентом, — а конкретный состав работ месяц от месяца не совпадает.

SLA-поддержка оправдана там, где простой сайта прямо и быстро конвертируется в потери — крупный интернет-магазин, сервис с онлайн-оплатой, сайт с высоким трафиком, — и где бизнесу нужны не просто плановые работы, а гарантированные измеримые метрики реакции и восстановления.

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

Как может помочь «Пятый фактор»

«Пятый фактор» работает преимущественно в логике фиксированного, заранее согласованного объёма работ: по каждой услуге на сайте компании заранее опубликован состав работ, результат и цена, которая фиксируется после бесплатной первичной проверки и не меняется до сдачи согласованного объёма [29]. В стоимость таких услуг закладывается небольшой резерв рабочего времени на связанные уточнения, которые могут появиться уже после согласования задачи — например, добавить поле или уточнить условие обработки данных; это отдельный запас, который не подменяет собой основной объём и не меняет срок выполнения согласованной задачи [27][28].

Если у сайта уже есть чёткое понимание, какие технические задачи требуют решения — ускорение интернет-магазина на 1С-Битрикс, техническое SEO, интеграция с 1С, банком, CRM или государственной информационной системой, контроль соответствия сайта и форм требованиям 152-ФЗ, — команда «Пятого фактора» может изучить задачу, зафиксировать объём работ и результат и выполнить её за согласованную фиксированную стоимость. Если вместо этого нужна именно регулярная эксплуатационная поддержка сайта с постоянным набором плановых работ, обсуждение стоит начинать с того же вопроса, который разобран в статье: какой закрытый перечень задач имеет смысл прописать в договоре и какая периодичность нужна конкретному сайту.

Вывод

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

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

Источники

[1] habr.com — Договор на техническое обслуживание и поддержку сайта — https://habr.com/ru/post/73078/

[2] amulex.ru — Версия 2025: Договор на информационное сопровождение сайта — https://amulex.ru/docs/contracts/services-contract/1592.html

[3] webfull.ru — Поддержка сайтов: разовая поддержка и абонентское обслуживание — https://webfull.ru/podderzhka-saitov/

[4] elma365.com — SLA: что это, примеры, уровень сервиса и отличие от OLA — https://elma365.com/ru/baza-znaniy/sla/

[5] rbc.ru — Договор возмездного оказания услуг: существенные условия, виды, образец — https://www.rbc.ru/life/news/689691ef9a7947368dcf74af

[6] cyberleninka.ru — Договор возмездного оказания услуг как вид обязательств по оказанию услуг в гражданском праве России — https://cyberleninka.ru/article/n/dogovor-vozmezdnogo-okazaniya-uslug-kak-vid-obyazatelstv-po-okazaniyu-uslug-v-grazhdanskom-prave-rossii

[7] intellectprava.ru — Договор на сопровождение сайта — https://intellectprava.ru/soprovozhdenie-sajta

[8] workspace.ru — Договор на техническую поддержку сайта — https://workspace.ru/docs/dogovor-na-tekhnicheskuyu-podderzhku-sayta/

[9] documentoved.ru — Рекомендации по составлению договора обслуживания сайта — https://www.documentoved.ru/documents/special-documents/dogovor-na-obslujivanie-saita

[10] dogovor24.ru — Договор на техническую поддержку сайта — https://dogovor24.ru/document/dogovor-na-tekhnicheskuyu-podderzhku-sayta

[11] els24.com — Образец договора на техническое обслуживание и поддержку веб-сайта между юридическими лицами — https://els24.com/docs/dogovor-okazaniya-uslug/645-dogovor-na-tekhnicheskoe-obsluzhivanie-i-podderzhku-veb-sayta/

[12] allcontract.ru — Договор оказания услуг 2026 — образцы, гл. 39 ГК — https://allcontract.ru/articles/dogovor-okazaniya-uslug

[13] uristhome.ru — Пример договора оказания услуг по техническому обслуживанию и поддержке веб-сайта — https://uristhome.ru/document/20/dogovor-okazaniya-uslug-po-tekhnicheskomu-obsluzhivaniyu-i-podderzhke-veb-saita

[14] habr.com — о раздельных договорах на создание и поддержку сайта — https://habr.com/en/articles/24131

[15] consultant.ru — ГК РФ Статья 779. Договор возмездного оказания услуг — https://www.consultant.ru/document/cons_doc_LAW_9027/a397ec4ca2dd0c96c211ee4e4436628f0cf581a3/

[16] 1c-bitrix.ru — Регламент работы службы технической поддержки — https://www.1c-bitrix.ru/support/sla.php

[17] mwi.me — Обслуживание сайтов: тарифы, услуги и выбор подрядчика 2026 — https://mwi.me/marketing-guides/obsluzhivanie-saytov/

[18] bizopt.md — Обслуживание веб-сайтов — поддержка, обновления и разработка — https://bizopt.md/ru/obsluzhivanie-veb-sajtov/

[19] diadoc.ru — SLA — соглашение об уровне сервиса — https://www.diadoc.ru/features/sla-agreement

[20] mwi.me — SLA-поддержка: полный гайд по выбору модели в 2026 году — https://mwi.me/marketing-guides/sla-podderzhka/

[21] surf.ru — SLA поддержка: что это и как составить [2026] — https://surf.ru/sla-podderzhka/

[22] kalinkindev.ru — Комплексное обслуживание сайта: что входит и сколько стоит — https://kalinkindev.ru/blog/kompleksnoe-obsluzhivanie-sayta/

[23] ilyaguev.ru — Что входит в обслуживание сайта: список работ и зачем это нужно — https://ilyaguev.ru/obzory/chto-vkhodit-v-obsluzhivanie-sajta-spisok-rabot-i-zachem-eto-nuzhno

[24] rus-in.com — Техническое сопровождение сайта — https://rus-in.com/services/tekhnicheskaya-podderzhka/support-service/

[25] maximov.by — Обслуживание сайта: что входит и сколько стоит — https://maximov.by/website-maintenance-guide-ru.html

[26] netlab-com.ru — Техническая поддержка сайтов 24/7 по SLA — https://netlab-com.ru/services/tekhnicheskaya-podderzhka-saytov-24-7-po-sla/

[27] 5factor.ru — Исправление soft 404 в Google — резерв незапланированных работ — https://5factor.ru/uslugi/tehnicheskoe-seo/ispravlenie-soft-404-google-search-console/

[28] 5factor.ru — Проверка адресов по ФИАС API — резерв незапланированных работ — https://5factor.ru/uslugi/integracii-i-avtomatizaciya/proverka-adresov-fias-api/

[29] 5factor.ru — главная страница, модель фиксированной цены и этапов работы — https://5factor.ru/