Что выяснить до внедрения Битрикс24

• CRM

К вопросам по статье

Какую проблему должна решить CRM

Перед внедрением Битрикс24 нужно договориться, что изменится в работе команды. Например: обращения из общей почты должны получать ответственного, а договор — собираться из данных сделки. С такими примерами можно оценить первый этап. Список «воронки, роботы, отчёты» ещё не объясняет, что принимать после настройки.

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

Откуда приходят обращения

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

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

Как устроены этапы работы

Названия стадий должны отражать наблюдаемые события. Например, предложение действительно отправлено, встреча проведена, заказ согласован. Стадия «Думает» плохо объясняет, что делать менеджеру и когда возвращаться к клиенту.

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

Какие данные переносить

• Где сейчас хранятся клиенты и сделки.
• Есть ли дубли и устаревшие сведения.
• Какая история нужна в ежедневной работе.
• Кто проверяет сопоставление полей.
• Как согласуется доступ сотрудников.
• Как подтвердить корректность переноса на контрольной выборке.

Практическая подготовка: превратить пожелания в проверяемый первый этап

Попросите руководителя отдела и одного менеджера показать недавнее обращение: откуда оно пришло, кто ответил и где записан следующий шаг. Затем разберите обращение, которое зависло. Эти два примера помогают отделить проблему настроек от отсутствующего правила — например, кто подхватывает клиента, когда ответственный недоступен.

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

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

Входной пакет не обязан быть длинным техническим заданием. Достаточно схемы первого процесса, перечня источников, нужных данных, ролей и контрольных сценариев. При этом каждая формулировка должна иметь практический смысл. «Сделать удобную CRM» нельзя принять одинаково всеми сторонами. «Новая заявка из формы создаёт запись, назначается действующему менеджеру и содержит предмет обращения» уже можно проверить.

Интервью по процессу: задавать вопросы о последнем реальном обращении

Вместо общего вопроса «как у вас устроены продажи?» попросите показать путь недавнего обращения без раскрытия лишних личных данных. Откуда оно пришло, кто первым увидел, что сделал и где появился следующий шаг? Затем разберите случай, когда всё пошло не по обычному маршруту. Именно исключение часто объясняет, почему формально правильная воронка не помогает команде.

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

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

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

Источники обращений и технические зависимости

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

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

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

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

Модель данных: оставить только то, что имеет получателя

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

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

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

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

Роли и ответственность без выдачи всем полного доступа

Сначала перечисляют действия сотрудников. Кто принимает новое обращение, кто готовит предложение, кто сопровождает заказ и кто видит сводный результат? Затем определяют нужные данные для каждой роли. Отдел продаж и сервис могут работать с одной историей, но не обязаны получать одинаковые полномочия во всех разделах.

В Битрикс24 права CRM настраиваются через предусмотренную ролевую модель; конкретное поведение и доступность зависят от текущего портала и условий продукта. Поэтому настройку принимают под обычным сотрудником. Администратор способен открыть то, что менеджер не увидит. Уведомление со ссылкой также не гарантирует, что человеку доступны связанные данные и нужное дело.

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

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

Пилот и обучение как проверка процесса

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

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

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

Сценарии приёмки до обязательного запуска

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

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

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

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

Бюджет, ограничения и следующий этап

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

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

После запуска наблюдают данные за согласованный период: время нужного действия, обращения без ответственного, причины исключений и качество использования полей. Правила показателей определяют заранее. Автоматическое уведомление не следует считать ответом менеджера, а число карточек — выручкой. Экономический эффект оценивают по реальным наблюдениям, не придумывая проценты из успешной демонстрации.

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