К содержанию
AgentroОбсудить задачу

CRM и автоматизация

CRM начинается не с настройки: как поставить цель внедрения Bitrix24

Воронки, роботы и поля — это состав работ, а не цель внедрения. Разбираем, что определить до настройки Bitrix24 и как сформулировать проверяемый результат.

Владислав Теслюк10–12 минут
Этапы подготовки внедрения CRM от бизнес-цели до пилотного запуска
Интерфейс Bitrix24 и схема рабочего процесса: от цели внедрения до согласованного маршрута работы.
Содержание
  1. По каким симптомам компания обычно понимает, что ей нужна CRM
  2. «Поставить роботов» — не цель внедрения
  3. Как сформулировать измеримую цель
  4. Что нужно изучить до настройки
  5. 1. Откуда начинается процесс
  6. 2. Как выглядит реальный путь клиента
  7. 3. Где процесс живёт сейчас
  8. 4. Какие роли участвуют
  9. 5. Какие решения должен принимать руководитель
  10. Путь нормального внедрения
  11. 1. Цель
  12. 2. AS-IS: как работает сейчас
  13. 3. TO-BE: как должно работать
  14. 4. Архитектура
  15. 5. Прототип и пилот
  16. 6. Запуск и обучение
  17. 7. Контроль и развитие
  18. Короткий пример: почему архитектура важнее списка настроек
  19. Семь типичных ошибок при постановке задачи
  20. Ошибка 1. Цель подменяют списком функций
  21. Ошибка 2. Проектируют идеальный процесс, не изучив реальность
  22. Ошибка 3. Автоматизируют всё сразу
  23. Ошибка 4. Не назначают владельца процесса
  24. Ошибка 5. Строят отчёты на данных, которые сотрудники не заполняют
  25. Ошибка 6. Запускают без пилота
  26. Ошибка 7. Не договариваются о критериях приёмки
  27. Чек-лист перед началом внедрения
  28. Главное
  29. Обсудить задачу

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

В этот момент появляется понятное желание: купить Bitrix24, подключить телефонию, настроить роботов — и наконец навести порядок.

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

Поэтому нормальное внедрение начинается не с вопроса «какие роботы поставить?», а с вопроса:

Что конкретно должно измениться в работе компании после запуска системы?

По каким симптомам компания обычно понимает, что ей нужна CRM

Чаще всего решение о внедрении появляется, когда одновременно накапливаются несколько проблем:

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

Все эти симптомы важны. Но ни один из них ещё не является целью внедрения.

«У нас бардак», «не хватает контроля» и «хотим автоматизировать продажи» — это описание боли. Чтобы из неё получился проект, нужно понять, какое новое поведение должно появиться у сотрудников и какое решение сможет принимать руководитель.

«Поставить роботов» — не цель внедрения

В списке требований к CRM часто встречаются формулировки:

  • подключить телефонию;
  • создать несколько воронок;
  • настроить роботов;
  • добавить обязательные поля;
  • интегрировать сайт;
  • сделать отчёты;
  • обучить сотрудников.

Это нормальный список работ. Но он ничего не говорит о том, зачем компании всё это нужно.

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

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

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

Технология усиливает уже принятую управленческую логику. Она не заменяет её.

Agentro, рабочий материал

Как меняется работа

До → после

До

01

Обращения приходят в личные чаты и по телефону

02

Сотрудники ведут блокноты и собственные таблицы

03

Доступ к клиентской базе не регулируется

04

Рост упирается в личную продуктивность и объём ручной рутины

После

01

Все обращения собираются в одной системе

02

Клиентская база принадлежит компании и защищена ролями

03

Ответственный и следующий шаг видны

04

Рутина автоматизирована, а руководитель видит сроки и отклонения

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

Как меняется процесс: до и после

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

Схема подхода Agentro

Как сформулировать измеримую цель

Хорошая цель внедрения отвечает минимум на пять вопросов:

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

Плохая формулировка:

Внедрить Bitrix24, подключить источники и автоматизировать воронку.

Более рабочая формулировка:

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

Здесь уже понятно:

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

Ещё один пример.

Плохо:

Настроить CRM для контроля отдела продаж.

Лучше:

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

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

Что нужно изучить до настройки

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

1. Откуда начинается процесс

Нужно собрать все точки входа:

  • сайт и формы;
  • телефония;
  • email;
  • WhatsApp, Telegram и другие мессенджеры;
  • маркетплейсы и агрегаторы;
  • повторные обращения;
  • рекомендации;
  • офлайн-источники;
  • ручное создание клиента сотрудником.

Если часть обращений останется за пределами системы, отчётность с первого дня будет неполной.

2. Как выглядит реальный путь клиента

Нужно пройти путь от первого контакта до результата:

обращение → квалификация → предложение → согласование → договор → оплата → передача в исполнение → результат → сервис → повторная продажа.

На каждом шаге важно понять:

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

3. Где процесс живёт сейчас

Обычно часть данных находится в CRM, часть — в 1С, часть — в таблицах, почте и личных чатах.

До разработки нужно определить:

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

Иначе интеграция превращается в автоматический обмен дублями и ошибками.

4. Какие роли участвуют

