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