Есть особый жанр бизнес-историй:
полгода собирали сайт на 1С-Битрикс, все мучились, все согласовывали, сделали релиз…
И дальше — тишина.
Маркетинг живёт своей жизнью.
Отдел продаж — своей.
Разработка — «ну если что-то прям сломается, пишите».
Через год:
- половина форм ведёт на мёртвые почты;
- половина интеграций живёт на костылях;
- SEO матерится из-за дублей и бардака;
- обновления не ставились «чтобы не ломать»;
- любая доработка стоит в три раза дороже, потому что никто не хочет лезть в это болото.
А владелец бизнеса, глядя на всё это, искренне спрашивает:
«Почему наш сайт ничего не даёт, хотя мы в него столько вложили?»
Потому что сайт — это не памятник дизайну.
Это живой организм. И если его не обслуживать нормально, он превращается в тухлый актив, который вроде «есть», но только мешает.
Давай разберу, как я выстраиваю поддержку и развитие Битрикс-проекта, чтобы он не умер через год после запуска.
1. Поддержка — это не «звони, когда всё упадёт»
Самая тупая модель:
«Если что-то сломается — напишем разработчику, он починит».
И дальше начинается:
- сайт уже неделю отправляет заявки на старый e-mail — никто не заметил;
- интеграция с 1С падает раз в три дня — привыкли, «это нормально»;
- корзина ломается под акцией — узнаём от злых клиентов.
Поддержка «по вызову» — это не экономия.
Это регулярные внезапные минусы:
- пропущенные заявки;
- сорванные рекламные кампании;
- слитый трафик.
Нормальная модель — когда у проекта есть регулярный тех-чек и понятный регламент.
Не пожарная команда, а плановый сервис.
2. Какие задачи вообще должны быть «на постоянке»
Я, когда беру проект на сопровождение, делю всё на четыре корзины:
1) Аварийка (когда всё горит)
- сайт не открывается / 500-ошибка;
- не оформляются заказы;
- не отправляются формы;
- не проходит оплата;
- не работает критичная интеграция (1С/CRM).
Это то, ради чего нужен быстрый канал связи и чёткое:
кто поднимает попу и идёт чинить прямо сейчас, а не «в понедельник посмотрим».
2) Регулярный техосмотр
Раз в месяц/квартал нужно пройтись по проекту с фонариком:
- ошибки в логах;
- состояние базы (мусор, веса таблиц);
- обновления модулей и безопасности;
- состояние интеграций (нет ли постоянных ошибок обмена);
- скорость ключевых страниц.
Это всё можно делать планово.
И если делать — сайт перестаёт жить в режиме: «мы узнаём о проблеме только когда она уже бьёт по деньгам».
3) Мелкие улучшения UX/конверсии
То, что не пожар, но даёт отдачу:
- поднять форму выше;
- сократить поля в заявке;
- поправить шаги оформления заказа;
- добавить нормальный текст/оффер.
Это как подтяжка болтов на машине:
каждая по мелочи, но в сумме сильно влияет на то, **как едет».
4) Стратегические доработки
Крупные штуки:
- новый раздел/направление;
- новая логика доставки;
- мультирегионы;
- переработка каталога;
- новый личный кабинет.
Их надо планировать, а не «впихивать между тушением пожаров».
3. Без формата работы всё превращается в ад “можешь вот это глянуть?”
Если не договориться про формат сопровождения, будет вот так:
- маркетолог скидывает задачи в чат;
- директор звонит «срочно поправить одну кнопку»;
- SEO пишет в письмах «вот список доработок»;
- разработчик половину забывает, половину делает вперемешку.
И в конце месяца все недовольны:
- бизнес: «мы платим, а что сделали — непонятно»;
- разработчики: «вы нас дёргаете хаотично, а потом спрашиваете, почему нет результата»;
- маркетинг: «ничего не успевают».
Как я делаю по-человечески:
1) Один вход для задач
Не чат, не голосом, не «письмом на почту».
А нормальный таск-менеджер: туда падает ВСЁ:
- баги;
- хотелки;
- идеи;
- срочные вопросы.
2) Приоритизация раз в неделю/две
Собрались (онлайн, не обязательно лично):
- разобрали, что критично;
- что можно отложить;
- что пока вообще не трогаем.
Формируем список задач на ближайший спринт.
И всё: пока он не сделан — не кидаем сверху новые «срочно-срочно», если это не авария.
3) Отчёт не «отработано 20 часов», а «что изменилось на сайте»
В конце периода:
- список задач → что сделано;
- ссылки на результат (страницы, формы, фичи);
- если возможно — цифры: как это повлияло.
«Починили баг с корзиной, перестали терять N% заказов».
«Упростили форму, конверсия такой-то страницы выросла с X до Y».
Тогда это сопровождение бизнеса, а не «часов нащёлкали».
4. Сколько часов сопровождения вообще нужно?
Вопрос, который мне задают почти всегда.
Ответ честный: зависит от стадии жизни проекта.
Если сайт свежий и активно развивается
Много идей, много изменений, постоянно крутите маркетинг, пробуете новое —
нормальный режим:
- от 20–40 часов в месяц и выше.
Потому что:
- что-то доделываете;
- что-то чините после реальных пользователей;
- что-то улучшаете по аналитике.
Если сайт зрелый, без постоянных «революций»
Функционал более-менее устаканился, доработки — эпизодически:
- 10–20 часов в месяц спокойно хватит на:
- техосмотр;
- аварийку;
- небольшие улучшения.
Главное — не уходить в ноль.
Когда у проекта нет даже минимальной поддержки — он деградирует.
Если у вас сейчас «только аварийка по звонку»
Это даже не нижний уровень.
Это вообще «без ремня безопасности».
Каждый выезд по 5–10 часов в самый неудобный момент.
Каждый раз больно и дорого.
Проще ввести фиксированный минимум, чем жить в режиме «а вдруг опять упадёт в субботу вечером».
5. Кто внутри компании должен отвечать за работу с агентством / разработчиками
Ещё одна любимая дыра.
Кто «главный» по сайту:
- директор (которому вообще некогда);
- маркетолог (но он занят рекламой, и технических задач боится);
- никто (это самый частый вариант).
Я всегда прошу назначить одного человека-координатора. Это может быть:
- маркетолог;
- продакт/руководитель направления;
- иногда — собственник, если это малый бизнес и он реально вовлечён.
Его задачи:
- собирать хотелки изнутри (продажи, маркетинг, руководство);
- фильтровать бред и оставлять только то, что даёт выхлоп;
- приоритизировать задачи с разработкой;
- принимать результат.
Если этого человека нет — проект превращается в базар: каждый что-то хочет, никто ни за что не отвечает.
6. Почему “не трогать, если работает” — плохая стратегия для Битрикс
Фраза «не трогай — работать будет» звучит уютно.
До первого:
- обновления PHP у хостера;
- смены требований платёжной системы;
- обнаруженной уязвимости в старой версии;
- серьёзной доработки, которая упирается в древнее ядро.
На Битрикс долго сидеть на «медном веке» — значит:
- платить втридорога за любую доработку («сложно, старое всё, страшно трогать»);
- жить с рисками безопасности;
- не иметь доступа к новым фичам и интеграциям.
Нормальный подход:
- не прыгать на каждый свежий релиз;
- но и не запускать проект до состояния «последний раз обновляли при динозаврах»;
- хотя бы раз-два в год планово приводить систему в актуальное состояние, после тестов на стенде.
7. Как понять, что с сопровождением у вас уже всё плохо
Чисто по симптомам:
- вы узнаёте о проблемах от клиентов, а не раньше;
- разработчики реагируют только на «горит», на всё остальное — «потом» (который не наступает);
- у вас нет списка выполненных задач за последний месяц, только ощущение «что-то иногда делают»;
- маркетинг и SEO постоянно упираются в фразу: «разработчикам некогда, долго, дорого»;
- любая, даже простая доработка — это маленький стресс.
Если узнаёшь себя — это не значит, что «плохой подрядчик» или «плохой Битрикс».
Это значит, что нет системы сопровождения.
Сайт — это не разовый проект из серии «сделали и забыли».
На Битрикс тем более.
Либо ты относишься к нему как к живому механизму:
- планово обслуживаешь,
- аккуратно дорабатываешь,
- следишь за показаниями приборов (аналитика, логи, заявки),
Либо однажды утром просыпаешься с очень простым выводом:
«У нас есть сайт, в который мы ввалили деньги.
И ещё один бюджет рядом — на то, чтобы жить с последствиями того, что мы его потом забросили».