Договор на техподдержку сайта чаще всего подводит не ценой, а формулировками. «Исполнитель оказывает услуги по технической поддержке сайта» — под этой фразой можно ничего не делать месяц и выставить полный счёт. Если в договоре нет перечня работ, времени реакции, правил учёта часов и отчёта, вы платите за ощущение, что сайт под присмотром. Ниже — семь ошибок, из-за которых компании платят за пустые часы, и список пунктов, которые стоит вписать до подписания.
ПРАВИЛОХороший договор поддержки отвечает на вопрос «что будет, если сайт упадёт в субботу вечером» без звонка юристу.
Ошибка 1. Предмет договора без перечня работ
Формулировка «техническая поддержка и сопровождение сайта» ничего не обязывает делать. Спор начинается при первой же проблеме: вы считаете, что восстановление после сбоя входит в абонентскую плату, подрядчик — что это отдельная работа.
В договоре или приложении к нему должен быть закрытый перечень: мониторинг доступности, резервное копирование с указанием частоты, обновления CMS и модулей, продление SSL, исправление ошибок, пакет часов на доработки, отчёт. Всё, чего нет в перечне, — отдельная оплата, и это тоже надо написать прямо, с указанием, как такие работы оцениваются.
Ошибка 2. Сгорающие часы
Пакет часов техподдержки — удобная модель, если часы не сгорают в конце месяца. Если сгорают, в спокойные месяцы вы платите за ничего, а в горячие — докупаете сверх пакета. Подрядчику такая схема выгодна, вам — нет.
Нормальная практика — перенос неизрасходованных часов на следующий период, хотя бы в пределах квартала, и понятная цена часа сверх пакета. Мы, например, переносим часы в пределах квартала, а если задач стабильно больше, предлагаем перейти на следующий тариф, а не платить переработку каждый месяц.
Ошибка 3. Нет SLA для сайта
SLA — соглашение об уровне сервиса: за какое время подрядчик берёт проблему в работу. Без него «сделаем как можно скорее» может означать и час, и неделю. В SLA должно быть три вещи:
- Определение критичного сбоя. Например: сайт не открывается, не принимает заявки или заказы.
- Время реакции по каждому типу задачи — критичный сбой, ошибка, плановая доработка.
- Часы работы: только будни или круглосуточно, включая праздники.
Обратите внимание на разницу между временем реакции и временем устранения. Гарантировать, что любой сбой будет исправлен за час, честный подрядчик не может: причина может быть на стороне хостинга, платёжного сервиса или площадки. А вот гарантировать, что инженер возьмёт проблему в работу в течение оговорённого времени и сообщит срок, — может и должен. Если в договоре обещано «устранение любых неисправностей за 2 часа», уточните, что будет при нарушении, — обычно ничего.
Для интернет-магазина с 1С и Kaspi критичными стоит считать и сбои обмена: если остатки перестали обновляться ночью, утром вы получите отмены. Впишите такие сценарии в определение критичного сбоя явно.
| Так писать не стоит | Так лучше |
|---|---|
| «Исполнитель устраняет неисправности в разумный срок» | «Критичный сбой берётся в работу в течение 1 часа, срок устранения сообщается заказчику» |
| «Оказывать услуги по поддержке сайта» | Перечень работ в приложении с частотой каждой |
| «Пакет 10 часов в месяц» | «10 часов в месяц, неизрасходованные переносятся в пределах квартала» |
| «По запросу заказчика предоставляется информация» | «Ежемесячный отчёт: выполненные задачи, часы по каждой, рекомендации» |
| «Исходный код является собственностью исполнителя» | «Код, доступы и документация передаются заказчику» |
Ошибка 4. Нет отчёта и учёта часов
Если подрядчик списывает часы, а вы не видите, на что, — это не пакет часов, а абонентская плата без контроля. В договоре закрепите ежемесячный отчёт: какие задачи выполнены, сколько часов списано на каждую, что сломалось и что сделано, какие риски видит подрядчик. Отчёт — это не формальность: по нему вы планируете бюджет на развитие сайта и понимаете, за что платите.
Отдельно пропишите, что крупные задачи сначала оцениваются в часах и согласуются с вами, а только потом выполняются. Иначе «маленькая правка баннера» может съесть половину пакета.
Ещё один пункт, который редко встречается в договорах, — канал постановки задач. Если задачи прилетают в личные сообщения разным сотрудникам подрядчика, часть теряется, а спорить о сроках невозможно. Зафиксируйте один канал — рабочий чат или систему задач — и правило, что срок считается с момента постановки задачи в этом канале. Тогда и отчёт за месяц собирается из одного места, а не по памяти.
Ошибка 5. Права на код, доступы и уход от подрядчика
Самая дорогая ошибка обнаруживается при смене подрядчика: код в чужом репозитории, домен оформлен на исполнителя, доступы к хостингу только у него. Пропишите в договоре, что результаты работ — код, доработки, документация — принадлежат вам, что домен, хостинг и лицензии оформлены на вашу компанию, а при расторжении подрядчик передаёт все доступы и актуальную копию сайта в оговорённый срок.
Длинный срок уведомления о расторжении и штраф за досрочный выход. Если подрядчик уверен в своей работе, ему не нужно удерживать клиента договором. Нормальная практика — отказ в любой месяц без штрафов.
Ошибка 6. Исправление ошибок подрядчика за ваши часы
Подрядчик сделал доработку, через неделю она сломала корзину, и исправление списывается из вашего пакета. Так быть не должно. Впишите гарантию: ошибки в работах исполнителя исправляются бесплатно и часы не расходуют. Мы работаем именно так — исправление наших ошибок идёт по гарантии.
Отдельный вопрос — ошибки, оставленные прошлым подрядчиком. Их разумно зафиксировать на аудите при подключении и договориться, в каком порядке и за чей счёт их исправлять. Разовые исправления вне пакета обычно оцениваются по фиксированной цене: например, исправление ошибок на сайте у нас стоит от 25 000 ₸ за типовую ошибку с диагностикой, резервной копией и отчётом о причинах.
Ошибка 7. Неясно, что оплачивается отдельно
Хостинг, лицензии CMS и модулей, платные сервисы, часы сверх пакета — всё это может появиться в счёте внезапно. Перечислите в договоре, что не входит в абонентскую плату, и закрепите правило: о любых дополнительных расходах подрядчик сообщает заранее и согласует их до начала работ.
Полезно попросить у подрядчика прайс на типовые работы вне пакета ещё до подписания: перенос сайта, обновление крупной версии платформы, ускорение, лечение после взлома. Тогда при необходимости вы не торгуетесь в стрессовой ситуации, а сравниваете с известной ценой. Наши тарифы и разовые работы направления собраны на странице цен на поддержку.
Какие пункты вписать до подписания
- Закрытый перечень работ с частотой: мониторинг, бэкапы, обновления, SSL, исправления, отчёт
- Определение критичного сбоя и время реакции для каждого типа задач
- Часы работы: будни или 24/7, праздники
- Объём пакета часов, правило переноса и цена часа сверх пакета
- Порядок постановки задач и согласования оценки крупных работ
- Ежемесячный отчёт с часами по задачам и рекомендациями
- Гарантия на работы исполнителя без списания часов
- Права на код и документацию у заказчика
- Домен, хостинг и лицензии оформлены на заказчика
- Передача доступов и копии сайта при расторжении, срок передачи
- Отказ от договора без штрафов с разумным сроком уведомления
- Перечень того, что оплачивается отдельно, и правило предварительного согласования
Договор — юридический документ, и окончательную редакцию стоит согласовать с вашим юристом по действующему законодательству РК. Чек-лист выше — о содержании, а не о форме.
Как это устроено в WeMake
Техническую поддержку сайтов мы ведём по договору SLA. В нём фиксируем время реакции на сбой, состав работ, пакет часов и регламент постановки задач. Критичный сбой — когда сайт не открывается, не принимает заявки или заказы — инженер берёт в работу в течение часа, обычно за 5 минут, и сообщает срок, обычные задачи из чата делаем за 1–2 дня.
Как выбрать между пакетом часов и оплатой фактических работ, мы разбирали в статье «Фиксированная цена или оплата по часам». Пришлите нам ваш текущий договор поддержки — покажем, каких пунктов в нём не хватает, и предложим условия поддержки сайта по SLA с бесплатным аудитом при подключении.
Что такое SLA для сайта?
Соглашение об уровне сервиса: какие проблемы считаются критичными, за какое время подрядчик берёт их в работу и в какие часы работает поддержка.
Где взять образец договора обслуживания сайта?
Типовые шаблоны есть у юристов и подрядчиков, но главное — приложение с перечнем работ, SLA и правилами учёта часов. Используйте чек-лист из статьи, чтобы проверить любой образец.
Должны ли сгорать часы техподдержки?
Не должны. Нормальная практика — перенос неизрасходованных часов хотя бы в пределах квартала.
Кому принадлежит код после работ по поддержке?
Это определяет договор. Впишите, что код, доработки и документация принадлежат заказчику и передаются ему при расторжении.
