Какие пункты нужны в договоре на обслуживание сайта

Договор на поддержку обычно подробно расписывает оплату и молчит про аварию. Здесь 8 пунктов, которые я проверяю первыми: вид договора, перечень работ, реакция отдельно от восстановления, приемка, часы, права на код, доступы и выход. С примерами формулировок и проверкой своего договора за полчаса.

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

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

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

Что выяснить у подрядчика до договора

Договор закрепляет то, о чем договорились на словах, поэтому работа над ним начинается раньше, на первой встрече с подрядчиком. Ставку за час я смотрю последней. Владелец компании почти всегда начинает с прайса и сравнивает 2500 руб. с 3500 руб., а через полгода выясняется, что дешевый час тратился на поиски того, кто вообще отвечает за сайт, и на воспоминания, где лежит последняя копия. Ниже 5 вопросов, которые я советую задать каждому кандидату до разговора о цене, и записать ответы: у кого они конкретные, а у кого общие слова, видно сразу.

5 вопросов до разговора о цене

1. За сколько вы отреагируете на аварию и где это записано. Нормальный ответ содержит цифры и ссылку на документ: регламент к договору с перечнем того, что считается аварией. «Мы всегда быстро отвечаем» цифрой не является. Как читать эти цифры, разобрано ниже, в разделе о времени реакции.
2. Кто конкретно будет делать работу. Будет ли у проекта постоянный менеджер и закрепленный разработчик или задачи раздаются тому, кто свободен. Для небольшого сайта второе нормально, если у команды есть общая база знаний о проекте. Для сайта с обменом с 1С и нестандартной логикой закрепленный человек экономит часы: ему не нужно каждый раз заново разбираться, как устроен обмен. Отдельно спросите, не отдает ли подрядчик работу на сторону. Это не преступление, но вы должны знать, у кого окажутся доступы к вашему серверу.
3. У кого будут доступы и резервные копии. Правильный ответ: у вас. Подрядчик, который просит оформить домен на себя «для удобства», сразу уходит из списка: без его участия домен потом на вас не переоформить.
4. Как вы отчитываетесь за часы. Попросите показать пример отчета. Хороший выглядит как список задач, у каждой время и короткое описание результата, еще лучше, если ход задачи и потраченные часы видны онлайн в трекере. Отчет вида «Техническое сопровождение сайта, 10 ч.» оспорить невозможно, и через 3 мес. вы перестанете понимать, за что платите.
5. Можно ли начать с пробного месяца. Месяц работы показывает больше любых презентаций. Уточните минимальный пакет, есть ли гарантия возврата и нужно ли платить за год вперед. Предоплату за год до первого месяца работы я не советую вносить никому, даже со скидкой.

Если хотя бы по 2 вопросам ответ размытый, низкая ставка не спасет. Финалистам я бы дал еще одно задание: короткий аудит сайта до договора. Достаточно доступа на чтение или даже просто адреса. Сильный подрядчик напишет конкретно: «ядро не обновлялось с 2024 года, 3 модуля несовместимы с PHP 8, обновление займет 6–10 ч., начать стоит с копии». Слабый пришлет 20 страниц рекомендаций, которые подходят любому сайту. В Design Lab первичный технический аудит новым клиентам поддержки делаем в подарок: подрядчик, который берет сайт вслепую, потом тратит ваши часы на то, что должен был увидеть до старта.

Проверка партнерского статуса, если сайт на 1С‑Битрикс

Для сайтов на 1С-Битрикс есть проверка, которую можно сделать за минуту и без звонков. Вендор ведет реестр партнеров: на странице «Проверка партнера 1С-Битрикс» можно найти компанию по названию или ИНН и увидеть ее текущий статус, компетенции и портфолио.

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

Статус партнера хорошую поддержку не гарантирует. Он подтверждает другое: компания давно работает с платформой, продает лицензии и проходит требования вендора. Для поддержки важнее, умеет ли команда обновлять сайт штатно, без правок в ядре. Об этом стоит спросить отдельно, а что входит в обслуживание на Битриксе, разобрано в статье о поддержке сайтов на 1С-Битрикс. Для других CMS такого реестра обычно нет, и работают косвенные проверки: сайты, которые подрядчик ведет годами, и возможность поговорить с 1–2 такими клиентами.

Пробный месяц и условия выхода

Пробный месяц имеет смысл, только если вы проверяете в нем то, что пригодится в плохой день. Я бы дал 3 типа задач.

