За что вы платите при обслуживании сайта: какие работы действительно нужны бизнесу

Сайт работает. Зачем платить за его обслуживание?

Вопрос вполне разумный. Не каждому сайту необходим дорогой пакет обслуживания, а некоторые задачи действительно выгоднее решать по мере появления.

Проблема в том, что работоспособность сайта нельзя оценивать только по тому, открывается ли его главная страница.

Например, посетитель может спокойно просматривать каталог, но не суметь отправить заявку из-за ошибки в форме. Руководитель этого не заметит, поскольку сам сайт продолжает работать. Или после обновления программного модуля перестанет корректно отображаться стоимость доставки. Ошибка может затронуть часть заказов, хотя внешне интернет-магазин выглядит исправным.

Поэтому смысл технического обслуживания заключается не в постоянном изменении сайта, а в поддержании его работоспособности, устранении ошибок и своевременном выполнении необходимых задач.

Но объём этих работ должен соответствовать самому проекту.

Что действительно должно входить в техническое обслуживание сайта

У разных подрядчиков состав услуг отличается. Однако есть несколько направлений, которые стоит рассматривать при выборе поддержки.

Контроль работоспособности сайта и заявок

Проверять только доступность главной страницы недостаточно.

Нужно учитывать функции, от которых зависит работа бизнеса:

• отправку заявок,
• корзину,
• оформление заказа,
• передачу данных в CRM,
• работу личного кабинета
• и другие важные элементы.

Например, сайт может отвечать на запросы посетителей, но перестать отправлять уведомления о новых обращениях на электронную почту.

Для руководителя это означает риск потерять заинтересованного клиента, даже если технический мониторинг показывает, что сайт доступен.

Поэтому полезно заранее определить, какие действия посетителей необходимо регулярно проверять. Для корпоративного сайта это могут быть формы заявок, для интернет-магазина — оформление заказа и оплата, для сервисной компании — запись на услугу.

Резервное копирование и возможность восстановления

Резервная копия необходима на случай повреждения файлов, неудачного обновления, ошибки сотрудника или сбоя на сервере. Но сам факт создания копии ещё не гарантирует возможность восстановить сайт.

Имеет значение, что именно сохраняется, где размещаются резервные файлы и насколько быстро можно вернуть рабочую версию.

Если сайт использует базу данных, важно сохранять не только файлы, но и необходимые данные.

Особое внимание следует уделять интернет-магазинам и другим проектам, где постоянно появляются новые заказы, обращения и пользовательская информация. В таких случаях ежедневного копирования может оказаться недостаточно: периодичность нужно выбирать с учётом допустимой потери данных.

У подрядчика стоит уточнить три вещи:

• Как часто создаются резервные копии?
• Где они хранятся и защищены ли от проблем с основным сервером?
• Проверялась ли возможность восстановления сайта из копии?

Обновление CMS, модулей и серверного окружения

WordPress, 1С-Битрикс и другие системы управления сайтом требуют внимания к обновлениям.

Разработчики исправляют ошибки, устраняют известные уязвимости и обеспечивают совместимость программных компонентов. Однако бездумно устанавливать все доступные обновления тоже неправильно.

Новая версия плагина может оказаться несовместимой с шаблоном сайта. Изменение версии PHP способно нарушить работу старого программного кода. Иногда последствия проявляются только в отдельных разделах или функциях.

Поэтому безопасный порядок обновления обычно включает предварительную проверку совместимости, создание резервной копии, установку изменений и тестирование критически важных функций. Для сложных проектов обновления целесообразно сначала проверять в тестовой среде.

Хорошая техническая поддержка не сводится к нажатию кнопки «Обновить». Подрядчик должен понимать возможные последствия и иметь план восстановления.

Исправление ошибок и небольшие доработки

Со временем на сайте появляются задачи, которые не требуют полноценной переработки проекта.

