Проект внедрения сдан, команда работает, руководитель видит воронку. Через два-три месяца выясняется неприятное: часть роботов не срабатывает, интеграция с сайтом отвалилась после обновления шаблона, в карточке сделки появилось шесть новых полей, которые никто не заказывал, а отчёт по менеджерам показывает цифры, не похожие на реальность.
Это не признак плохого внедрения. Это нормальная жизнь работающей системы: компания меняется, процессы уточняются, сервисы обновляются. Вопрос не в том, нужна ли техподдержка Битрикс24, а в том, кто её будет оказывать — штатный сотрудник, внешний подрядчик или комбинация из двух вариантов.
Ниже разбираем, что именно ломается после запуска, из чего складывается реальная стоимость каждой модели, как устроены пакеты часов и в каких случаях свой человек в штате действительно необходим.
Почему поддержка нужна даже после хорошего внедрения
Распространённое ожидание: качественно настроенная система не требует вмешательства. Оно верно ровно наполовину — правильная архитектура действительно избавляет от постоянных переделок, но не отменяет трёх источников изменений.
- Меняется компания. Появился новый канал продаж, открылось направление, наняли пятерых менеджеров, ввели новый регламент скидок. Каждое изменение требует отражения в системе.
- Меняется окружение. Обновилась 1С, сменился оператор телефонии, сервис мессенджеров выпустил новую версию, платформа изменила логику модуля.
- Уточняются процессы. Первые месяцы работы всегда выявляют то, чего не было видно на этапе проектирования: стадия оказалась лишней, а нужного поля не хватает.
Третий пункт особенно важен: система, которую не корректируют в первые месяцы, начинает расходиться с реальной работой. А как только она расходится с реальностью, менеджеры возвращаются в блокноты и мессенджеры — механику этого сопротивления мы разбирали в материале «Почему менеджеры не работают в CRM».
Шесть типовых поломок после внедрения
1. Роботы и триггеры перестают срабатывать
Самая частая заявка в поддержку. Робот был настроен на переход между стадиями, стадию переименовали или добавили новую — и условие больше не выполняется. Задачи не ставятся, напоминания не приходят, менеджеры не получают уведомлений. Внешне всё выглядит нормально, просто автоматизация тихо не работает.
Коварство ситуации в том, что об этом узнают не сразу: пропущенное напоминание не выдаёт ошибку, а просто не происходит.
2. Отваливаются интеграции
Второй по частоте случай. Обновили 1С — встал обмен. Сменили пароль технической учётной записи — остановилась синхронизация. Разработчики поправили форму на сайте — заявки перестали попадать в CRM и уходят на почту, где их никто не смотрит.
Заявки с сайта, потерянные на неделю, — прямой убыток, и в отличие от предыдущего пункта его можно посчитать.
3. Разрастание полей и стадий
Каждый администратор с правами что-то добавляет: поле «уточнить у клиента», стадию «на согласовании у РОПа», ещё одну воронку «на всякий случай». За год карточка сделки превращается в анкету на два экрана, менеджеры заполняют её выборочно, и данные в отчётах теряют смысл.
Это не техническая поломка, а деградация архитектуры — и лечится она не настройкой, а ревизией.
4. Права доступа перестают соответствовать структуре
Появились филиалы, сменился руководитель отдела, наняли подрядчиков на аутсорс. Права остались прежними: кто-то видит то, что видеть не должен, а кто-то не может открыть нужную сделку и просит коллегу «посмотреть за него».
5. Дубли и мусор в базе
Один клиент обратился через сайт, потом позвонил, потом написал в мессенджер — три карточки, три истории. Если правила дедупликации не настроены, а обмен с учётной системой работает по слабому ключу сопоставления, база деградирует незаметно, но необратимо.
6. Телефония и записи звонков
Звонки не привязываются к сделкам, записи не открываются, часть вызовов не фиксируется вовсе. Обычно причина на стыке систем: изменения на стороне оператора, истёкшие сертификаты, изменённые настройки маршрутизации.
Что вообще входит в понятие «поддержка»
Смешение трёх разных типов работ — причина большинства недоразумений с подрядчиками и завышенных ожиданий от штатного сотрудника.
| Слой | Содержание | Периодичность | Кто справляется |
|---|---|---|---|
| Инциденты | Что-то сломалось: встал обмен, не работает робот, пропали заявки | Непредсказуемо, требует быстрой реакции | Нужны компетенции по всей связке систем |
| Эксплуатация | Добавить пользователя, настроить права, поправить шаблон, обучить новичка | Регулярно, небольшими задачами | Достаточно подготовленного сотрудника внутри |
| Развитие | Новая воронка, смарт-процесс, интеграция, дашборд | Проектами, по мере роста компании | Требует проектирования, а не настройки |
Практический вывод: эти слои редко закрываются одним человеком или одной моделью. Штатный сотрудник хорошо справляется с эксплуатацией и плохо — с инцидентами на стыке систем. Подрядчик силён в инцидентах и развитии, но привлекать его для добавления пользователя нерационально.
Три модели поддержки
| Параметр | Штатный специалист | Подрядчик | Гибрид |
|---|---|---|---|
| Скорость реакции на мелкие задачи | Высокая: человек рядом | Зависит от условий договора | Высокая по эксплуатации |
| Знание процессов компании | Глубокое | Формируется со временем | Глубокое внутри, достаточное снаружи |
| Компетенции по сложным задачам | Ограничены опытом одного человека | Команда с разными специализациями | Сложное — наружу, простое — внутрь |
| Риск при отпуске или увольнении | Критичный: знания уходят с человеком | Отсутствует | Снижен |
| Загрузка | Постоянная оплата независимо от объёма задач | Оплата по факту работ | Гибкая |
| Работа со стыками систем | Часто вне зоны компетенции | Обычно основная специализация | Закрывается подрядчиком |
Как честно посчитать стоимость
Сравнение «зарплата специалиста против чека подрядчика» некорректно, потому что сравниваются несопоставимые величины. Полная стоимость штатного сотрудника включает больше, чем оклад.
Что складывается в стоимость своего специалиста:
- оклад и премиальная часть;
- налоги и взносы;
- рабочее место, техника, лицензии;
- подбор: время на поиск и вероятность неудачного найма;
- обучение и повышение квалификации;
- простой: часы, когда задач нет, а оплата идёт;
- риск замещения на период отпуска и болезни;
- стоимость привлечения подрядчика на задачи вне его компетенции.
Последний пункт обнуляет большую часть экономии в реальных проектах: сложную интеграцию или BI-аналитику штатный администратор обычно не делает, и её всё равно отдают наружу.
Что складывается в стоимость подряда:
- оплата фактических часов или пакета;
- время сотрудников компании на постановку задач;
- затраты на первичное погружение подрядчика в процессы.
Дальше остаётся подставить свои цифры и сравнить на горизонте года. Ключевой вопрос при этом не «что дешевле», а какой объём задач у вас реально возникает в месяц. Если это 5–15 часов, штатная единица простаивает. Если 60–100 часов регулярно, разговор о своём человеке становится осмысленным.
Как устроены пакеты часов
Наиболее распространённая модель подряда, и у неё есть особенности, о которых стоит знать заранее.
- Предоплаченный объём. Компания покупает пакет часов, из которого списываются фактические трудозатраты по задачам.
- Цена часа снижается с объёмом. Большой пакет обычно дешевле в расчёте на час, чем разовые обращения.
- Срок действия. У пакета есть период, в течение которого его нужно использовать. Это стоит проверять: неиспользованные часы могут не переноситься.
- Оценка до старта. Нормальная практика — оценка задачи в часах до начала работ, чтобы заказчик решал, стоит ли она этих затрат.
- Отчётность. Прозрачный отчёт о списаниях: какая задача, сколько часов, что сделано.
Главное преимущество модели — предсказуемость бюджета без содержания штатной единицы. Главное требование к заказчику — дисциплина в приоритизации: если задачи ставятся без разбора, пакет расходуется на мелочи, а важное остаётся неcделанным.
Как это устроено у нас, можно посмотреть на странице техподдержки Битрикс24: решение разовых и регулярных задач без переплаты и сюрпризов по времени.
Когда нужен именно свой человек
Есть сценарии, где штатный специалист оправдан, и притворяться, что подряд универсален, не стоит.
- Большая компания с постоянным потоком задач. Несколько десятков пользователей, регулярные изменения процессов, потребность в ежедневной поддержке команды.
- Битрикс24 как основная рабочая среда всей компании. Не только продажи: задачи, документы, HR, внутренние коммуникации, база знаний.
- Коробочная версия с доработками на уровне кода. Требует постоянного технического сопровождения и понимания инфраструктуры.
- Требования к конфиденциальности. Отрасли, где внешний доступ к данным нежелателен или ограничен регламентами.
- Свой отдел разработки. Если он есть, поддержка платформы логично встраивается в его контур.
Важная оговорка: даже в этих случаях подрядчика обычно не отменяют полностью — его привлекают на проекты развития и сложные интеграции, оставляя штатному сотруднику эксплуатацию.
Гибридная модель: как это работает на практике
Самая рабочая схема для компаний среднего размера — разделение по слоям задач.
Внутри компании назначается суперпользователь: сотрудник, который хорошо знает процессы и получает расширенные права. Он добавляет пользователей, настраивает несложные права доступа, правит шаблоны документов, обучает новичков, собирает и приоритизирует заявки от коллег. Это не отдельная должность, а часть роли — обычно РОП, руководитель бэк-офиса или сильный менеджер.
Наружу уходят инциденты на стыке систем, интеграции, смарт-процессы, BI-аналитика, ревизия архитектуры.
Эффект от такой схемы измеримый: 60–70% обращений закрываются внутри в течение минут, а внешний бюджет расходуется на задачи, которые действительно требуют квалификации. Дополнительный плюс — суперпользователь фильтрует поток, и подрядчик не тратит оплаченные часы на «подскажите, где нажать».
Сильно помогает база знаний внутри системы: типовые вопросы закрываются самостоятельно, а не через живого человека. Как это выглядит на практике — в проекте базы знаний в Битрикс24 для ООО «Трейд Такси», где сотрудники перестали задавать однотипные вопросы коллегам.
Как выбрать подрядчика: на что смотреть в договоре
- Время реакции. Зафиксировано ли, в какой срок подрядчик отвечает на обращение, и различается ли реакция по критичности задач.
- Каналы обращений. Где ставятся задачи: своя система, чат, почта. Устные договорённости в мессенджере теряются с обеих сторон.
- Оценка до работ. Получаете ли вы оценку в часах прежде, чем задача уйдёт в работу.
- Отчётность по списаниям. Видно ли, на что израсходован пакет.
- Судьба неиспользованных часов. Переносятся ли они на следующий период.
- Работа с чужим внедрением. Готов ли подрядчик поддерживать систему, настроенную другой компанией, и что для этого потребуется.
- Документирование. Остаётся ли у вас описание сделанных настроек — это то, что защищает от зависимости от подрядчика.
Пункт 7 стоит выделить: система, настройки которой существуют только в голове исполнителя, создаёт зависимость независимо от того, штатный он или внешний. Документация — обязательное требование, а не приятное дополнение.
Как снизить потребность в поддержке
Часть заявок можно устранить не быстрым реагированием, а профилактикой.
- Ограничить права на изменение структуры. Создавать поля и стадии должен один ответственный, а не каждый администратор.
- Вести журнал изменений. Что поменяли, когда и зачем — это первое, что спрашивают при разборе инцидента.
- Настроить уведомления о сбоях интеграций. Ответственный узнаёт об остановке обмена в тот же час, а не через неделю.
- Проверять систему после обновлений. Особенно после обновления учётной системы и сторонних сервисов.
- Раз в полгода делать ревизию. Убрать неиспользуемые поля, лишние стадии, неработающие роботы.
- Развивать базу знаний. Инструкции по типовым действиям снимают значительную часть обращений.
Отдельно про самостоятельные доработки: часть задач компания действительно может закрывать своими силами, и современные инструменты это упрощают — мы писали об этом в материале о вайбкодинге в Битрикс24. Разумная граница: небольшие утилиты и отчёты — можно своими силами, изменения в архитектуре и интеграциях — через того, кто отвечает за систему целиком.
Частые вопросы
Сколько часов поддержки нужно в месяц?
Зависит от размера компании и активности изменений. Ориентир: небольшой отдел продаж со стабильными процессами — единицы часов; компания с интеграциями и регулярными изменениями — десятки. Точнее считается по факту первых двух-трёх месяцев, поэтому начинать разумно с небольшого пакета.
Можно ли обойтись без поддержки совсем?
Первое время после запуска — нет: корректировки нужны почти всегда. Дальше возможно, если процессы стабильны, интеграций нет и внутри есть подготовленный сотрудник. Но при появлении обмена с учётной системой или телефонии риск остаться без компетенций в момент сбоя становится существенным.
Поддержит ли подрядчик систему, которую внедрял не он?
Как правило да, но потребуется аудит: нужно понять, как устроены воронки, автоматизация и интеграции. Это разовые часы на входе, зато дальше работа идёт предметно, а не наугад.
Что делать, если внедрявший подрядчик перестал отвечать?
Первым шагом — забрать доступы и зафиксировать текущее состояние системы: какие интеграции работают, где размещены обработчики, какие используются сторонние сервисы. Затем аудит и передача поддержки. Основная сложность обычно не техническая, а в отсутствии документации.
Стоит ли обучать своего сотрудника вместо найма?
Часто это лучший вариант: сотрудник, который знает процессы компании, осваивает эксплуатацию системы быстрее, чем внешний администратор погружается в специфику бизнеса. Обучение суперпользователя обычно входит в проект внедрения.
Как понять, что поддержка работает хорошо?
По трём признакам: заявки закрываются в предсказуемые сроки, повторяющиеся инциденты устраняются на уровне причины, а не симптома, и система за год не превратилась в свалку полей и стадий.
Что делать дальше
Выбор между своим специалистом и подрядчиком решается не принципом, а арифметикой: посчитайте объём задач за последние три месяца и разложите их по трём слоям — инциденты, эксплуатация, развитие. Обычно после такого разбора становится видно, что модель нужна гибридная, а спор «свой или внешний» был поставлен неверно.
Мы поддерживаем и системы, которые внедряли сами, и чужие внедрения после аудита. Подход тот же, что и в проектах: сначала разобраться, как устроена система и процессы, потом устранять причины, а не симптомы, — чтобы количество обращений со временем снижалось, а не росло.
Посмотрите, как устроена техподдержка Битрикс24 и комплексное внедрение, изучите наши кейсы или запишитесь на консультацию — оценим объём задач по вашей системе и предложим формат поддержки.
