Техническая поддержка сайта — это работа с уже действующим проектом: разобраться в обращении, согласовать изменение, выполнить его, проверить и выпустить на сайт. Её задача — сохранять нужные бизнесу сценарии и вносить согласованные небольшие изменения. Обслуживание полезно, когда за формами, содержимым, обновлениями и ошибками есть кому следить и понятно, как передать задачу исполнителю.
Название «поддержка» само по себе не определяет состав. В одном договоре предусмотрены проверки и исправления, в другом — только работа по обращениям. До подключения нужно выяснить, что выполняется регулярно, что требует отдельной оценки и кто отвечает за внешние сервисы.
Где заканчивается поддержка и начинается другая задача
Разделяйте работы по результату и условиям выполнения. Ниже — примеры для согласования состава, а не перечень услуг, автоматически включённых в любой тариф.
| Вид работы | Пример | Что согласовать |
|---|---|---|
| Регулярное обслуживание | Проверить согласованные формы, заменить подготовленный текст, исправить небольшой дефект существующего сценария | Перечень задач, периодичность проверок, приоритеты и объём |
| Развитие сайта | Добавить личный кабинет, новый способ оформления заказа или обмен с CRM | Требования к новой функции, оценку, проверку и границы проекта |
| Аварийная работа | Восстановить недоступный сайт или разобраться с внезапной потерей заявок | Канал обращения, время реакции, полномочия на срочные действия и согласование расходов |
| Работа со сторонним поставщиком | Выяснить причину сбоя хостинга, почты или платёжного сервиса | Кто обращается к поставщику, у кого доступ к аккаунту, кто оплачивает его услуги |
Небольшое исправление может выполняться в рамках согласованной поддержки. Но фраза «добавить всего одну кнопку» не объясняет трудозатраты: за ней может стоять новый обмен данными, расчёт или проверка прав доступа. Отдельная ограниченная доработка сайта начинается с описания результата и оценки затронутого участка. Крупная переработка, новая подсистема или смена платформы требуют проектной оценки.
При аварии сначала нужно определить, что затронуто: весь сайт, отдельная форма, отправка письма или внешний сервис. Затем — установить причину и безопасный способ восстановления. Сам факт абонентской оплаты не задаёт срок реакции, круглосуточное дежурство или право без согласования расширять бюджет. Эти условия следует зафиксировать до возникновения срочной ситуации.
Что имеет смысл включить в регулярный состав
Для сайта компании полезно начать с тех действий, от которых зависит обращение клиента: открытие важных страниц, отправка формы и получение заявки ответственным сотрудником. Для магазина добавляются согласованные сценарии заказа и обмена данными. Перечень должен соответствовать вашему сайту: проверка функции, которой нет, ничего не даёт.
Проверки и мониторинг. Укажите, что именно проверяется, как часто, кому поступает сигнал и кто реагирует. Проверка доступности не подтверждает работу всех функций. Например, стандартная проверка состояния Laravel сообщает, что приложение запустилось без исключений; дополнительные проверки базы и других зависимостей настраиваются отдельно. Для бизнеса важен ещё и результат сценария: дошло ли обращение до места, где его обработают. Автоматический сигнал и действия специалиста — разные части работы.
Обновления и исправления. Нужно знать, какие компоненты используются и какие изменения требуют проверки. Обновление нельзя считать законченным только по сообщению об установке: проверяют затронутые функции и связанные сценарии. Исправление ошибки должно подтверждаться повторением действия, при котором она возникала.
Резервные копии и доступы. Зафиксируйте, что сохраняется, где хранится копия и кто может восстановить сайт. Наличие архива следует подтверждать проверкой восстановления. Не считайте такую проверку включённой в тариф, если она не названа в составе. Доступ исполнителю давайте с правами, необходимыми для согласованных работ; пароли и ключи не включайте в обычное описание задачи.
Небольшие изменения содержания. Можно отдельно согласовать размещение подготовленных материалов, замену контактов или правку существующего блока. Написание текстов, съёмка товаров и создание нового дизайна — самостоятельные результаты. Возможность отредактировать страницу не означает, что подготовка всех её материалов уже оплачена.
Для небольшого сайта перечень может быть коротким. Для проекта с заказами и интеграциями он потребует больше внимания. Полезнее назвать несколько важных проверок с ответственным за результат, чем записать в договоре «полное техническое сопровождение» без расшифровки.
Как проходит задача от обращения до выпуска
Рабочий порядок помогает понять, за что учитывается время и в какой момент нужно решение владельца.
- Зафиксировать обращение. Передайте страницу или раздел, ожидаемое поведение, фактический результат, время возникновения и шаги повторения. Добавьте снимок ошибки без персональных данных и секретов. Укажите влияние на бизнес: остановились все обращения или проблема относится к одному необязательному полю.
- Уточнить причину и оценить объём. Исполнитель проверяет затронутый участок, доступы и зависимости. Для изменения согласуют ожидаемый результат, трудозатраты и способ проверки. Если до диагностики объём неизвестен, заранее определяют границы этой диагностики и следующий момент согласования.
- Выполнить согласованную работу. Изменение должно оставаться в пределах задачи. Где это возможно, его сначала проверяют в отдельной среде с защищёнными тестовыми данными. Если выясняется, что нужно менять больше, новую оценку согласуют до расширения работ.
- Проверить результат. Повторяют исходный сценарий и проверяют связанные действия. Для формы недостаточно увидеть сообщение «отправлено»: нужно убедиться, что тестовое обращение получено нужным адресатом. Проверки не должны создавать реальные заказы или рассылки без согласования.
- Выпустить и закрыть задачу. Определяют подходящий момент и способ возврата при неудачном изменении, учитывая новые данные на рабочем сайте. После выпуска повторяют нужные проверки. В отчёте фиксируют выполненное, результат проверки, затраченное время и оставшиеся ограничения.
Выпуск — часть работы. Например, в Laravel после обновления кода длительно работающие процессы, включая обработчики очередей, нужно перезапустить или перезагрузить, чтобы они использовали новую версию. Поэтому копирование изменённого файла ещё не доказывает, что весь сценарий работает.
Удобная запись по задаче отвечает на вопросы: что попросили, что согласовали, что сделали, как проверили и что осталось. Она также показывает, почему диагностика, переписка и выпуск входят в трудозатраты, даже если сама правка занимает несколько строк.
Учебный пример: поменять получателя заявок
Допустим, компания хочет отправлять обращения с существующей формы новому ответственному сотруднику. Это учебная ситуация, а не клиентский кейс и не оценка часов.
В обращении можно написать: «На странице услуги форма должна отправлять уведомление в новый рабочий ящик. Поля и сохранение обращений остаются прежними. Результат принимаем по тестовой заявке, которую получает новый адресат».
Для этой задачи нужно уточнить текущий способ отправки, изменить получателя, проверить отправку и получение письма, затем выпустить изменение и повторить проверку на рабочем сайте. Если письмо не доставлено из-за настроек внешней почты, это выявленная зависимость: потребуется доступ к сервису или участие его ответственного.
Если по ходу обсуждения появляется требование «пусть заявки сразу создают сделки в CRM», состав меняется. Нужно определить поля, правила создания, обработку ошибок и доступ к CRM. Такой результат нельзя считать продолжением замены адресата без новой оценки.
Какие границы действуют у пакета Студии Вебирус
Подтверждённые условия технической поддержки сайтов — от 6 000 ₽ в месяц, до 3 часов работ. В этот объём входят коммуникация, проверка и выпуск изменений. Это общий объём работы, а не три часа разработки плюс неограниченные обсуждения и тестирование.
Дополнительные работы предварительно согласовываются по 2 000 ₽/час. Их не следует смешивать с отдельным заказом: для разовых работ действуют 3 000 ₽/час и минимальный заказ 1 час. Объём и стоимость разовой задачи согласуют до начала; минимум относится к заказу целиком.
Поддержка предназначена для регулярных небольших работ. Задачи, приоритеты и выпуск согласуют заранее. Чужой проект Студия Вебирус принимает после диагностики кода, доступов и условий эксплуатации; возможность работы и объём подтверждаются по её результатам. Поддержка любой CMS или технологии автоматически не обещается.
Срок реакции, срочные работы и условия вне рабочего графика согласуются отдельно. Перенос неиспользованных часов и минимальный срок договора заранее не заявлены. Периодичность мониторинга, проверок копий и обновлений нужно включить в конкретный согласованный состав. Нельзя выводить эти обязательства только из цены пакета.
Расходы на домен, хостинг и внешние сервисы отдельно обозначаются в предложении. Работа исполнителя с настройками или обращением в поддержку поставщика не равна оплате его подписки и не определяет срок устранения сбоя на его стороне. Для каждого сервиса нужно знать владельца аккаунта и порядок взаимодействия.
Что зафиксировать перед подключением
Передавайте поддержку вместе с понятным перечнем ответственности:
- какие страницы и бизнес-сценарии обслуживаются, какие проверки выполняются регулярно;
- где принимают задачи, кто со стороны компании утверждает приоритет, объём и выпуск;
- как учитываются трудозатраты и согласуется превышение месячного объёма;
- какой порядок действует для срочных обращений и работы вне обычного графика;
- кто отвечает за доступы, внешние сервисы, копии и подтверждение результата.
Если для важного пункта ещё нет договорённости, назовите его открытым вопросом. Это позволяет согласовать реальный состав до оплаты и не принимать общую формулировку за обещание всех возможных работ.
После определения состава можно посчитать стоимость поддержки, а регулярные задачи связать с планом работы с сайтом после запуска.