• Изменился адрес офиса,
• необходимо исправить телефон,
• добавить поле в форму заявки,
• обновить информацию об услуге
• или устранить ошибку отображения на мобильных устройствах.

Часть таких задач может входить в ежемесячный пакет обслуживания. Но здесь важно различать поддержку и разработку нового функционала.

Изменение текста на странице и создание личного кабинета для клиентов — работы совершенно разного масштаба. Если договор не разделяет их, неизбежно возникают споры о стоимости и сроках.

Перед заключением договора полезно уточнить, какие задачи подрядчик считает небольшими доработками, сколько часов включено в тариф и как оплачивается превышение лимита.

Какие услуги не обязательно оплачивать каждый месяц

Распространённая ошибка — выбирать максимальный тариф обслуживания независимо от реальных потребностей сайта.

Например, небольшой корпоративный сайт с несколькими страницами, без сложных интеграций и частых обновлений контента может не требовать десятков часов работы специалистов ежемесячно.

В таком случае достаточно базового технического контроля и разовых доработок при необходимости.

Есть и обратная ситуация. Интернет-магазин регулярно обновляет ассортимент, обменивается данными с учётной системой и принимает заказы круглосуточно. Здесь отсутствие технической поддержки может создавать существенные операционные риски.

Отдельного внимания заслуживают услуги, которые иногда включают в общий пакет, хотя они решают другие задачи.

• SEO-продвижение. Техническая поддержка может включать исправление битых ссылок, проблем индексации и технических ошибок. Но полноценное SEO с анализом спроса, развитием структуры и работой над поисковой видимостью — отдельное направление.
• Реклама. Поддержка сайта не означает настройку и ведение рекламных кампаний. Подрядчик может помогать с технической частью: установкой счётчиков, передачей целей и исправлением ошибок на посадочных страницах.
• Разработка новых разделов. Создание большого каталога, интеграция с 1С или внедрение сложного личного кабинета обычно требуют самостоятельной оценки и отдельного бюджета.

Абонентская поддержка или оплата по факту: что выгоднее?

Однозначного ответа нет. Выбор зависит от частоты задач, сложности сайта и возможных последствий сбоев.

Допустим, у компании простой сайт, который редко меняется. За несколько месяцев понадобилось только заменить контакты и исправить один небольшой блок.

• Если постоянное обслуживание обходится дороже таких редких работ, разумно рассмотреть разовую оплату. Но при этом должен быть решён вопрос с резервными копиями, обновлениями и ответственностью за техническое состояние.

Теперь другая ситуация. Сайт ежедневно приносит обращения, на него направлен рекламный трафик, а менеджеры получают заявки через интеграцию с CRM.

• Если передача данных неожиданно прекратится, проблема может затронуть текущие продажи. Для такого бизнеса особенно важны постоянный контроль и заранее согласованные сроки реагирования.

Стоимость обслуживания в данном случае следует сравнивать не только с количеством часов программиста, но и с возможными последствиями простоя. При этом высокая стоимость пакета сама по себе не гарантирует надёжность. Необходимо понимать, какие обязательства берёт подрядчик.

Как оценить стоимость поддержки на практике

Для начала соберите задачи, которые возникали на сайте за последние три–шесть месяцев. Посмотрите, сколько из них были плановыми, сколько требовали срочного решения и какие проблемы могли повлиять на получение заявок или работу сотрудников.

Затем сравните предлагаемые условия:

• стоимость ежемесячного обслуживания;
• количество включённых часов и перечень работ;
• стоимость дополнительных задач;
• сроки реакции на обращения;
• порядок действий при авариях;
• условия резервного копирования и восстановления.

Особенно внимательно изучите разницу между временем реакции и временем устранения неисправности.

Если подрядчик обещает ответить на обращение в течение двух часов, это не означает, что любая поломка будет исправлена за два часа.

Например, восстановление сайта после сложного сбоя может потребовать диагностики, доступа к серверу и проверки сохранности данных.