1. Срочную. Возьмите реальную проблему из аудита (сломанная форма, ошибка на странице, долгая загрузка) и поставьте ее с пометкой «срочно». Смотрите, через сколько минут ответят и через сколько часов исправят.
2. Плановую. Небольшая доработка на 3–5 ч.: новый блок на странице, поле в форме, выгрузка. Проверьте, назвали ли оценку до начала работы и уложились ли в нее.
3. Вопрос на подумать. Например, «стоит ли нам переходить на новую версию PHP» или «почему заявки с сайта иногда не доходят до CRM». Тут видно, умеет ли подрядчик объяснять без жаргона и предлагать варианты с ценой.

В конце месяца попросите отчет и сравните его с тем, что видели сами. Если в отчете 10 ч., а вы помните задачи на 4, разговор нужен сразу. Еще одна проверка, о которой часто забывают: напишите подрядчику в выходной, без аварии, просто с вопросом. Если в договоре круглосуточная реакция только на аварии, ответ в понедельник нормален. Если обещали «всегда на связи», проверьте обещание.

Договор на год я бы подписывал только после пробного месяца, а условия выхода из него обсуждал до подписания: срок уведомления, судьбу оплаченного остатка и перечень того, что подрядчик передаст при расставании. Как это записать, разобрано в конце статьи. От списка кандидатов до годового договора при таком порядке уходит 5–7 недель, из них 4 занимает пробный месяц. Кажется долго, но поддержка обычно длится годами, и месяц на проверку окупается тем, что не придется проходить через смену подрядчика еще раз.

Признаки, по которым кандидата стоит вычеркнуть сразу

Некоторые ответы на первой встрече заканчивают разговор. Если слышите что-то из этого списка, дальше можно не сравнивать.

• Домен или хостинг предлагают оформить на себя. За этим стоит зависимость, которую потом придется разрывать.
• Цена названа до того, как кто-то посмотрел сайт. Фиксированный тариф бывает, но объем работ без осмотра сайта оценить нельзя.
• Нет ответа на вопрос, где будут храниться копии. Или ответ «на хостинге, там же все есть».
• Требуют предоплату за год сразу. Скидка за предоплату нормальна после того, как вы поработали вместе.
• Обещают «сделаем все» без единой оговорки. Любая команда чего-то не делает: одни не берут чужие CMS, другие не занимаются рекламой. Если ограничений не называют, их узнаете в процессе.
• Не могут показать ни одного проекта на поддержке дольше 2 лет. Сделать сайт и вести его годами — разные навыки.

И одна мягкая настораживающая вещь: подрядчик ругает предыдущего исполнителя до того, как увидел код. Возможно, он прав. Но профессионал сначала смотрит, потом оценивает. Если кандидат прошел эти проверки, ответы на 5 вопросов пора превращать в текст договора. Дальше по пунктам.

Какой договор вы на самом деле подписываете

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

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

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

Перечень работ и то, что в него не входит

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

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

Цифры в правой колонке — пример, а не норма: частота копий и срок хранения зависят от сайта. Важна сама форма. В ней есть периодичность, место и способ проверки, и по каждой строке можно задать вопрос «сделано или нет».

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

Время реакции и время устранения — это разные цифры

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

Поэтому в нормальном регламенте 3 цифры на каждый приоритет: время реакции, срок восстановления работы (пусть временного, обходным путем) и срок полного устранения причины. И отдельно часы, в которые эти сроки считаются.

Время реакции в таблице взято из нашего регламента: в Design Lab это 15 мин. на аварию и до 1 ч. на задачу, так написано на странице поддержки сайтов. Колонка восстановления — пример формулировки для обсуждения. Жесткий срок полного устранения на аварию честно обещать нельзя: если лежит дата-центр хостинга, подрядчик не починит его быстрее провайдера. Зато можно обещать откат из копии или перенос на запасной сервер, если они подготовлены заранее. Как это выглядит на практике, я разбирал в статье о том, что делать, если дата-центр вышел из строя.

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

Что делать, если сроки нарушены? Вариантов 2: неустойка в договоре или скидка на следующий месяц. Я за второй. Неустойку приходится требовать претензией, а иногда и через суд. Скидка, например 10% от абонемента за каждое нарушенное аварийное окно, срабатывает сама при следующем счете.

Как ставятся задачи и принимается работа

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

1. Задача ставится в одном месте: система задач, общий чат или почта, но одна на весь проект. Задача из устного разговора считается поставленной, когда ее записали.
2. Если задача больше определенного объема (например, 4 ч.), подрядчик сначала присылает оценку, и работа начинается после вашего согласия.
3. Часы списываются по факту, с точностью до 15 или 30 мин., с комментарием к каждой задаче.
4. Раз в месяц подрядчик присылает отчет: задачи, часы по каждой, остаток пакета.
5. У заказчика есть срок на возражения по отчету, например 5 рабочих дней. Если возражений нет, работы считаются принятыми.

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

