Портал, к которому полгода не подходил администратор, выглядит у всех примерно одинаково. В списке сотрудников числятся люди, уволившиеся весной. В базе три карточки одного клиента, и в каждой своя сумма сделок. Робот отправляет уведомления на почту бухгалтера, который давно сменился. Место на Диске кончилось, и менеджеры пересылают договоры через мессенджер, минуя CRM. Ни одна из этих ситуаций не выглядит как поломка: система запускается, кнопки нажимаются, ошибок нет.
Проблема всплывает позже и сразу целиком. Руководитель просит выгрузить воронку за квартал, видит цифры и не может им поверить. Начинается ручная сверка, которая съедает неделю и заканчивается выводом «в CRM бардак». Плановое обслуживание Битрикс24 нужно ровно для того, чтобы этот момент не наступал: мелкие расхождения ловятся, пока они ещё мелкие. Дальше идёт список того, что стоит проверять, с какой периодичностью, и что из этого закрывает штатный администратор без подрядчика.
Почему портал деградирует сам по себе
Битрикс24 не ломается от времени. Ломается соответствие между настройками портала и тем, как реально устроена компания: софт при этом остаётся полностью исправным. Настройки фиксируются один раз, в момент внедрения. Компания продолжает меняться каждый месяц.
Пришёл новый руководитель отдела продаж, у него другой взгляд на стадии воронки, но старые стадии никто не убрал, и менеджеры пользуются двумя наборами. Открылся филиал: сотрудников завели, а в структуру компании не поставили, поэтому отчёт по подразделениям их не видит. Маркетинг запустил новый источник заявок, форму подключили, а поле «Источник» в карточке лида не расширили, и весь трафик падает в «Другое».
Каждое расхождение по отдельности стоит недорого. Вместе они дают эффект, который руководители описывают одинаково: «CRM у нас есть, но решения мы принимаем по табличке в Excel». Регулярная проверка CRM возвращает системе статус источника правды, и работает это только при постоянной частоте. Разовая ревизия даёт эффект на месяц.
Регулярная проверка CRM: чистота базы
Быстрее всего в активной базе накапливаются дубликаты. Клиент оставил заявку с рабочей почты, через месяц позвонил с личного мобильного, потом написал в мессенджер с третьего номера. Формально это три разных лида.
В Битрикс24 для этого есть контроль дубликатов. Он настраивается отдельно для лидов, контактов и компаний: в нужном разделе CRM откройте настройки через шестерёнку и выберите «Контроль дубликатов». Там указываются поля, по которым система сверяет записи. Для лидов это ФИО, название компании, телефон и e-mail, для компаний берутся название, телефон и e-mail. После сохранения база сканируется кнопкой «Начать сканирование». Частота автоматических проверок задаётся в соседнем пункте настроек, «Автоматический поиск дубликатов».
Важно понимать границы механизма. Автоматически Битрикс24 объединит записи только тогда, когда совпадают значения всех полей карточек, за элементы отвечает один сотрудник, а лиды находятся на одной стадии канбана. Стоит менеджеру дописать комментарий в одну из карточек, и объединять придётся руками. Плюс функция доступна не на всех тарифах. Поэтому в регламенте обслуживания появляется отдельный пункт: раз в месяц разбирать очередь на ручное объединение. Одной галочки «включить контроль дубликатов» не хватит.
Вторая часть проверки смотрит на качество данных внутри карточек. Сколько сделок висит без движения дольше месяца. Сколько лидов в работе с датой создания в прошлом квартале. У скольких компаний не заполнен БИН, из-за чего не формируются документы. Эти выборки собираются фильтрами и занимают полчаса, а результат обычно объясняет, почему конверсия в отчёте выглядит хуже реальной.
Кто и что видит: доступы, увольнения, безопасность
Самая распространённая находка при аудите: активные учётные записи людей, которые в компании больше не работают. Иногда это просто занятое место в тарифе. Иногда речь про доступ к клиентской базе у человека, ушедшего к конкуренту.
Увольнение в Битрикс24 делается в разделе «Сотрудники»: в меню рядом с нужным человеком выбирается «Уволить». Сделать это может администратор портала или сотрудник, которому в структуре компании выдано право «Увольнение сотрудников». После увольнения человек теряет доступ, но его задачи, переписка и файлы остаются в системе, так что история работы не пропадает.
Дальше начинается то, что чаще всего забывают. Дела уволенного нужно передать: сменить ответственного в сделках, лидах, контактах, компаниях, предложениях и счетах. Задачи передаются отдельно, и сделать это может только администратор портала. Если шаг пропустить, клиенты остаются закреплёнными за несуществующим сотрудником, а в отчётах появляется менеджер-призрак с нулевой активностью и живой воронкой.
Раз в квартал стоит посмотреть шире. В разделе «Безопасность» проверяется, включена ли двухфакторная аутентификация и для всех ли она обязательна. Там же доступна история входов: дата и время, геопозиция, устройство, операционная система, браузер и IP-адрес. Администратор может открыть историю входов любого сотрудника и при необходимости принудительно завершить его сеансы на всех устройствах. Этим закрывают ситуацию с потерянным телефоном или уволенным в конфликте менеджером.
Заодно проверяется обратная сторона: у кого прав больше, чем нужно для работы. Со временем администраторов на портале становится трое или четверо, потому что доступ выдавали «на время задачи» и не забирали. Разумная норма для среднего бизнеса выглядит так: один основной администратор и один резервный, остальным достаточно прав на уровне своего отдела.
Место на Диске: скучно, пока не кончилось
Объём хранилища зависит от тарифа, и заканчивается он всегда неожиданно. Когда место исчерпано, загрузить новые файлы уже нельзя. Практический эффект: менеджер не может прикрепить подписанный договор к сделке и отправляет его в мессенджер. Документ выпадает из системы, а вместе с ним и из истории клиента.
Проверяется это быстро. На Диске есть раздел «Очистка места»: сканирование показывает, чем занято хранилище, и предлагает, что можно удалить безопасно. Обычно это корзина и неиспользуемые резервные копии файлов. Отмечаете нужное и нажимаете «Выполнить очистку». Есть и экспертный режим для детального разбора: обычный сотрудник видит там только свой диск, администратор видит диски всех сотрудников и рабочих групп.
Отдельно про корзину. Удалённые файлы лежат в ней 30 дней и всё это время занимают место. То есть «мы почистили диск» без очистки корзины даёт нулевой результат первый месяц. Обратная сторона того же правила: если файл удалили по ошибке, у вас есть эти 30 дней, чтобы его вернуть, а после срока восстанавливать будет нечего.
Для регламента полезнее смотреть на прирост: сколько гигабайт прибавляется за месяц. Абсолютная цифра «занято 40 из 100» сама по себе мало о чём говорит. Зная скорость роста, вы понимаете, когда упрётесь в потолок, и переходите на следующий тариф заранее, а не в пятницу вечером перед сдачей проекта.
Автоматизация, которая тихо перестала работать
Роботы и бизнес-процессы отказывают незаметнее всего. Пользователю они ошибку не показывают, просто перестают срабатывать, и никто об этом не узнаёт, пока клиент не спросит, почему ему до сих пор не прислали счёт.
Причины остановки предсказуемы. Робот отправлял письмо конкретному сотруднику, сотрудника уволили. Бизнес-процесс переводил сделку на стадию, стадию переименовали при реорганизации. Уведомление уходило на почтовый ящик, который отключили при смене подрядчика. Вебхук интеграции с сайтом перестал отвечать после переезда на новый хостинг, и заявки с формы не доезжают.
Проверка здесь ручная, и от этого никуда не деться: пройти по списку роботов в каждой воронке и сверить, что адреса, ответственные и стадии в их настройках всё ещё существуют. По конкретной сделке помогает вкладка «Ещё» → «История» в карточке: там видно дату и время изменения, кто его внёс и что именно поменялось. Если по сделке ожидалось действие робота, а в истории оно не записано, значит робот не отработал.
Интеграции проверяются сквозным тестом. Отправьте заявку с каждой формы на сайте, напишите в каждый подключённый мессенджер, позвоните на рабочий номер. Пять минут работы дают точный ответ, все ли каналы доезжают до CRM. Такой тест стоит делать после любого изменения на сайте, а не только по расписанию.
Каналы связи: телефония, почта, мессенджеры
Сбой в каналах связи стоит денег сразу. Заявка, которая не доехала до CRM, превращается в потерянного клиента, причём вы об этом даже не узнаете.
По телефонии проверяется несколько вещей. Оплачены ли номера и не истекает ли срок аренды в ближайший месяц. Все ли входящие звонки создают лид или подтягиваются к существующей карточке клиента, а не оседают безымянными. Записываются ли разговоры и хватает ли под записи места, потому что хранилище они занимают наравне с файлами.
По почте правило простое: у каждого менеджера подключён рабочий ящик, а не личный. Частая находка при обслуживании: сотрудник сменил пароль от почты и не обновил его в Битрикс24, из-за чего синхронизация молча отвалилась месяц назад. Всё это время переписка с клиентами идёт мимо CRM, и в карточке сделки видно только звонки.
По мессенджерам и открытым линиям стоит убедиться, что каждый канал привязан к действующей очереди сотрудников. Если в очереди остался уволенный человек, часть обращений распределяется на него и висит непрочитанной, пока клиент не напишет второй раз или не уйдёт к конкуренту.
Что добавляется в коробочной версии
Облачный портал обновляет вендор, и владелец о технической стороне не думает. С коробкой техническая поддержка Битрикс24 включает ещё и сервер, и это отдельный блок регламента.
Обновления ставятся из административной панели: раздел Marketplace → «Обновление платформы». Сначала обновляется сама система обновлений, кнопкой «Обновить систему SiteUpdate», затем ставятся апдейты продукта через «Установить рекомендуемые обновления» либо выборочно через вкладку «Список обновлений». SiteUpdate не затрагивает публичную часть портала и сохраняет данные.
Есть два условия, без которых обновление не пойдёт. Первое: активная лицензия и включённая настройка «Поддержка Битрикс24 в коробке» в админпанели. Второе: версия PHP. Для обновления сервер должен работать на PHP 8.1 или выше, а текущую версию видно в разделе «Настройки» → «Производительность» → «PHP». При этом с 1 февраля 2026 года поддержка продуктов на PHP ниже 8.2 ограничена, и вендор рекомендует 8.3 или новее. Если у вас коробка на PHP 7.4, откладывать обновление уже некуда.
Резервные копии в коробке остаются зоной ответственности владельца портала, вендор их за вас не делает. В регламент стоит внести и частоту бэкапа, и проверку восстановления: копия, которую ни разу не разворачивали на тестовом сервере, остаётся гипотезой. Отдельно в коробке существует журнал изменений, инструмент для руководителей и администраторов. Он фиксирует появление новых пользователей, изменение страниц и пунктов меню, события форума и библиотеки документов, а состав выводимой информации зависит от настроек администратора.
Как выглядит регламент на практике
Чек-лист без периодичности превращается в документ, который открывают один раз. Работает разбивка по частоте, где у каждой позиции есть ответственный и понятная длительность.
Раз в месяц, около часа: очередь дубликатов на ручное объединение, сделки без движения дольше 30 дней, сверка списка активных сотрудников с реальным штатом, объём Диска и прирост за месяц, сквозной тест форм и мессенджеров.
Раз в квартал, полдня: соответствие стадий воронки текущему процессу продаж, права доступа по группам и подразделениям, работоспособность роботов и бизнес-процессов по каждой воронке, история входов и статус двухфакторной аутентификации, ревизия установленных приложений Маркетплейса на предмет того, что реально используется.
Раз в год, один-два дня: пересбор структуры компании, инвентаризация полей в карточках (какие заполняются, какие мертвы), сверка тарифа с фактическим числом сотрудников, а для коробки план обновления PHP и продления лицензии.
Заведите этот регламент повторяющейся задачей в самом Битрикс24, с чек-листом внутри и ответственным. Тогда обслуживание перестаёт зависеть от того, вспомнил ли администратор.
Ещё одна строка регламента: фиксировать находки письменно. Список того, что нашли и починили в прошлом цикле, за год складывается в карту слабых мест портала. Видно, какие роботы ломаются чаще других, какой отдел стабильно не заполняет поля, где процесс расходится с настройками сильнее всего.
Пример: производственная компания, 40 сотрудников
Компания внедрила Битрикс24 в 2023 году, настроила воронку, подключила телефонию и почту, дальше два года пользовалась без единой административной ревизии. Обратились с формулировкой «CRM врёт по конверсии».
Первый же прогон контроля дубликатов дал около 900 пар в контактах: часть базы задваивалась по три-четыре раза, потому что один и тот же клиент писал на почту, звонил и оставлял заявку на сайте. Конверсия из лида в сделку из-за этого считалась примерно вдвое ниже реальной.
Вторая находка: семь активных учётных записей уволившихся сотрудников, за которыми числилось больше шестидесяти открытых сделок. Их никто не вёл, и в отчёте они выглядели как зависшая воронка. Третья: два робота из четырёх не работали больше года. Один отправлял уведомление на почтовый ящик, отключённый при смене провайдера, второй ссылался на стадию, переименованную во время реорганизации отдела.
Разбор занял три рабочих дня. Конверсия в отчёте выросла с 8% до 14%, и произошло это не потому, что продавать стали лучше, а потому, что знаменатель перестал быть выдуманным. Дальше компания перешла на ежемесячный регламент, и повторный аудит через полгода нашёл уже десятки расхождений вместо сотен.
Своими силами или на подряде
Часть чек-листа закрывает любой внимательный администратор внутри компании: дубликаты, увольнения, место на Диске, тест форм. Это не требует специальных знаний, требует дисциплины и полутора часов в месяц.
Сложности начинаются там, где нужно принимать решения об архитектуре: перестроить воронку под изменившийся процесс, разобраться, почему бизнес-процесс падает на конкретном шаге, обновить коробку с PHP 7.4 на 8.3 без потери работоспособности кастомных доработок. Здесь цена ошибки выше, а частота задач такая, что держать штатного специалиста экономически бессмысленно.
Мы в B2BPRO.KZ ведём плановое обслуживание порталов по такому же регламенту и параллельно закрываем аварийные ситуации. Техподдержка Битрикс24 24/7 означает, что при отказе интеграции или падении коробочного сервера заявку примут ночью и в выходной, а не в понедельник в девять утра. Для облачных порталов это чаще всего вопрос настроек и данных, для коробочных добавляются сервер, обновления и резервные копии.
Формат подписки удобнее разовых обращений из-за накопительного эффекта: подрядчик, который смотрит ваш портал каждый месяц, знает историю изменений и находит расхождения раньше, чем они превращаются в неделю ручной сверки. Если сейчас портал живёт без регламента, начните с одного прогона по чек-листу. Он покажет, насколько велик разрыв между настройками и реальностью, и уже из этого станет понятно, нужна ли вам поддержка в режиме 24/7 или хватит внутреннего администратора.
Частые вопросы
Как часто нужно проводить плановое обслуживание Битрикс24?
Рабочая схема состоит из трёх уровней. Короткая ежемесячная проверка на час: дубликаты, уволенные, место на Диске, тест форм. Квартальная на полдня: воронки, права доступа, роботы, безопасность. Годовая на один-два дня: структура компании, поля в карточках, тариф, а для коробки обновления и лицензия. Для компаний, где меньше десяти сотрудников и один канал заявок, месячный цикл можно растянуть до квартального.
Чем обслуживание облачного портала отличается от коробочного?
Содержательная часть общая: данные, доступы, автоматизация. В коробке сверху добавляется техническая: обновления через Marketplace → «Обновление платформы», версия PHP, состояние сервера и резервные копии, за которые отвечает владелец портала, а не вендор. Плюс в коробочной версии есть собственный журнал изменений с событиями по пользователям, страницам и пунктам меню.
Можно ли объединить все дубликаты автоматически?
Нет. Битрикс24 объединит записи сам только при полном совпадении значений всех полей карточек, при одном ответственном сотруднике и, для лидов, на одной стадии канбана. Любое расхождение выводит пару в ручное объединение. Функция к тому же доступна не на всех тарифах, так что ручной разбор очереди остаётся частью регламента.
Сотрудник уволен, а его сделки повисли. Что делать?
Сменить ответственного в элементах CRM: сделках, лидах, контактах, компаниях, предложениях и счетах. Задачи уволенного передаются отдельно, и передать их может только администратор портала. Сами данные при увольнении не удаляются: задачи, переписка и файлы человека остаются в системе.
Зачем поддержка 24/7, если компания работает с девяти до шести?
Отказы редко случаются в удобное время. Интеграция с сайтом падает ночью, когда меняют хостинг; коробочный сервер уходит в перезагрузку в выходной; массовая рассылка ломает почтовый канал в пятницу вечером. Режим 24/7 нужен не для ежедневной работы, а чтобы понедельник не начинался с потерянных за выходные заявок.