Антон Дегтярёвмессенджеры, ip-телефония и сайт: один поток лидов
На аудите почти всегда вижу одну и ту же картину: WhatsApp подключили в один месяц, звонки — в другой, форму на сайте настраивал ещё один подрядчик — и в итоге один и тот же клиент, написавший в мессенджер после звонка, превращается в CRM в два разных лида. Показываю архитектуру, которая убирает дубли и делает из трёх разрозненных каналов один сквозной поток.
почему три подключённых канала — это ещё не омниканальность
Формально в 9 из 10 компаний, которые приходят ко мне на аудит, каналы уже подключены: мессенджеры через Wazzup, IP-телефония с записью звонков, форма на сайте через виджет. Проблема не в подключении — каждый канал по отдельности работает штатно.
Проблема в том, что каждый канал настраивали отдельно и в разное время, и по факту это три параллельных потока данных в одну CRM, а не один поток. Клиент, который сначала позвонил, а через час написал в Telegram уточнить условия, в системе — два разных человека с двумя открытыми лидами, если между каналами нет связки по номеру телефона.
Омниканальность — это не «поставить виджет и мессенджер», а решить конкретную техническую задачу: как система понимает, что звонок, сообщение в WhatsApp и заявка с сайта — это один и тот же клиент, а не три новых.
корень проблемы: идентификация клиента, а не канал связи
Ключевая настройка, без которой омниканальность не работает — это правило дедупликации по номеру телефона в CRM. При создании нового лида или сделки система должна сначала проверить: есть ли уже контакт с этим номером, и если да — добавить активность в существующую карточку, а не плодить новую.
На практике это включается в настройках CRM — «Дубликаты» — и работает по номеру телефона и email. Частая ошибка, которую вижу на аудитах: правило дедупликации включено технически, но не настроено под реальный формат номеров. Клиент указал номер с +7, а телефония передала с 8 — система считает их разными людьми, потому что сравнивает строки, а не нормализованные номера.
Решение — привести формат номера к единому стандарту на входе, до того как заявка попадает в CRM: через настройку телефонии и правило нормализации номера в бизнес-процессе создания лида. Это займёт час работы один раз, а не будет создавать дубли на каждом пятом обращении.
сайт как точка входа, а не отдельный канал
Виджет на сайте — про его подключение я уже писал отдельно — в омниканальной схеме выполняет роль не самостоятельного канала, а точки переключения между остальными. Клиент видит на сайте три опции одновременно: написать в чат, заказать обратный звонок, написать в WhatsApp по кнопке — и выбирает то, что удобно именно ему в моменте.
Правильная настройка — все три опции виджета заведены на одну и ту же очередь открытых линий, а не на разные ответственные группы. Иначе получается парадокс: клиент написал в чат на сайте, не дождался ответа за 2 минуты, нажал кнопку WhatsApp на той же странице — и его сообщение обрабатывает уже другой дежурный менеджер, который не видит первую переписку.
Второй момент — форма обратного звонка должна создавать не отдельный лид, а звонок с меткой «сайт, форма обратного звонка», привязанный к телефонии. Тогда менеджер видит в карточке единую хронологию: сначала заявка с сайта, потом исходящий звонок, потом переписка — а не три несвязанных записи в разных разделах CRM.
единая очередь вместо трёх параллельных
Технически в Битрикс24 и звонки, и сообщения из мессенджеров, и чат с сайта попадают в раздел «Открытые линии» — при условии, что телефония тоже заведена как линия, а не работает в обход неё напрямую на отдельных менеджеров. Это принципиальный момент архитектуры: если звонки маршрутизируются отдельно от текстовых каналов, единого потока не получится в принципе, сколько бы каналов вы ни подключили.
На моих внедрениях я завожу одну общую очередь на все каналы для нового обращения и отдельную персональную маршрутизацию только для повторных клиентов — им нужно попадать сразу к тому менеджеру, кто уже вёл сделку, а не в общую очередь. Про то, как технически настроить такое распределение без ручного разбора, писал в статье про автоназначение ответственного.
Смешение логики — частая ошибка: пытаются одновременно распределять по загрузке менеджера и привязывать к предыдущему контакту в одном правиле. Работает только последовательная проверка: сначала «был ли уже контакт с этим номером», и если нет — уже тогда распределение по загрузке или другой стратегии.
карточка клиента как общая память между каналами
Смысл всей схемы — чтобы менеджер, отвечающий в любом канале, видел полную историю клиента, а не только текущую переписку. На практике это означает: в карточке контакта видна лента активности вперемешку — звонок 3 дня назад, сообщение в Telegram вчера, заявка с сайта сегодня утром — в хронологическом порядке, без переключения между вкладками.
Второй практический эффект — не нужно переспрашивать клиента то, что он уже говорил в другом канале. Частая жалоба клиентов на плохой сервис — «я уже всё рассказывал вашему менеджеру, а теперь снова спрашивают то же самое». Единая карточка убирает эту причину раздражения полностью, потому что новый менеджер видит контекст до того, как начинает разговор.
Третий эффект менее очевидный, но важный для отчётности: анализ воронки продаж становится честным. Если каждый канал считается отдельно, конверсия занижена искусственно — часть сделок «размазана» между несколькими карточками одного клиента и нигде не закрывается целиком.
типичные ошибки объединения каналов из практики
Первая — включают дедупликацию по email вместо телефона. В B2C-сегменте клиенты редко указывают почту в мессенджере, но всегда есть номер телефона — правило нужно строить именно вокруг него.
Вторая — забывают протестировать сценарий «один клиент, три канала» перед запуском в бой. На моих внедрениях обязательный шаг перед сдачей проекта — прогнать тестовое обращение через все три канала под одним номером и проверить, что в CRM появилась одна карточка, а не три.
Третья — разная логика рабочего времени в разных каналах: чат отвечает автоматическим сообщением после 18:00, а телефония продолжает принимать звонки без предупреждения об офлайне. Клиент получает противоречивый опыт в зависимости от того, каким каналом воспользовался, хотя компания одна и та же.
Четвёртая, самая дорогая по деньгам — не считают, какой канал реально приносит сделки, а какой только создаёт видимость активности. Без сквозной аналитики по объединённым карточкам разговор «отключить один из каналов» превращается в спор мнений, а не решение на цифрах.
с чего начинать объединение, если каналы уже подключены разрозненно
Не пересобирайте всё с нуля. Первый шаг — включить и проверить правило дедупликации по нормализованному номеру телефона, это самое дешёвое и самое важное изменение. Второй — свести маршрутизацию всех каналов на одну очередь открытых линий для новых обращений. Третий — прогнать тестовый сценарий с одним номером через все каналы и убедиться, что дублей не появляется.
Дальше уже можно донастраивать частности: приоритеты каналов, автоответы, специфичные правила для постоянных клиентов. Но без первых трёх шагов любая дополнительная автоматизация просто множит количество разрозненных карточек на одного клиента, а не решает исходную проблему.
Отдельно советую запланировать повторную проверку через месяц после запуска, а не считать объединение каналов разовой настройкой. Появляются новые сотрудники, добавляются новые формы на сайте, меняются номера у части клиентов — без периодической сверки правила дедупликации со временем начинают давать сбои именно там, где их никто не тестировал изначально.