Для доработок по подряду приемка устроена иначе. По ст. 720 ГК РФ заказчик обязан осмотреть и принять результат, а явные недостатки, не оговоренные при приемке, потом заявить сложнее. Поэтому у каждой крупной доработки должны быть критерии готовности: что именно проверяется и на каком сайте, на копии или на рабочем.

Часы и деньги

Про стоимость часа и размер пакета я писал отдельно в статье сколько стоит обслуживание сайта в месяц. В договоре вокруг этой цифры должны стоять 4 правила:

• Неиспользованные часы. Сгорают, переносятся на следующий месяц или копятся без ограничения. Если переносятся, то на какой срок.
• Часы сверх пакета. По какой ставке и с чьего согласия. Хорошая формулировка: сверх пакета работы выполняются только после подтверждения заказчика, кроме устранения аварий.
• Изменение ставки. Как часто и с каким предупреждением. Без этого пункта ставку можно поменять письмом в любой момент.
• Предоплата. За месяц, за квартал или за год, и что происходит с оплаченным остатком при досрочном расторжении.

Последний пункт я бы читал особенно внимательно, если вам предлагают скидку за оплату года вперед. Скидка обычно 5–10%, а выход из договора с годовой предоплатой без расписанного порядка возврата легко превращается в спор на сумму в разы больше этой скидки.

Кому принадлежат код и доработки

Этот пункт чаще всего отсутствует вовсе. Логика у заказчика простая: «я заплатил, значит, мое». По закону все не так прямо.

Для программ, созданных по заказу, в Гражданском кодексе есть отдельная норма.

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

Что я бы записал:

• исключительное право на код, написанный по заданию заказчика, переходит заказчику с момента оплаты работ;
• за подрядчиком остается право использовать свои типовые наработки (библиотеки, модули, которые он применяет у всех клиентов), а заказчик получает право пользоваться ими на своем сайте без ограничения срока;
• сторонние модули и лицензии (например, решения из Маркетплейса 1С-Битрикс) оформляются на заказчика, а их условия определяет правообладатель, и подрядчик тут ничего не передает;
• код хранится в репозитории, к которому у заказчика есть доступ.

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

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

Здесь договор должен ответить на 3 вопроса: на кого оформлены ресурсы, где лежат копии и что подрядчик делает с персональными данными, к которым получает доступ.

Домен, хостинг, лицензии, аккаунты Метрики, Вебмастера и платежного сервиса оформляются на заказчика. Подрядчик работает по выданным доступам, и в приложении есть перечень этих доступов с датой выдачи. Копии хранятся вне основного сервера, и заказчик знает, где именно и как их достать без подрядчика.

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

Ответственность: чего ждать и что требовать

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

Мое мнение: это бесполезная борьба. Подрядчик с абонементом в 35 тыс. руб. в месяц не может отвечать за выручку магазина за неделю простоя, и если он это подпишет, то либо не читал договор, либо не собирается платить. Закон такое ограничение для отношений между компаниями допускает: ст. 400 ГК РФ разрешает ограничивать размер ответственности, а по п. 4 ст. 401 ГК РФ заранее нельзя только освободить от ответственности за умышленное нарушение.

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

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

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

По договору услуг заказчик вправе отказаться в любой момент, оплатив исполнителю фактически понесенные расходы. Это ст. 782 ГК РФ, и договор такое право не отменяет. Но порядок выхода все равно нужно расписать, иначе «право отказаться» есть, а сайта на руках нет.

В разделе о выходе 4 пункта: срок уведомления, судьба оплаченного остатка, перечень того, что подрядчик передает (доступы, актуальная копия, репозиторий, описание нестандартных доработок), и срок передачи. Хороший подрядчик соглашается на этот раздел без спора. Если подрядчик сопротивляется именно ему, это говорит о нем больше, чем любая презентация.

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

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

1. Найдите перечень регулярных работ. Есть ли у каждой работы периодичность и можно ли проверить, что она сделана.
2. Найдите список того, что не входит. Если его нет, напишите подрядчику 3 задачи, о которых чаще всего спорите, и спросите, входят ли они.
3. Найдите время реакции. Есть ли отдельная цифра на восстановление, закрытый перечень аварий и канал для них.
4. Посмотрите последний отчет. Видно ли в нем задачи, часы по каждой и остаток пакета.
5. Найдите пункт о правах на код. Если его нет, это первый пункт для дополнительного соглашения.
6. Проверьте, на кого оформлены домен, хостинг и лицензии, и где лежит последняя копия. Попросите показать ее.
7. Найдите раздел о расторжении. Записано ли, что и в какой срок вам передадут.

Обычно после такого прохода остаются 2–3 пробела. Их закрывают дополнительным соглашением, и нормальный подрядчик подпишет его в течение недели. Если на просьбу показать резервную копию вы получаете обещание «скоро пришлем», шаг 6 стоит сделать первым.

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