У нас был B2B-проект, где снаружи все выглядело спокойно: трафик идет, формы на месте, менеджеры работают в CRM. Но заявок стало меньше, а стоимость лида за 5 недель выросла на 27%. Проверили путь заявки и нашли тихую поломку: после обновления CRM форма показывала успешную отправку, но часть обращений просто не доходила.
Такие истории опасны тем, что сайт не падает. Он продолжает работать и понемногу сливает деньги, пока команда обсуждает рекламу, SEO или сезонность.
У сайта есть третье состояние - «работает с потерями»
Обычно на сайт смотрят слишком грубо: если открывается, значит все в порядке, если нет - авария. На деле самая дорогая зона находится посередине. Кнопка на iPhone нажимается через раз, страница грузится 6-7 секунд, SSL продлили, но цепочка сертификатов собрана некорректно, интеграция с CRM теряет часть данных после смены полей.
Я много раз слышал один и тот же короткий диалог:
- Сайт работает?
- Да, открывается.
- А все заявки доходят?
- Не проверяли.
Этого уже достаточно, чтобы понять, где риск. Деньги теряются не в момент падения сервера, а в тот момент, когда никто не проверяет ключевое действие пользователя.
Мы обычно ставим Sentry или Rollbar даже на небольшие проекты. Для форм и оплат добавляем отдельные проверки бизнес-сценариев, чтобы видеть не только uptime, но и то, что заявка, заказ или оплата реально дошли до конца.
Поддержка начинается там, где есть ритм
Формат «если что, пишите» звучит удобно, но по сути это очередь случайных проблем. Разовая техподдержка устраняет последствия. Системное сопровождение снимает часть инцидентов еще до того, как о них узнает клиент.
Рабочий ритм выглядит довольно буднично, но именно он дает результат: ежедневный мониторинг, еженедельная проверка форм и интеграций, ежемесячные обновления CMS и модулей, контроль логов, бэкапов, SSL и скорости. Когда такого ритма нет, сайт постепенно накапливает ошибки, которые никто не замечает.
| Разовая починка | Системная поддержка |
|---|---|
| Чинят форму после жалобы | Проверяют путь заявки по графику |
| Обновляют плагин по просьбе | Обновляют и тестируют по регламенту |
| Делают бэкап «на всякий случай» | Держат понятные RPO и RTO |
| Узнают о падении от клиента | Получают алерты через UptimeRobot или Better Stack |
У одного проекта на WordPress + WooCommerce мы перевели работу из режима «правки по мере поступления» в обычный месячный регламент. Через квартал число критических инцидентов снизилось с 6-8 до 1-2. Внешне сайт почти не изменился, но команда перестала жить в ожидании сюрпризов.
После релиза деньги часто утекают через технику, а не через дизайн
После редизайна бизнес обычно смотрит на внешний вид, маркетинг - на конверсию, а разработка выдыхает после деплоя. Просадка часто приходит позже, через 2-4 недели, когда поисковики заново обходят страницы, а пользователи доходят до реальных сценариев.
Был проект после редизайна на WordPress: новый сайт выглядел лучше старого, но органика за месяц просела на 27%. Причина оказалась простой: не настроили 301-редиректы со старых URL, часть canonical сломали, а несколько форм после релиза никто не прогнал руками.
Что мы обычно проверяем сразу после запуска:
- 301-редиректы со старых адресов
- robots.txt, sitemap.xml, canonical
- мобильную версию и метрики в Lighthouse
- формы, корзину, оплату, CRM-интеграции
- ошибки в Search Console и Яндекс Вебмастере
На деле Screaming Frog в первые часы после релиза полезнее, чем еще один созвон про отступы на первом экране.
Самые дорогие сбои живут тихо и долго
Тут у нас был и свой неудачный опыт. Несколько лет назад на e-commerce-проекте мы ограничились базовым мониторингом доступности и не поставили отдельный контроль сценария заказа. Сайт оставался онлайн, но часть оплат на мобильных проходила с ошибкой почти 9 дней, пока это не стало видно по цифрам продаж.
С тех пор правило простое: мониторить нужно не только uptime, но и ключевые действия пользователя. Если бэкап делается раз в неделю, а заявки приходят каждый день, это уже не защита, а допущение потерь.
Зрелость поддержки видна по числу проблем, которые не дошли до чата, а не по скорости ответа в нем.
У компании с ежедневными заявками мы однажды разбирали сбой после неудачного обновления модуля. Базу подняли только к вечеру, часть данных за день восстанавливали вручную из почты и мессенджеров. После таких случаев разговор про RPO и RTO быстро становится предметным: сколько данных бизнес готов потерять и как быстро сайт должен вернуться в работу.
Кто отвечает за сайт, должно быть понятно без созвона
Штатный специалист, фрилансер или подрядчик - вопрос не привычки, а управления. Важно, есть ли единый ответственный контур: очередь задач, журнал изменений, правила эскалации, доступы, мониторинг, резервный человек на случай отпуска или болезни.
Я видел проект, где за сайт одновременно отвечали маркетолог, фрилансер и хостер. Формально у каждого была своя зона, по факту - ничья. После перехода на единое сопровождение средний срок решения критических проблем сократился с 2-3 дней до нескольких часов.
Если хотите быстро проверить риск у себя, задайте команде пять вопросов:
- кто каждый день проверяет, что заявки доходят до CRM;
- где видны ошибки форм, оплат и интеграций;
- как часто бэкапы тестируются на восстановление;
- кто выпускает обновления и где они сначала проверяются;
- кто подхватит сайт, если основной специалист недоступен.
Если на старте у вас была форма, которая «успешно отправляла» заявки в пустоту, проблема была не в форме. Проблема была в том, что бизнес жил без системы контроля. Сайт редко просит помощи громко - чаще он просто молча забирает деньги из вашей воронки.