В договоре желательно отдельно описать порядок обработки критических проблем, которые мешают принимать заказы или обращения.

Как понять, что подрядчик действительно выполняет свою работу

Самый простой способ — запросить понятный отчёт. При этом не обязательно требовать длинный технический документ с перечислением всех действий программиста. Для руководителя намного полезнее знать, что изменилось и какой результат получен.

Например:

«Обнаружена ошибка отправки заявок с мобильной версии сайта. Исправлена работа формы, выполнены контрольные отправки».

Это гораздо информативнее записи «Технические работы — 3 часа».

Другой пример:

«Перед обновлением системы создана резервная копия. Обновлены компоненты, проверены основные страницы, корзина и оформление заказа».

Такой отчёт объясняет, какие действия выполнены и какие функции проверены.

Если за месяц никаких ошибок не обнаружено, подрядчик тоже может сообщить об этом. Нормальная работа сайта — положительный результат, но желательно понимать, какие именно проверки проводились.

На что обратить внимание в договоре

Помимо стоимости и перечня работ, имеет смысл проверить следующие условия.

• Ответственность за доступы. У компании должны оставаться необходимые права на домен, хостинг, систему управления и используемые сервисы. Порядок хранения и передачи доступов должен быть понятен.
• Резервные копии. Желательно определить периодичность копирования, срок хранения, состав сохраняемых данных и порядок восстановления.
• Согласование изменений. Существенные доработки и дополнительные расходы не должны появляться без согласования.
• Сроки обработки обращений. Для обычных задач и критических неисправностей могут действовать разные условия.
• Передача сайта другому специалисту. При завершении сотрудничества компания должна иметь возможность продолжить работу с собственным сайтом без искусственных ограничений.

Особенно важно последнее условие. Зависимость от одного подрядчика не должна превращаться в невозможность обслуживать сайт у другой команды.

Когда стоит пересмотреть действующий договор обслуживания

Даже если компания давно сотрудничает с подрядчиком, условия поддержки полезно периодически пересматривать.

Например, раньше сайт использовался как электронная визитка, а теперь через него поступает значительная часть обращений. В таком случае прежнего уровня контроля может быть недостаточно.

Или наоборот: компания сократила количество изменений на сайте, отказалась от части функционала, но продолжает оплачивать большой пакет часов.

Поводом для пересмотра также могут стать:

• повторяющиеся ошибки,
• длительное ожидание решения простых задач,
• отсутствие понятной информации о выполненных работах
• или постоянные дополнительные счета.

Однако не стоит оценивать подрядчика исключительно по количеству исправленных неисправностей. Если сайт стабильно работает, а проблемы выявляются до того, как их замечают посетители, это тоже результат качественного обслуживания.

Как выбрать подходящий формат поддержки сайта

Начинать стоит не с тарифов, а с оценки самого сайта.

• Определите, какие функции критичны для бизнеса,
• кто отвечает за техническое состояние ресурса,
• насколько часто требуются изменения
• и что произойдёт при серьёзном сбое.

Если сайт небольшой, обновляется редко и не участвует в важных операциях, может быть достаточно базового контроля с возможностью заказывать дополнительные работы.

Для активно развивающегося корпоративного сайта разумно предусмотреть регулярные часы на исправления, обновление информации и небольшие улучшения.

Интернет-магазинам, сервисам с личными кабинетами и проектам со сложными интеграциями обычно нужен более подробный регламент: контроль критических операций, понятная процедура восстановления и приоритетная обработка неисправностей.

Главный критерий хорошего обслуживания — не количество часов в счёте, а соответствие выполняемых работ реальным потребностям бизнеса.

Сайт должен оставаться работоспособным, безопасным и удобным для посетителей. А владелец компании должен понимать, за что платит, какие риски закрывает техническая поддержка и какие задачи потребуют отдельного бюджета.

Материал подготовлен командой «Гвард-ИТ».