Запуск Битрикс24: что проверить перед началом работы сотрудников

Технически настроенная CRM ещё не означает, что внедрение закончено.

Можно создать воронки, настроить роботов, подключить телефонию и перенести клиентскую базу. Но до тех пор, пока сотрудники не начинают работать в системе по реальным сценариям, нельзя проверить главное: насколько CRM действительно соответствует ежедневной работе компании.

Именно поэтому перед реальным стартом нужен отдельный этап — финальная подготовка к эксплуатации. Его задача не в том, чтобы ещё раз посмотреть, «всё ли работает», а в том, чтобы убедиться: сотрудники понимают свои действия, данные попадают туда, куда нужно, автоматизация не мешает процессам, а руководитель получает из CRM достоверную картину.

Что проверить перед запуском

1. Сотрудники и права

Начать стоит не с роботов и интеграций, а с пользователей.

Для каждого сотрудника нужно проверить:

•   Создана учётная запись.
•   Указана правильная должность и подразделение.
•   Пользователь добавлен в нужные группы или команды.
•   Настроен доступ к необходимым сущностям CRM.
•   Ограничен доступ к чужим данным там, где это требуется.
•   Проверены права на просмотр, создание, изменение и удаление.
•   Руководители видят данные своих сотрудников и нужные отчёты.
•   Уволенные или не участвующие в работе сотрудники не имеют лишнего доступа.
•   Проверен вход в систему под несколькими типовыми ролями.

Особенно полезно выполнить такую проверку не только от имени администратора. Администратор почти всегда видит больше обычного пользователя и поэтому может не заметить проблем с правами.

2. Карточки CRM

Карточка должна отражать реальный рабочий процесс, а не просто содержать большое количество полей.

Проверьте:

•   Все нужные поля присутствуют.
•   Поля имеют понятные названия.
•   Убраны или скрыты поля, которые сотрудникам не нужны.
•   Поля расположены в логичном порядке.
•   Понятно, где хранится ключевая информация о клиенте.
•   Не создаются дублирующие поля с одинаковым смыслом.
•   Ответственные, контакты и связанные сущности отображаются корректно.
•   Карточка удобна для работы с телефона или другого используемого интерфейса, если это важно для процесса.

Хорошая карточка не пытается собрать в одном месте абсолютно всё. Она должна помогать сотруднику быстро понять состояние клиента и выполнить следующий шаг.

3. Обязательность полей

Обязательное поле — это не просто техническая настройка.

Если сделать обязательными слишком много полей, сотрудники начнут заполнять их формально: ставить случайные значения, писать «нет информации» или вводить данные, которые не несут смысла.

Поэтому для каждого обязательного поля стоит задать простой вопрос: зачем компании эта информация и что произойдёт, если её не заполнить?

Проверьте:

•   Обязательными являются только действительно необходимые поля.
•   Понятно, на каком этапе поле должно быть заполнено.
•   Значение поля можно получить из реального рабочего процесса.
•   Нет полей, которые невозможно заполнить на соответствующем этапе.
•   Значения используются дальше в отчётах, автоматизации или работе менеджера.

4. Воронки

Воронка должна соответствовать тому, как реально движется клиент.

Проверьте каждую стадию:

•   Названия понятны сотрудникам.
•   Последовательность отражает реальный процесс.
•   Для каждой стадии понятно, что означает нахождение клиента на ней.
•   Понятно, какое действие переводит клиента дальше.
•   Есть отдельные статусы для завершённых и проигранных сделок.
•   Причины отказа или другие необходимые признаки фиксируются.
•   Нет лишних стадий, которые сотрудники не смогут использовать одинаково.

Особое внимание стоит уделить переходам между стадиями. В реальной работе менеджер может воспринимать одну и ту же ситуацию иначе, чем команда внедрения. Именно такие расхождения часто становятся заметны после запуска.

5. Роботы и автоматизация

Автоматизация должна помогать процессу, а не создавать дополнительный шум.

Перед запуском проверьте:

•   Каждый робот имеет понятную цель.
•   Условия запуска соответствуют реальному процессу.
•   Роботы не запускаются повторно без необходимости.
•   Нет конфликтующих автоматических действий.
•   Проверены сценарии с отменой, возвратом на предыдущую стадию и изменением данных.
•   Ответственные получают именно те задачи, которые должны получать.
•   Автоматические задачи имеют понятные сроки и формулировки.
•   Тестовые роботы и временные настройки отключены.

