Договор на обслуживание сайта: что в нём должно быть
Предмет, часы, сроки реакции, доступы, приёмка работ, ответственность за простой. Разбор пунктов, которые защищают обе стороны.
Содержание
В договоре на обслуживание сайта должно быть шесть вещей: предмет с перечнем работ, лимит часов и цена сверх лимита, время реакции на инцидент, порядок передачи доступов, приёмка и отчётность, ответственность за простой. Без этих пунктов документ не работает, и спорить придётся скриншотами переписки.
Полгода работы по переписке в мессенджере, всё вроде нормально: подрядчик чинит то, что ломается, присылает счёт раз в месяц, деньги уходят на карту. Потом что-то случается: сайт лежит три дня, подрядчик молчит, а когда появляется, говорит «ну я же не обещал круглосуточно». Или наоборот: заказчик отказывается платить за месяц, потому что «вроде ничего не делалось», хотя на самом деле было потрачено семь часов на разбор атаки ботов. Без документа, который заранее фиксирует правила, обе стороны спорят на голых эмоциях. Эта статья для тех, кто либо сам оказывает услуги обслуживания сайтов, либо нанимает подрядчика и хочет иметь рычаги в конфликте, а не только скриншоты переписки. Разберём пункты, которые реально защищают обе стороны, а не просто занимают место в шаблоне.
Зачем договор, если и так всё по переписке
Три ситуации, где отсутствие договора обходится дороже, чем время на его составление.
Первая: спор о деньгах. Заказчик получает счёт за месяц и отказывается платить, потому что «вроде ничего не делалось». Без договора и без прозрачного учёта часов доказать факт и объём работы почти невозможно, спор решается только испорченными отношениями и потерянной оплатой.
Вторая: авария и вопрос ответственности. Сайт упал на три дня во время рекламной кампании, заказчик требует компенсацию за упущенную выгоду. Без пункта об ограничении ответственности подрядчик формально отвечает суммой, которую предъявит заказчик, а не суммой месячного платежа. Это разница на порядок и больше.
Третья: расставание с подрядчиком. Заказчик решает сменить исполнителя, а домен, хостинг или админ-панель зарегистрированы на прежнего подрядчика без явной передачи прав. Без договора, где чётко написано, кому принадлежат доступы и в какой срок они передаются при расторжении, возврат контроля над сайтом превращается в отдельную битву, иногда через суд.
Предмет договора: чем обслуживание отличается от разработки
Юридически разработка сайта и его обслуживание разные вещи, и путать их в одном договоре не стоит. Разработка обычно оформляется договором подряда (статья 702 ГК РФ): есть овеществлённый результат, работа принимается по акту, результат можно предъявить и проверить. Обслуживание, наоборот, оформляется договором возмездного оказания услуг (статья 779 ГК РФ): предмет это сами действия (диагностика, правки, реагирование на инциденты), а не конечный физический результат, который можно принять один раз и закрыть.
Разница важна не только для юристов. Она определяет, как выглядит акт в конце месяца: акт по услугам описывает, что было сделано и сколько времени затрачено, а не «объект принят без замечаний» как в строительном подряде. Если в договоре обслуживания случайно остались формулировки из шаблона подряда про приёмку результата, при споре заказчик может настаивать на том, что раз результата в физическом смысле нет, платить не за что. Это реальная лазейка, которая закрывается только правильной формулировкой предмета договора.
Для налоговой стороны это тоже имеет значение: если исполнитель работает как самозанятый или ИП на упрощёнке, договор услуг с понятной регулярной оплатой выглядит для налоговой ожидаемо и не вызывает вопросов, в отличие от разовых крупных сумм без ясного основания.
Часы и что в них входит
Ядро большинства абонентских договоров, это фиксированный пакет часов в месяц: 2, 4, 8 или 10 часов на мелкие правки и поддержку. В договоре стоит прописать явно три вещи.
Что считается рабочим временем. Обычно это диагностика проблемы, сама правка, тестирование после неё и время ожидания ответа хостинга по вашей заявке (тикет в поддержку хостинга, который обрабатывается 40 минут, тоже часть работы, а не пауза). Переписка с заказчиком по существу задачи тоже засчитывается, но не любая переписка вообще.
Перенос неиспользованных часов. Если в договоре не прописано иное, по умолчанию неиспользованные часы сгорают в конце месяца, и это нормально для обеих сторон, если написано явно. Более гибкий вариант, перенос до 50 процентов остатка на следующий месяц, чаще встречается в премиум-тарифах.
Переработки и срочные работы вне графика. Что происходит, если за месяц набежало 12 часов при пакете в 8. Обычный вариант, доплата по часовой ставке за превышение, срочные внеплановые работы (авария в выходной день) по повышенному коэффициенту, обычно 1,5-2 от базовой ставки.
Сроки реакции и SLA: реакция это не решение
Частая путаница в устных договорённостях: «отвечу быстро» не равно «решу быстро». SLA (Service Level Agreement) должен разделять два разных срока.
Время реакции, это когда подрядчик подтвердил получение заявки и начал разбираться. Время решения, это когда проблема реально устранена. Для несложной правки текста время решения может совпадать со временем реакции, но для аварии с базой данных время реакции 15 минут (специалист увидел алерт и начал смотреть) абсолютно не то же самое, что время решения 15 минут (сайт снова работает).
Таблица уровней приоритета, которая обычно ложится в приложение к договору:
| Приоритет | Пример | Время реакции | Время решения |
|---|---|---|---|
| P1, авария | Сайт полностью недоступен, утечка данных | 30-60 минут | До 4 часов |
| P2, серьёзно | Не работает форма заявки, ошибка на важной странице | До 4 часов рабочего времени | До 1 рабочего дня |
| P3, обычная правка | Поменять текст, добавить страницу | До 1 рабочего дня | По плану, до 3 рабочих дней |
Отдельно стоит прописать, что считается рабочим временем (например, будни с 10 до 19 по московскому времени) и что происходит с заявками вне этого окна: ставятся в очередь до начала следующего рабочего дня, либо (за отдельную доплату) обрабатываются как ночное дежурство. Подробный разбор, какой уровень SLA нужен конкретно вашему сайту, у меня есть в статье про SLA для небольшого сайта.
Доступы и ответственность
Практическое правило, которое экономит нервы при расставании с любым подрядчиком: домен, хостинг-аккаунт и основная почта администратора всегда регистрируются на заказчика, а не на исполнителя, даже если исполнитель технически всё настраивал. Проверить, кто по факту является администратором домена, можно через whois:
whois example.ru | grep -i "org|person|registrar"Для доменов в зоне .ru с 2019 года действуют ограничения на публикацию персональных данных физлиц в whois, поэтому по юрлицам видно организацию, а по физлицам чаще пусто. В таком случае надёжнее свериться напрямую в личном кабинете у регистратора, кто указан администратором и на чей email привязан аккаунт.
В договоре стоит явно прописать: NDA о неразглашении данных заказчика и его клиентов, срок передачи всех рабочих доступов при расторжении (разумный стандарт, 3-5 рабочих дней), обязанность подрядчика не создавать скрытых точек доступа (запасные админ-аккаунты, недокументированные ключи API) без ведома заказчика. И отдельным пунктом, ограничение ответственности: подрядчик отвечает в пределах суммы, полученной за последний оплаченный период (или за весь год, в зависимости от переговорной позиции), кроме случаев умысла или грубой небрежности, где ограничение обычно не применяется по закону.
Приёмка работ и отчётность
Даже при договоре услуг, а не подряда, ежемесячный акт нужен, хотя бы для бухгалтерии обеих сторон. В акте по обслуживанию логично описывать не «результат принят», а перечень выполненных задач и потраченное время, со ссылкой на подробный отчёт (changelog) как приложение.
Хороший ежемесячный отчёт заказчику отвечает на четыре вопроса без необходимости переспрашивать: что было сделано, сколько часов на что ушло, что осталось в очереди на следующий месяц, были ли инциденты и как быстро их закрыли. Если в конце месяца заказчик получает только «всё нормально, проблем не было», доказательной базы для спора нет ни у одной из сторон, и это плохо и для добросовестного подрядчика тоже: он не может подтвердить объём проделанной работы.
Порядок претензий стоит прописать заранее: срок на предъявление претензии по качеству (например, 5 рабочих дней с момента выполнения работы), срок на ответ (например, 10 рабочих дней), и что происходит, если стороны не пришли к согласию (претензионный порядок до суда, реже упоминание конкретного суда по месту исполнения). Что вообще должно входить в само обслуживание, чтобы не спорить о границах пакета, я подробно разбирал в статье про состав техподдержки сайта, а разницу между абонентским обслуживанием и разовыми правками, если вы ещё выбираете формат работы, смотрите в статье абонентка или разовые правки.
Готовая структура договора по пунктам
Ниже минимальный набор разделов, которые встречаются в рабочих договорах на обслуживание сайта у меня и у большинства коллег, кого я знаю в нише:
- Предмет договора (что именно обслуживается, какая CMS, какой сайт по домену)
- Состав услуг и что явно не входит в пакет
- Пакет часов, перенос остатка, порядок доплаты за превышение
- Сроки реакции и решения по приоритетам (SLA), рабочее время
- Стоимость, порядок оплаты, дата выставления счёта
- Доступы: кто владеет доменом и хостингом, порядок передачи при расторжении
- Конфиденциальность и NDA
- Ответственность сторон и её ограничение
- Порядок сдачи-приёмки (ежемесячный акт и отчёт)
- Порядок предъявления и рассмотрения претензий
- Срок действия, порядок продления и расторжения
Не у каждого малого сайта нужен юрист для составления такого документа с нуля: можно начать с этого списка разделов, заполнить конкретикой под свою ситуацию и при необходимости отдать готовый черновик на проверку юристу, это дешевле, чем писать договор с чистого листа.
Если сравниваете стоимость обслуживания у разных подрядчиков и не понимаете, что должно быть заложено в цену помимо самого договора, у меня есть отдельный разбор в статье сколько стоит обслуживание сайта. А если хотите обсудить условия и получить проект договора под свой сайт, посмотрите мои тарифы или напишите через форму на главной, обычно на составление договора под конкретный случай уходит один-два рабочих дня.
Частые вопросы
Нужен ли договор на обслуживание сайта
Нужен с того момента, как вы передаёте подрядчику доступы. Договор описывает, кто отвечает за простой, что входит в лимит часов и как расстаться, не потеряв доступы. Если через сайт обрабатываются данные посетителей, добавляется поручение на обработку по 152-ФЗ.
Что писать в предмете договора
Перечень работ списком. Формулировка про техническую поддержку в предмете бесполезна: под неё подходит что угодно. Пишите, как часто снимаются бэкапы и где лежат, с каким интервалом проверяется доступность, как часто ставятся обновления, сколько часов в месяц уходит на правки. Всё, что не названо, при споре считается невходящим.
Как фиксировать время реакции
В часах и с разделением на рабочее и нерабочее время. Слово оперативно не значит ничего. Отдельно оговорите, что вообще считается инцидентом: недоступность сайта, отказ формы заявки, ошибка оплаты.
Кому принадлежат доступы и код
По умолчанию заказчику. Пропишите передачу логинов, паролей и репозитория при расторжении и срок, в который подрядчик их отдаёт. Это самое частое место конфликта.
