В понедельник у клиента уже шел платный трафик, а оплат стало почти ноль. Снаружи сайт выглядел живым: каталог открывается, корзина считает, кнопки нажимаются. Ручная проверка показала простую и дорогую вещь: после обновления модуля Т-Банка заказ создавался, а шаг оплаты падал с ошибкой JavaScript. Релиз был, сайт «сделали», но в рабочем состоянии его никто не держал.
Я такое видел много раз на проектах, где после запуска все выдохнули и решили, что дальше сайт живет сам. Если через сайт идут заявки, оплаты, CRM и реклама, дальше начинается обычная эксплуатация. За нее потом и приходят счета.
После релиза начинаются обычные поломки, а не магия
Запуск - это момент, когда сайт выходит из тестовой среды в реальную. Там уже живут хостинг, SSL, почтовый сервис, CRM, аналитика, платежи, плагины и обновления PHP. Любая из этих штук может сломать деньги, хотя главная страница будет открываться как ни в чем не бывало.
У нас был интернет-магазин на Laravel 11 и PostgreSQL 16. Через 3 месяца после запуска изменилась схема поля в API Bitrix24, и лиды перестали попадать в CRM. Форма на сайте показывала «успешно отправлено», менеджеры сидели без обращений. Починили за 2 часа, но потерянные заявки уже никто не вернул.
Мини-диалог тут обычно такой:
- «Но сайт же готов?»
- «Готов. Это значит, что он открывается в браузере и работает в рамках того, что проверили на запуске».
- «А почему тогда еще платить?»
- «Потому что форма, оплата и письма любят ломаться не в день запуска, а в самый дорогой день месяца».
Нормальная поддержка - это короткий список понятных работ
Короче, нормальное обслуживание не выглядит как «все, что захотите». У него есть очень приземленный состав: мониторинг, бэкапы, обновления, проверка форм, писем, оплаты и критичных интеграций. Фильтр тут простой: работа либо снижает риск простоя, либо защищает данные, либо держит конверсию, либо экономит время команде.
Для обычного сайта компании я бы ожидал вот такой базовый набор:
- мониторинг доступности через UptimeRobot или Better Stack
- ежедневные бэкапы вне основного сервера
- обновления CMS, плагинов и серверных пакетов по графику
- тест форм, писем и оплаты
- реакция на критичный сбой по SLA
SEO, баннеры, новые блоки, тексты, редизайн, A/B-тесты, новый функционал - это уже отдельные работы. Их можно держать в том же договоре, но путать с поддержкой не стоит. И если подрядчик не тестирует восстановление из бэкапа, сам бэкап почти бесполезен. Мы однажды приняли проект, где копии делались полгода, а развернуть не удалось ни одну. У нас тоже была ошибка на старте: когда-то этот кусок процесса проверяли слишком формально, и потом пришлось пересобирать регламент уже на живых проектах.
Цена зависит от цены сбоя, а не от размера сайта
Маленький лендинг может быть дороже в сопровождении, чем большой каталог. Если на него льется реклама на 300 000 ₽ в месяц, а каждая заявка считается вручную, час простоя там стоит дороже, чем у спокойного сайта без трафика и интеграций.
Обычно все сравнивают абонентку по месячной сумме. Я бы смотрел на другое: время реакции, лимиты часов, стоимость срочных работ, кто отвечает за восстановление и сколько точек вообще может сломаться. Сайт с CRM, оплатой и рекламой - это уже не «страничка в интернете», а кусок операционки.
| Обязательно | Отдельно | По ситуации |
|---|---|---|
| мониторинг, бэкапы, обновления | SEO, контент, дизайн-правки | отчеты, мелкие улучшения |
| проверка форм и оплаты | новый функционал | доработка аналитики |
| критические баги | редизайн блоков | антиспам и скорость |
Переплата обычно сидит не в тарифе, а в хаосе
Самая дорогая модель - «сломается, тогда позвоним». Пока поломку заметят, бизнес уже теряет лиды. Потом оплачивает срочное подключение человека, который сначала полдня выясняет, где доступы, кто менял код и почему письма уходят через ящик сотрудника, уволившегося еще в прошлом году.
У нас был сайт на WordPress и WooCommerce, которым 8 месяцев никто не занимался. Плагины не обновлялись, доступы остались у старого подрядчика, часть почты шла через старый SMTP. После заражения хостинг ограничил проект, и очистка с восстановлением вышла примерно в стоимость 4 месяцев нормальной поддержки.
Был и другой кейс. В пиковый день перестала работать оплата, а подрядчик ответил через 6 часов - просто потому, что в договоре не было времени реакции. Формально он ничего не нарушил. По факту экономия на ежемесячном платеже сгорела за один день.
До и после тут выглядят так:
- до - «платим только когда что-то сломалось»
- после - 6 часов тишины, потерянная выручка, срочные часы по двойной ставке
- после наведения порядка - алерты, регламент, реакция на критичное за 15-30 минут
Что попросить у подрядчика до оплаты
Я бы не просил прайс первым сообщением. Я бы попросил короткий регламент на одну страницу: что входит в базу, что считается критичным инцидентом, где лежат бэкапы, кто проверяет доставку заявок, сколько стоит ночь и выходные и кто реально восстанавливает сайт после аварии.
Мы сами когда-то недооценивали этот кусок и продавали поддержку слишком общими словами. На практике это плохо и для клиента, и для команды. Если подрядчик не может показать правила работы простым языком, вы покупаете не сервис, а право еще раз разбираться в хаосе. Обычно это случается ровно тогда, когда касса уже течет мимо.