Полезно отдельно проверить негативные сценарии: что произойдёт, если пользователь изменит поле обратно, перенесёт сделку на другую стадию или внесёт данные с задержкой.

6. Уведомления

Слишком большое количество уведомлений быстро превращает CRM в источник информационного шума.

Проверьте:

•   Сотрудник получает только необходимые уведомления.
•   Понятно, что требует действия, а что является информацией.
•   Уведомления приходят нужному человеку.
•   Нет повторяющихся сообщений от разных роботов.
•   Формулировки понятны без дополнительного объяснения.
•   Уведомления не дублируют друг друга в нескольких каналах без необходимости.

7. Телефония

Если звонки являются частью продаж или обслуживания, телефонию нужно проверять не только технически.

•   Входящие звонки определяют клиента корректно.
•   Новые номера обрабатываются по ожидаемому сценарию.
•   Исходящий звонок можно совершить из CRM.
•   История звонков попадает в нужную карточку.
•   Записи разговоров доступны тем, кому они положены.
•   Пропущенные звонки не теряются.
•   Ответственный определяется корректно.
•   Проверены разные номера и типовые сценарии звонков.

8. Мессенджеры

Подключённый канал ещё не означает, что коммуникация работает правильно.

Проверьте:

•   Входящее сообщение связывается с нужным клиентом.
•   Новый клиент создаётся по ожидаемому сценарию.
•   Ответ сотрудника уходит именно в тот канал, из которого пришло обращение.
•   История переписки сохраняется.
•   Ответственный назначается корректно.
•   Проверены повторные обращения существующего клиента.
•   Понятно, что происходит, если клиент пишет одновременно в разных каналах.

9. Почта

Для электронной почты стоит проверить не только факт подключения ящика.

•   Входящие письма привязываются к нужным клиентам и сделкам.
•   Новые отправители обрабатываются корректно.
•   Исходящие письма фиксируются в CRM.
•   Ответы на письма не создают лишние сущности.
•   Сотрудники понимают, из какого адреса отправляется письмо.
•   Проверены подписи и другие обязательные элементы.
•   Понятно, какие письма должны попадать в CRM, а какие — нет.

10. Сайт

Если заявки приходят с сайта, нужно пройти весь путь от посетителя до сотрудника.

•   Тестовая заявка создаёт нужную сущность CRM.
•   Передаются все необходимые данные.
•   Источник обращения фиксируется корректно.
•   Назначается правильный ответственный.
•   Клиент получает ожидаемое подтверждение, если оно предусмотрено.
•   Менеджер получает уведомление.
•   Роботы запускаются в правильный момент.
•   Данные не создают дубли при повторных обращениях.

Лучше сделать несколько тестов: обычную заявку, заявку существующего клиента, повторную заявку и заявку с неполными данными.

11. Импорт клиентов

Импорт — один из самых недооценённых этапов запуска.

До загрузки базы необходимо определить:

•   Какие данные действительно нужно переносить.
•   Какие поля соответствуют полям новой CRM.
•   Как будут обрабатываться дубли.
•   Какие значения нужно предварительно привести к единому виду.
•   Какие старые данные не стоит переносить.
•   Какие записи должны получить ответственных.
•   Как будут отличаться старые клиенты от новых обращений.

Желательно сначала импортировать небольшой объём данных и проверить результат в CRM. Массовую загрузку лучше выполнять после того, как сопоставление полей и правила обработки дублей уже проверены.

12. Отчётность

Отчёты нужно проверять не только на наличие графиков.

Главный вопрос: можно ли по ним принять решение?

Проверьте:

•   В отчётах используются правильные поля и стадии.
•   Показатели считаются так, как ожидает бизнес.
•   Нет дублей.
•   Фильтры работают корректно.
•   Руководители видят нужные данные.
•   Периоды и даты интерпретируются правильно.
•   Понятно, откуда берётся каждый ключевой показатель.
•   Сотрудники понимают, какие действия влияют на показатели.

Особенно важно проверить отчётность на реальных или максимально приближенных к реальности данных. На пяти тестовых сделках практически невозможно заметить проблему, которая станет очевидной на нескольких тысячах записей.

13. Обучение

Обучение — это не демонстрация всех функций CRM.

Сотруднику в первую очередь нужно объяснить:

