
Границы поддержки сайта после завершения проекта нужно закрепить письменно: отделить исправление дефектов от новых работ, перечислить обслуживаемые компоненты, определить порядок обращений, сроки реакции, график и оплату. До передачи проекта согласуйте эти условия с заказчиком и внесите их в договор или приложение, чтобы обе стороны одинаково понимали, что входит в сопровождение.
Что заранее зафиксировать в условиях поддержки сайта
- Какие ошибки исполнитель устраняет без дополнительной оплаты и как заказчик подтверждает, что это дефект.
- Какие страницы, системы, интеграции и сервисы входят в обслуживание.
- Как классифицируются обращения и в какие сроки исполнитель реагирует на каждый тип.
- В какие часы ведётся работа, куда отправлять запросы и как эскалировать срочные проблемы.
- Как рассчитывается стоимость, учитываются часы и согласуются задачи сверх поддержки.
- Где хранятся доступы и инструкции и как передать их заказчику при смене исполнителя.
Отделите гарантийное исправление ошибок от новых задач
Сначала определите, что считать дефектом: несоответствие согласованному техническому заданию, ошибку реализованной функции или сбой, возникший из-за изменений в коде исполнителя. Укажите срок и порядок предъявления таких претензий, а также условия, при которых бесплатное исправление не применяется, например после вмешательства третьих лиц.
Поддержка сайта после разработки обычно охватывает согласованные регулярные действия: диагностику, обновления, резервное копирование или устранение сбоев в пределах перечисленных компонентов. Новые страницы, функции, интеграции и изменение дизайна - отдельные доработки, которые оцениваются и согласуются дополнительно.
Такое разделение подходит фрилансеру и заказчику, которым важно избежать неоднозначных ожиданий после сдачи. Не стоит обещать "любые исправления бесплатно" или включать в поддержку неопределённый объём новых работ: такие формулировки не задают проверяемых границ.
Составьте карту сайта: какие компоненты входят в поддержку
Перед оформлением условий составьте перечень обслуживаемых частей проекта. Для каждого компонента зафиксируйте владельца, место размещения, зависимость от внешних сервисов и действия, которые исполнитель обязан выполнять.
- Сайт и его разделы: домен, хостинг, CMS, тема, модули и пользовательские функции.
- Интеграции: платёжные системы, CRM, рассылки, аналитика и внешние API.
- Инфраструктура: сервер, сертификаты, DNS, резервные копии и почтовые настройки - только если это входит в согласованный объём.
- Рабочие материалы: репозиторий кода, инструкции по развёртыванию, тестовая среда и журнал изменений.
- Доступы: учётные записи и роли в панели хостинга, CMS, доменном регистраторе и сторонних сервисах.
Не передавайте пароли в открытой переписке. Предпочтительны персональные учётные записи с необходимыми правами и безопасный способ передачи секретов. Уточните, кто отвечает за продление сторонних подписок и кто оплачивает услуги провайдеров.
Сведите типы обращений и сроки реакции в одну таблицу
Перед подготовкой таблицы соберите сведения, без которых условия будут трудно проверить:
- перечень компонентов и функций, которые включены в обслуживание;
- контактных лиц со стороны заказчика и исполнителя;
- рабочий график и канал для регистрации запросов;
- порядок определения приоритета и согласования платных работ;
- доступ к тестовой среде, журналу ошибок и резервным копиям, если они используются.
Затем составьте таблицу. Указывайте в ней срок реакции, а не обещание полностью устранить проблему за тот же период: время решения зависит от причины сбоя и участия сторонних сервисов. Приведённые категории - основа для согласования, а не универсальный норматив.
-
Разделите запросы по влиянию на работу сайта.
Опишите, что считать критическим сбоем, частичной недоступностью и плановой задачей. Привязывайте категорию к наблюдаемому результату, а не к субъективной оценке срочности. -
Установите сроки первой реакции.
Для каждого типа обращения укажите, когда исполнитель подтвердит получение и сообщит дальнейшие действия. Сроки должны учитывать согласованный график и часовой пояс сторон. -
Определите границы оплаты.
Отметьте, какие работы покрывает фиксированная плата или пакет часов, а какие требуют отдельной оценки. Для внешних сервисов предусмотрите отдельное согласование, если исполнитель не контролирует их работу. -
Согласуйте формат обновления статуса.
Укажите, как исполнитель сообщает о диагностике, блокерах и ожидаемых действиях заказчика. Завершение обращения подтвердите описанием результата и, если уместно, ссылкой на задачу или журнал изменений.
| Тип обращения | Пример критерия | Срок реакции | Оплата и граница работ |
|---|---|---|---|
| Критический сбой | Ключевая функция недоступна или сайт не открывается | Согласовать приоритетный срок в рабочем графике договора | Уточнить, включена ли диагностика в обслуживание; сторонние расходы согласовать отдельно |
| Частичная неисправность | Отдельная функция работает с ошибкой, остальные разделы доступны | Установить срок реакции для обычного приоритета | Исправление дефекта - по гарантийным условиям; изменение логики - отдельная задача |
| Плановое обслуживание | Обновление, проверка или согласованная профилактическая работа | Определить срок планирования и уведомления заказчика | Учесть в фиксированной плате или списывать из согласованного пакета часов |
| Новая доработка | Новая функция, раздел, интеграция или изменение требований | Установить срок оценки и согласования, не обещая немедленное выполнение | Работать после отдельной оценки и письменного подтверждения объёма и цены |
Опишите рабочий график, каналы связи и порядок эскалации
Проверьте, можно ли по документу понять, куда направить запрос, кто его примет и что делать при срочном сбое. Условия должны описывать рабочие часы, выходные и праздники, допустимые каналы и порядок связи при недоступности основного канала.
- Указаны рабочие часы исполнителя и часовой пояс.
- Определён основной канал регистрации обращений и способ подтверждения их получения.
- Назначены контактные лица и указано, кто вправе согласовывать платные работы.
- Описаны категории приоритета и критерии для каждой из них.
- Указан отдельный порядок эскалации при критическом сбое.
- Обозначено, как учитываются запросы, пришедшие вне рабочего времени.
- Определено, как заказчик предоставляет сведения для диагностики и подтверждает результат.
Рассчитайте стоимость сопровождения и правила учёта часов
Стоимость зависит от состава работ, режима доступности, сложности проекта и модели оплаты. Чтобы оценить техническую поддержку сайта по цене, отдельно перечислите включённые задачи, лимиты и условия оплаты сверх объёма. Запрос "обслуживание сайта стоимость" или "сопровождение сайта цена" не имеет однозначного ответа без этих исходных данных.
Зафиксируйте, когда начинается учёт времени, как округляются затраты, где заказчик видит отчёт и кто подтверждает дополнительные работы. Уточните, переносятся ли неиспользованные часы, оплачивается ли срочная работа вне графика и как оформляются расходы на сторонние сервисы.
Проверьте условия на частые ошибки:
- объём поддержки описан словами "всё необходимое" без перечня задач;
- не разделены исправление дефекта, плановое обслуживание и доработка;
- обещано время полного решения, хотя установлен только срок реакции;
- не указано, как учитываются и подтверждаются часы;
- не согласована ставка или порядок оценки работ сверх пакета;
- не определено, входят ли в плату хостинг, лицензии и услуги внешних провайдеров;
- не установлен порядок согласования срочных и внеплановых работ;
- не прописано, что происходит с неиспользованным остатком часов.
В договор на техническую поддержку сайта внесите не только цену, но и состав услуги, порядок изменения объёма, правила приёмки и расчётов. Если условия оформляются приложением, укажите, что именно оно уточняет и как соотносится с основным договором.
Передайте доступы и инструкции, чтобы заказчик мог сменить исполнителя
Передача проекта должна позволять заказчику сохранить контроль над сайтом и поручить обслуживание другому специалисту. Выберите удобный способ хранения материалов и включите его в акт или перечень передаваемых данных.
- Общий защищённый менеджер секретов. Подходит, если заказчик и исполнитель используют персональные учётные записи и могут отозвать доступ после завершения сотрудничества.
- Репозиторий и документация. Уместны для проектов с кодом и регулярными изменениями: передайте права доступа, инструкции по запуску и порядок публикации обновлений.
- Передача владельцу проекта. Используйте для домена, хостинга и внешних сервисов: заказчик должен иметь собственную учётную запись владельца, а не зависеть от личного аккаунта исполнителя.
- Поэтапный переход новому специалисту. Подходит для сложного проекта: согласуйте передачу контекста, список известных проблем и безопасное отключение прежних доступов.
Не отправляйте пароль от единственной учётной записи и не удаляйте резервные копии до подтверждения передачи. После смены исполнителя заказчику следует сменить секреты, проверить права пользователей и убедиться, что критичные сервисы привязаны к его контактным данным.
Разбор спорных ситуаций при поддержке сайта после сдачи
Как понять, что обращение относится к гарантийному исправлению?
Сравните фактическое поведение сайта с согласованным заданием и зафиксируйте шаги, при которых проявляется ошибка. Если результат соответствует требованиям, но заказчик хочет изменить поведение, это обычно отдельная доработка.
Можно ли считать срок реакции сроком устранения сбоя?
Нет, если договор прямо не устанавливает оба срока отдельно. Реакция означает подтверждение обращения и начало согласованных действий; решение может зависеть от диагностики, доступа и сторонних сервисов.
Что делать, если сбой вызван внешним сервисом?
Проверьте, входит ли этот сервис в перечень обслуживаемых компонентов и кто отвечает за обращение к его поставщику. Зафиксируйте зависимость и согласуйте действия, которые исполнитель может выполнить в пределах своих доступов.
Нужно ли оплачивать диагностику, если причина ошибки не найдена?
Это зависит от условий договора. Заранее укажите, входит ли первичная диагностика в поддержку и как оплачивается дальнейшее расследование, если проблема возникла вне кода или инфраструктуры исполнителя.
Как согласовать работу, которой нет в перечне поддержки?
Попросите исполнителя описать объём, оценку, цену и ожидаемый результат. Начинать такую работу следует после письменного согласования уполномоченным представителем заказчика.
Что делать, если заказчик не предоставил доступы или данные для проверки?
Исполнитель должен зафиксировать, какой доступ или материал необходим и как его безопасно передать. Условия могут предусматривать приостановку сроков реакции или выполнения задачи до получения необходимых данных.
Как корректно завершить поддержку и передать сайт другому специалисту?
Сверьте перечень передаваемых доступов, кода, инструкций и известных проблем, затем подтвердите передачу письменно. Отзовите прежние доступы после того, как заказчик проверит работоспособность учётных записей и материалов.
Автор: Ирина Белова