- «Сайт же работает, зачем нам постоянная поддержка?»
- «Работает - это открывается главная. А заявки доходят, CRM не отвалилась, SSL не истек, копии восстанавливаются?»
- «Обычно мы узнаем это уже после сбоя».
Я слышал этот разговор десятки раз. Почти всегда картина одна: сайт снаружи живой, а деньги уходят через тихую поломку, на которую никто не смотрел. Ниже - что в поддержке должно быть по умолчанию, где заканчивается сопровождение и начинается разработка, и какие цифры по рынку сейчас выглядят здоровыми.
Сайт может открываться - и уже терять вам лиды
Главная ошибка простая: руководитель открывает главную страницу, видит, что все грузится, и считает вопрос закрытым. На практике критичны другие цепочки: форма → почта или CRM, заказ → оплата, запись → уведомление менеджеру. Если рвется одно звено, сервер может отвечать с uptime 99,9%, но продажи уже проседают.
У нас был проект в B2B-услугах на Laravel 11 и PostgreSQL 16. Сайт открывался, формы показывали «успешно отправлено», UptimeRobot молчал. После смены SMTP заявки не доходили 9 дней, а менеджеры думали, что просто выдалась слабая неделя. Когда подняли логи и проверили путь заявки до CRM, увидели потерю около 27% лидов.
Поддержка начинается не с вопроса «упало или нет». Она начинается с контроля бизнес-сценариев: дошла заявка, создался заказ, вернулся статус оплаты, уведомление ушло нужному человеку.
«Самые дорогие инциденты - не падения сайта, а сбои в интеграциях, которые никто не заметил», - как рассказал CTO сервиса с онлайн-записью.
Поддержка - это регламент, а не человек на правки
Нормальная техподдержка - это набор повторяемых действий. Мониторинг, логи, бэкапы, обновления CMS и модулей, SSL, домен, восстановление после сбоев, исправление багов в существующей логике. Если подрядчик правит только по сообщению в чате, вы покупаете часы разработчика, но не профилактику инцидентов.
Мы обычно делим поток задач на четыре типа:
P1 - сайт недоступен / не проходят заявки
P2 - сломан критичный раздел или оплата
P3 - некритичный баг или редакторская правка
P4 - плановая доработка
На такой схеме споров меньше уже на первой неделе. Поменять телефон в шапке, продлить SSL, починить форму после обновления - это сопровождение. Новый личный кабинет, новая платежка, интеграция с ERP - уже отдельная разработка.
| Тип задачи | Что обычно входит | Что идет отдельно |
|---|---|---|
| Контент | телефон, баннер, текст, письмо | массовое наполнение |
| Стабильность | бэкапы, SSL, логи, баги | переезд на новый сервер |
| Функции | мелкая правка формы | кабинет, калькулятор, модуль |
| Интеграции | восстановить текущую связку | новая CRM или платежка |
Если нет Sentry, централизованных логов и алертов, подрядчик работает почти вслепую. В такой модели ошибки ловят по жалобам клиентов, а это уже поздно.
Почему цена отличается в разы
Стоимость зависит не от числа страниц. Она зависит от того, сколько у сайта точек отказа: старый WordPress с набором плагинов, CRM, платежи, доставка, телефония, внешние API, частые релизы, несколько подрядчиков в одной системе.
В прошлом году к нам пришел клиент после поддержки за 12 тыс. ₽/мес. На бумаге было все: «мониторинг», «оперативная реакция», «резервные копии». По факту - ответы в чате и правки сразу на проде. После обновления плагина сломалась корзина, а копия оказалась битой. Восстановление заняло 14 часов, и эта экономия закончилась в один день.
Рыночные ориентиры в 2026 году у меня такие:
- корпоративный сайт без интеграций - 15-30 тыс. ₽/мес
- сайт с CRM, каталогом и регулярными правками - 40-80 тыс. ₽/мес
- магазин или сервис с SLA - 80-150+ тыс. ₽/мес
Смотреть стоит не на абонплату, а на то, есть ли post-release check, проверяемые копии по правилу 3-2-1, staging, понятное время реакции и внятное восстановление. Хороший вопрос подрядчику - не «сколько стоит час», а «какой у вас RTO и RPO». По сути, это два параметра: за сколько восстановят сайт и сколько данных могут потерять.
Когда хватит разовых правок, а когда нужен SLA
Можно ли жить без абонентки?
Можно, если сайт обновляют раз в пару месяцев и он не влияет на выручку напрямую. Для визитки или простого корпоративного сайта пакет часов часто разумнее ежемесячного договора.
Когда без регулярной поддержки уже рискованно?
Когда сайт связан с лидами, записью, оплатой, кабинетом клиента или складом. На проекте для клиники у нас реакция на критичный сбой была 30-60 минут, релизы шли через staging, а после каждого обновления мы проверяли ключевые сценарии руками и автотестами.
Мы пришли к этому не сразу. Я и сам видел, как поддержка по переписке создает ложное ощущение контроля: несколько правок теряются, решение одного инцидента потом не воспроизводится, а повторный сбой оказывается вопросом времени. Когда-то мы вели часть таких задач именно так и несколько раз ловили повторные инциденты из-за незафиксированных изменений. После перехода в трекер, ежемесячного отчета и пострелизной проверки количество повторных аварий на одном проекте снизилось на 43% за 4 месяца.
Как быстро проверить подрядчика
Я бы просил не красивое КП, а короткий регламент на 2-3 страницы. По нему сразу видно, управляет подрядчик эксплуатацией или просто продает присутствие в чате.
Спросите пять вещей:
- где ведутся задачи и кто ставит приоритет
- есть ли staging и проверка после релиза
- чем ловят ошибки и кто смотрит логи
- как проверяют восстановление из копии
- что у них считается багом, а что доработкой
Если на эти вопросы отвечают общими словами, поддержки у вас пока нет. Есть надежда, что в нужный момент кто-то ответит, но это не эксплуатация в управляемом виде.
Самый полезный шаг в 2026 году простой: попросите у подрядчика один документ с границами работ, временем реакции и сценарием восстановления. Не прайс, а регламент. Рынок уходит от «человека на подхвате» к управляемой эксплуатации, и выигрывают здесь не самые большие бюджеты, а самые ясные правила.
