Битрикс24 заводят обычно так: регистрируют портал, подключают форму с сайта, приглашают менеджеров — и через два месяца обнаруживают, что менеджеры по-прежнему ведут сделки в мессенджере, а в CRM лежат необработанные лиды. Регистрация портала занимает пять минут, внедрение — недели, и разница между ними не в количестве настроек, а в том, что настраивается и в каком порядке.
Что решается CRM, а что не решается ничем
CRM отвечает на несколько конкретных вопросов, и если они у вас не болят, внедрять её рано.
- Сколько заявок пришло и сколько из них никто не взял в работу
- На какой стадии сейчас каждая сделка и кто за неё отвечает
- Что именно обещали клиенту — переписка и записи звонков в одном месте, а не в личном телефоне менеджера
- Из какого источника пришли те заявки, которые дошли до денег, а не просто пришли
- Что происходит, когда менеджер уходит в отпуск или вообще уходит
Чего CRM не сделает: не заставит звонить, не исправит плохой продукт и не создаст процесс там, где его нет. Если продажи устроены как «кто первый увидел заявку, тот и звонит», CRM это не починит — она это зафиксирует и сделает видимым. Иногда этого достаточно, чтобы процесс появился.
Лиды или сразу сделки
Первое решение при настройке, и его чаще всего принимают по инерции. В Битрикс24 два режима работы CRM: классический, где заявка сначала попадает в лид и только после квалификации превращается в сделку с контактом и компанией, и простой, где лидов нет и заявка сразу становится сделкой.
Простой режим подходит, когда поток небольшой и почти все обращения целевые: в услугах это обычная ситуация. Лиды нужны, когда потока много и в нём заметная доля мусора — спам из форм, ошиблись номером, «а вы в другом городе есть». Тогда лид работает как фильтр: его либо конвертируют, либо закрывают с причиной, и в воронку сделок мусор не попадает, не портя конверсию.
Ошибка — включить лиды «на всякий случай» при пяти обращениях в день. Получается лишний шаг, который менеджеры проскакивают формально, и статистика по лидам оказывается бесполезной.
Воронка: стадии как смена ответственности
Стадии сделок придумывают либо слишком подробно, либо слишком обобщённо. Рабочий критерий один: стадия меняется тогда, когда меняется то, что нужно сделать дальше, или тот, кто это делает. Если между двумя стадиями действие одно и то же, это одна стадия.
Практический ориентир для сайта услуг — от пяти до семи стадий плюс два исхода: успех и провал с обязательной причиной. Причина отказа важнее, чем кажется: без неё через полгода нельзя ответить на вопрос, почему не покупают — дорого, долго, ушли к конкуренту или просто не отвечают.
- Несколько направлений — несколько воронок: новый клиент, повторная продажа, поддержка. Смешивать их в одной воронке нельзя, конверсия становится бессмысленной
- На каждой стадии — обязательные поля, без которых сделку нельзя протащить дальше. Это единственный способ добиться заполнения данных
- Дело на каждой открытой сделке: звонок, письмо или встреча с датой. Сделка без запланированного дела — это забытая сделка
- Счётчики в интерфейсе настраиваются так, чтобы у менеджера на экране было видно просроченное, а не общее количество
Сорок дополнительных полей в карточке сделки — верный признак, что внедрение пошло не туда. Поле имеет право на существование, если по нему потом строится отчёт или фильтр. Остальное — текст в комментарии.
Как заявка с сайта попадает в CRM
Здесь три варианта, и они отличаются не удобством, а тем, сколько контроля остаётся у вас.
CRM-форма Битрикс24, встроенная на сайт. Быстро, ничего программировать не надо, поля настраиваются в портале. Минусы — внешний скрипт на странице, который влияет на скорость, ограниченная гибкость вида и то, что форма визуально живёт отдельной жизнью от сайта.
Своя форма плюс входящий вебхук. Форма остаётся частью сайта, валидация и оформление ваши, а данные уезжают в CRM запросом к методам вроде crm.lead.add или crm.deal.add. Так делается в большинстве проектов: скорость не страдает, поля передаются любые, включая служебные.
Через приложение с OAuth. Нужно, когда обмен двусторонний и постоянный: статусы возвращаются на сайт, в личный кабинет подтягиваются сделки и документы. Сложнее, но это уже не «отправка заявки», а интеграция.
Что бы вы ни выбрали, важны две вещи. Первая — заявка не должна потеряться, если CRM недоступна: письмо и запись в базе сайта отправляются всегда, независимо от результата запроса к порталу. Вторая — контроль дублей. Один человек оставляет заявку с двух устройств, звонит и пишет в мессенджер — и в CRM появляются три записи об одном обращении. Поиск по телефону и почте перед созданием решает это на входе.
Источник заявки: главная причина заводить CRM
Если из внедрения оставить один пункт, это будет он. Без источника CRM показывает, сколько заявок пришло. С источником — какие каналы приносят деньги, а какие только заявки.
Механика такая. На сайте в форму добавляются скрытые поля: UTM-метки первого и последнего касания, страница, с которой отправлена заявка, и идентификатор посетителя Метрики. UTM надо сохранять в cookie на первом заходе, иначе после перехода по внутренним ссылкам они потеряются и все заявки окажутся «прямыми». Идентификатор Метрики читается из её API на странице и уезжает в сделку отдельным полем.
- UTM первого касания — по какому каналу человек узнал о вас
- UTM последнего касания — откуда пришёл в тот раз, когда оставил заявку
- Страница входа и страница отправки формы: показывает, какая посадочная реально работает
- Название формы — заявок из шапки, из блока внизу и из всплывающего окна должно быть видно по отдельности
- Идентификатор посетителя Метрики — он нужен для следующего шага
Следующий шаг — офлайн-конверсии. Сделка закрывается в CRM через две недели после заявки, и этот факт возвращается в Метрику и в рекламный кабинет по сохранённому идентификатору. Тогда реклама оптимизируется не по отправкам формы, а по сделкам, и отчёт по каналам строится по деньгам, а не по обращениям. Это та часть, ради которой мы обычно и настраиваем связку — подробнее в услуге веб-аналитики. Про базовую настройку целей до запуска рекламы у нас есть отдельный разбор.
Телефония и переписка
Звонок — тоже заявка, и до CRM он доезжает реже, чем форма. Два варианта: номер, арендованный внутри Битрикс24, или своя АТС, подключённая по SIP. Второй вариант дороже в настройке, но сохраняет номер и логику распределения, которые уже работают.
Что должно получиться в итоге: входящий звонок с незнакомого номера создаёт лид, со знакомого — открывает карточку клиента до того, как менеджер снял трубку, запись разговора остаётся в истории, пропущенный звонок становится задачей, а не строкой в журнале. Отдельно стоит завести подменный номер для рекламного трафика — тогда звонки тоже попадают в отчёт по источникам, а не в графу «не определено».
Мессенджеры и чат на сайте подключаются открытыми линиями: обращения из разных каналов попадают в одну очередь и привязываются к тому же клиенту. Ценность не в самом чате, а в том, что переписка остаётся в компании, а не в личном телефоне сотрудника.
Где заканчивается Битрикс24 и начинается 1С
Частая путаница: Битрикс24 воспринимают как замену учётной системе. Это разные инструменты, и разделение ответственности между ними надо проговорить до внедрения.
- CRM ведёт то, что происходит до оплаты: обращения, коммуникации, стадии, договорённости
- 1С ведёт то, что после: документы, склад, деньги, отчётность
- Точка стыка — счёт и факт оплаты: счёт формируется по данным учёта, оплата возвращается в CRM и двигает сделку
- Номенклатура живёт в учёте. Дублировать каталог в CRM руками смысла нет, для коммерческих предложений он подтягивается обменом
Если на сайте уже настроен обмен с 1С, добавление CRM ложится сверху без переделок: сайт остаётся витриной и источником заявок, 1С — учётом, Битрикс24 — местом, где живёт работа с клиентом. Когда обмена нет, начинать стоит с него, а не с CRM: без цен и остатков из учёта коммерческое предложение всё равно собирается вручную.
Роботы: когда их включать
Автоматизация в Битрикс24 умеет многое: при переходе на стадию поставить задачу, отправить письмо, напомнить о звонке, сменить ответственного, уведомить руководителя о зависшей сделке. Соблазн настроить это в первый день велик, и почти всегда это ошибка.
Причина простая: воронка в первый месяц меняется. Стадии переименовывают, часть убирают, появляются новые. Роботы, навешанные на стадии, при каждом изменении ломаются, и вместо помощи вы получаете рассылку писем не туда. Разумный порядок — сначала два-три месяца живой работы в воронке, потом автоматизация того, что действительно повторяется каждый раз.
Исключение — то, что защищает от потери заявки. Уведомление о необработанном обращении через заданное время и автоматическое назначение ответственного включаются сразу: они не зависят от структуры воронки.
Почему внедрения проваливаются
- Нет ответственного внутри компании. Подрядчик настроил, ушёл, поддерживать некому — через месяц портал зарастает
- Менеджеры продолжают вести сделки в блокноте, потому что «в CRM долго». Значит, полей слишком много или процесс описан не так, как работает
- Руководитель не смотрит отчёты. Если данные никому не нужны, их перестают вносить — это вопрос недель
- Настроили всё сразу: воронки, роботы, сквозную аналитику, задачи, документооборот. Освоить такое за раз невозможно
- Нет регламента: непонятно, когда переводить стадию и что писать в комментарии. Каждый делает по-своему, отчёты не сходятся
Все пять причин — организационные, ни одна не техническая. Поэтому внедрение, сделанное только руками программиста, обычно не приживается: настройка портала — это меньшая часть работы.
Порядок, который работает
- Описать, как продажи идут сейчас: кто берёт заявку, что делает, где теряется
- Собрать воронку по этому описанию, а не по идеальной картинке
- Завести только те поля, по которым будут отчёты
- Подключить каналы заявок: формы сайта, телефонию, мессенджеры
- Настроить передачу источника и сохранение UTM — до запуска рекламы, а не после
- Раздать права: менеджер видит свои сделки, руководитель — все
- Поработать месяц и поправить воронку по факту
- Добавить роботов на то, что повторяется каждый раз
- Вывести отчёты, которые руководитель будет смотреть еженедельно
Между четвёртым и седьмым пунктом проходит основное время, и оно тратится не на настройку, а на то, чтобы люди начали работать в системе. Без этого этапа остальные бессмысленны.
Мы разворачиваем Битрикс24 под процесс продаж, а не по шаблону: воронки, поля, права, каналы заявок, передача источника и офлайн-конверсии обратно в рекламу — внедрение Битрикс24. Связку с учётом делаем в том же проекте, если она нужна: интеграции сайта с учётными системами. Если заявки сейчас теряются и непонятно, где именно, начинать стоит с веб-аналитики — она показывает разрыв между трафиком и обращениями, и часто выясняется, что чинить надо не CRM.