Нужно проектировать не только права «видит / не видит», но и ответственность:

  • кто принимает обращение;
  • кто квалифицирует;
  • кто проводит встречу;
  • кто согласует цену;
  • кто формирует договор;
  • кто принимает оплату;
  • кто передаёт заказ дальше;
  • кто контролирует исключения;
  • кто отвечает за качество данных;
  • кто владеет самим процессом.

Если у процесса нет владельца, после запуска он снова начнёт расползаться.

5. Какие решения должен принимать руководитель

Отчётность нельзя проектировать в конце проекта по принципу «покажите всё, что есть».

Сначала нужно сформулировать вопросы:

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

Тогда становится понятно, какие поля, действия и статусы должны фиксироваться в CRM.

Путь нормального внедрения

1. Цель

Фиксируем бизнес-задачу, границы первого этапа и критерии результата.

2. AS-IS: как работает сейчас

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

3. TO-BE: как должно работать

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

4. Архитектура

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

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

5. Прототип и пилот

Сначала собираем минимальный рабочий контур и проверяем его на ограниченной группе пользователей.

Пилот показывает то, чего не видно на схемах:

  • где сотруднику неудобно;
  • каких данных не хватает;
  • какие поля лишние;
  • где робот срабатывает не вовремя;
  • какие исключения не учли;
  • что руководитель действительно смотрит, а что нет.

6. Запуск и обучение

Обучение должно идти по ролям и реальным сценариям, а не по всем кнопкам Bitrix24.

Менеджеру нужно показать, как принять обращение, провести сделку и зафиксировать следующий шаг. Руководителю — как контролировать отклонения и проводить разбор. Администратору — как поддерживать справочники и пользователей.

7. Контроль и развитие

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

CRM — не проект, который один раз «сдали» и забыли. Но её развитие должно идти по зафиксированной архитектуре и приоритетам, а не списком случайных хотелок.

Agentro, рабочий материал

Кто и что делает

Один понятный сценарий

01
Клиент

Оставляет обращение через согласованный канал — оно сразу попадает в общую систему.

02
CRM

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

03
Сотрудник

Уточняет задачу и переводит обращение дальше только после заполнения нужных данных.

04
Другие системы

Возвращают документ или статус, который видят сотрудник и руководитель в одной карточке.

Кто и что делает в процессе

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

Схема подхода Agentro

Короткий пример: почему архитектура важнее списка настроек

В одном корпоративном проекте нужно было объединить 13 направлений работы, около 150 сотрудников и большую историческую базу клиентов. Кроме Bitrix24, у компании уже были внутренний программный продукт, телефония и требования закрытой инфраструктуры.

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

Поэтому сначала провели обследование:

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

Только после этого началась техническая реализация.

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

Семь типичных ошибок при постановке задачи

Ошибка 1. Цель подменяют списком функций

«Нужны роботы, телефония и отчёты» — это ещё не ответ на вопрос, что изменится в бизнесе.

Ошибка 2. Проектируют идеальный процесс, не изучив реальность

На встрече руководители описывают, как люди должны работать. После запуска выясняется, что половина шагов выполняется иначе, а важные исключения никто не учёл.

Ошибка 3. Автоматизируют всё сразу

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

Ошибка 4. Не назначают владельца процесса

Систему формально внедрили, но никто не отвечает за правила, качество данных и дальнейшие изменения.

Ошибка 5. Строят отчёты на данных, которые сотрудники не заполняют

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

Ошибка 6. Запускают без пилота

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

Ошибка 7. Не договариваются о критериях приёмки

У клиента и исполнителя разные представления о том, что значит «CRM готова». В итоге настройки закончены, а рабочий процесс так и не появился.

Чек-лист перед началом внедрения

До настройки Bitrix24 у компании должны появиться ответы:

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

Если на половину вопросов нет ответа — это не повод отказаться от CRM. Это причина начать не с настройки, а с обследования.

Agentro, рабочий материал

Постановка и приёмка задачи

Шаблон рабочего поручения

01Контекст

Почему задача важна сейчас

02Результат

Что должно измениться после выполнения

03Приёмка

По каким признакам результат принят

04Ограничения

Срок, бюджет, правила и зависимости

05Полномочия

Что исполнитель решает самостоятельно

06Риски

Что проверить до старта

Обратная формулировка

Исполнитель своими словами подтверждает результат и критерии приёмки до старта.

Матрица постановки и приёмки задачи

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

Пример рабочего материала Agentro

Главное

Bitrix24 не должна становиться цифровой копией старого беспорядка.

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

И только после этого появляются воронки, поля, роботы, интеграции и дашборды.

Так CRM превращается не в дорогую записную книжку, а в рабочую систему управления.

Обсудить задачу

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

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

Что делать дальше

Опишите текущую ситуацию. Я помогу определить, нужен ли отдельный проект и с какого шага разумно начать.

Предпроектное обследование
Добавить контекст

Согласие фиксируется с версией политики и временем отправки. Контактные данные не передаются в аналитику.

Владислав Теслюк

Автор

Владислав Теслюк

Бизнес-аналитик и руководитель Agentro. Помогает собственникам связать управленческую задачу с процессами, CRM, аналитикой и реализацией.

Материал обновлён 3 августа 2026 г..

Об авторе

Следующие материалы