•   Как принять новый клиентский запрос.
•   Как создать или найти клиента.
•   Как вести карточку.
•   Как работать со своей воронкой.
•   Какие поля обязательны и зачем.
•   Как фиксировать звонки и переписку.
•   Как ставить и выполнять задачи.
•   Что делать с просроченной задачей.
•   Когда и почему нужно менять стадию.
•   К кому обращаться при возникновении проблемы.

Лучший формат обучения — не «вот все кнопки системы», а прохождение нескольких реальных рабочих сценариев от начала до конца.

Финальный тест: пройти путь клиента целиком

Перед запуском полезно провести сквозной тест.

Например:

заявка с сайта → создание клиента → назначение ответственного → звонок → задача → изменение стадии → письмо → следующий этап → завершение сделки → попадание данных в отчёт.

Такой сценарий позволяет проверить не отдельные настройки, а связь между ними.

После этого стоит повторить тест для нескольких исключений:

• клиент уже существует;
• клиент не отвечает;
• сделка возвращается на предыдущий этап;
• меняется ответственный;
• клиент обращается повторно;
• обязательных данных недостаточно;
• сотрудник не выполняет задачу вовремя.

Именно на таких сценариях часто обнаруживаются последние проблемы.

Почему на этом внедрение не заканчивается

Есть важное различие между «CRM настроена» и «CRM готова к нормальной эксплуатации».

Настроенная система может технически работать без ошибок, но при этом не учитывать десятки небольших особенностей реального процесса.

В тестовой среде менеджер обычно выполняет заранее подготовленный сценарий. В реальной работе клиент пишет не в то время, приходит из другого канала, уже есть в базе под другим номером, меняет запрос, просит перезвонить через неделю или возвращается спустя несколько месяцев.

Тестовые данные редко показывают весь этот спектр вариантов.

Кроме того, после начала работы сотрудники начинают использовать CRM так, как им удобно. И здесь могут обнаружиться совершенно практические вопросы:

• почему это поле нужно заполнять именно здесь;
• почему задача создаётся дважды;
• куда попадает клиент, если он вернулся после закрытия сделки;
• что делать с повторным обращением;
• почему письмо не прикрепилось к карточке;
• почему в отчёте появилась лишняя сделка;
• какая стадия должна использоваться в конкретной ситуации.

Это не обязательно означает, что внедрение было выполнено плохо. Скорее, это естественный результат перехода от проектирования к реальной эксплуатации.

Первые недели — часть внедрения, а не период «после него»

Поэтому запуск лучше воспринимать не как точку, после которой проект внезапно заканчивается, а как переход к следующему этапу.

До старта проверяется то, что можно предсказать и протестировать.

После старта появляется то, что можно увидеть только на реальной работе: фактическое поведение пользователей, реальные клиентские сценарии, нестандартные ситуации, новые требования и взаимодействие между процессами.

В первые недели полезно регулярно собирать такие наблюдения и разделять их на несколько категорий:

1. Ошибка — система работает не так, как было задумано.
2. Недоработка процесса — настройка технически корректна, но процесс оказался неудобным.
3. Новый сценарий — ситуация не была известна на этапе проектирования.
4. Вопрос пользователя — функция работает правильно, но сотрудник не понимает, как ей пользоваться.
5. Новое требование — после начала работы бизнесу понадобилось что-то, чего изначально не планировали.

Такой подход помогает не пытаться исправлять всё одинаково. Где-то нужна техническая корректировка, где-то — изменение регламента, где-то — короткое обучение.

От запуска к сопровождению

Именно здесь естественным образом появляется сопровождение.

Его смысл не в том, чтобы бесконечно «чинить CRM», а в том, чтобы система продолжала соответствовать рабочему процессу после того, как этот процесс столкнулся с реальностью.

После запуска CRM постепенно становится частью ежедневной операционной работы. Меняются продукты, сотрудники, каналы обращений, правила продаж, показатели руководителей. Поэтому нормально, что система тоже развивается.

Хорошее внедрение заканчивается не в момент, когда все настройки отмечены галочками. Оно заканчивается тогда, когда команда может самостоятельно работать в CRM, а выявленные в реальной эксплуатации нюансы превращаются в понятные решения — технические, процессные или организационные.

Именно поэтому финальный этап перед запуском стоит рассматривать не как формальную приёмку настроек, а как подготовку системы и людей к реальной работе. А первые недели эксплуатации — как естественный переход от внедрения к сопровождению и дальнейшему развитию CRM.