Что проверить, прежде чем подключать CRM: маршрут обращения, ответственность, дубли и контроль первого ответа.
Форма на сайте прислала запрос на расчёт. Письмо с тем же вопросом осталось в общем ящике. Через час клиент написал менеджеру в мессенджер. Для клиента это одна попытка получить ответ. Для компании без единого порядка это три разрозненных события: их могут обработать дважды, передать друг другу или не заметить вовсе.
Проблема обычно не в том, что сотрудники «плохо ведут CRM». Заявка теряется раньше: когда никто не обязан проверить конкретный ящик, корпоративный мессенджер смешан с личным, а форма на сайте отправляет уведомление туда, куда редко заглядывают. CRM помогает собрать следы обращения, но не назначает владельца процесса вместо руководителя.
Спешите? Перейдите к коротким ответам. Там разобрано, можно ли начинать с одного канала и что делать с личными мессенджерами менеджеров.
Единое место начинается с единого маршрута
Чтобы заявки не терялись, компании нужна одна точка учёта и понятный путь для каждого обращения. Это может быть CRM, а на раннем этапе иногда хватает общей таблицы. Выбор инструмента вторичен, пока не решены четыре вопроса: откуда пришёл запрос, кто принял его в работу, когда должен состояться первый ответ и чем завершается обработка.
Рабочий маршрут выглядит так:
Источник обращения → карточка или строка учёта → ответственный → первое действие → следующий шаг → результат
На каждом переходе должен быть виден исполнитель. Если письмо лежит в общем ящике, а ответственным считается «отдел продаж», фактически ответственного нет. Если чат привязан к личному аккаунту менеджера, подмена в отпуске зависит от того, передаст ли он телефон. Если заявка с сайта попадает в CRM, но без срока первого контакта, карточка становится аккуратно оформленной версией той же очереди.
Поэтому сначала опишите не настройки, а правило. Например: запрос из формы автоматически создаёт карточку; дежурный менеджер получает её в течение рабочего дня; после первого ответа он фиксирует следующий шаг и дату; без результата карточку не закрывают. Формулировку нужно проверить на реальной смене, а не только согласовать на встрече.
Не всякой компании нужна CRM прямо сейчас. Когда один сотрудник получает немного обращений, а таблица показывает источник, срок и следующий шаг без ручных обходов, сложная система добавит работу. CRM становится оправданной, когда каналов и участников уже столько, что руководитель перестаёт видеть путь клиента целиком.
Почему заявки пропадают ещё до CRM
Симптом обычно звучит просто: «Иногда забываем ответить». Но причины у этого симптома разные, и одна интеграция их не исправит.
Первая причина - источники перечислены не полностью. В карте руководителя есть сайт, телефон и почта. В реальности клиент может написать в Telegram конкретному менеджеру, ответить на старую цепочку писем, заполнить форму на отдельном лендинге или оставить сообщение в сообществе. Пока компания не признаёт этот канал рабочим, он не попадёт в систему надёжно.
Вторая причина - уведомление принимают за обработку. Письмо во входящих, push-уведомление или непрочитанный чат лишь сообщают о событии. Они не показывают, кто обязан действовать, не передают обращение коллеге и не заставляют поставить следующий контакт. Менеджер может отвлечься на звонок и вспомнить о сообщении позже. Руководитель узнает об этом только по жалобе клиента или случайной сверке.
Третья причина - в компании нет правила для повторного обращения. Клиент оставил номер в форме, затем позвонил и продублировал вопрос в мессенджере. Если каждое событие становится отдельной сделкой, менеджеры начинают параллельные диалоги. Если карточки склеивают без проверки, в историю одного клиента можно поместить обращение другого человека с общим телефоном или адресом.
Задача системы не в том, чтобы механически свалить все сообщения в один список. Она должна сохранить источник, связать обращение с нужным клиентом по согласованным признакам и передать его человеку, который отвечает за следующий шаг.
Сайт, почта и мессенджеры требуют разных сценариев
Одна и та же воронка может принять обращения из разных каналов. Но способ появления карточки, состав данных и проверка результата различаются. Сравним их до настройки.
| Канал | Что должно попасть в точку учёта | Главный риск | Контрольный сценарий |
|---|---|---|---|
| Сайт | Данные формы, страница или метка источника, согласие, время отправки | Одна из форм отправляет письмо, но не создаёт карточку | Отправить тестовую форму с каждой страницы |
| Почта | Письмо, вложения, адрес отправителя, ответственный и срок | Общий ящик читает несколько людей, но никто не берёт запрос в работу | Проверить новое письмо и ответ клиента в существующей цепочке |
| Мессенджер | Текст диалога, канал, клиент, очередь и история переписки | Клиент пишет в личный аккаунт или сообщение остаётся у недоступного сотрудника | Отправить сообщение в рабочее время и при отсутствии основного менеджера |
Заявки с сайта: проверьте все формы, а не главную кнопку
На сайте редко бывает одна форма. Отдельно работают «Заказать звонок», «Узнать цену», запись на встречу, форма в подвале и страницы рекламных кампаний. Часть из них может относиться к продажам, часть - к поддержке или вакансиям. Не стоит отправлять всё в одну воронку без разбора: менеджер по продажам не должен вручную отделять отклики на вакансию от запроса на услугу.
В Битрикс24 CRM-форма после отправки может автоматически создать лид, сделку, контакт, компанию или элемент смарт-процесса; для формы также указывают ответственного и правила работы с дублями. Это подтверждает официальная инструкция по CRM-формам. У другой системы набор сущностей и правила будут иными, поэтому до выбора тарифа проверьте именно свои формы и поля.
Полезно записать, какая форма создаёт какой тип обращения и в какой очереди его видят. Тогда при смене сайта или подрядчика можно провести контрольный тест, а не ждать первой пропущенной заявки.
Почта: общий ящик лучше личной договорённости
Если с входящими запросами работают несколько человек, общий почтовый ящик даёт команде точку передачи. Но сам по себе адрес `sales@` ничего не решает. Нужно определить, кто разбирает новые письма, как происходит подмена и в какой момент письмо становится задачей с конкретным сроком.
В Битрикс24 при подключённом ящике и включённой интеграции с CRM входящие письма автоматически попадают в карточку клиента. На каждое входящее письмо система создаёт «Дело», которое можно выполнить или заменить следующим действием; история переписки остаётся в карточке. Эти условия описаны в справке по работе с почтой в CRM. При этом уже прочитанное в почтовом ящике письмо может не дать уведомления в Битрикс24. Это веская причина проверять не только оповещения, но и сам маршрут письма.
Мессенджеры: сначала решите, какие аккаунты компания контролирует
Клиенту всё равно, корпоративный это чат или личный. Компании не всё равно. Переписка в личном мессенджере менеджера остаётся вне общего доступа, а другой сотрудник не сможет продолжить разговор без передачи контекста. Здесь сначала требуется управленческое решение: какие мессенджеры и аккаунты используются для работы с клиентами, а какие не считаются официальным каналом.
На примере Битрикс24 открытая линия собирает сообщения из мессенджеров, социальных сетей и онлайн-чата, распределяет их между менеджерами и сохраняет данные клиента в CRM. Для очереди можно задать способ распределения, время передачи следующему сотруднику и проверку доступности оператора, как указано в официальной инструкции по открытым линиям. Количество доступных линий зависит от тарифа и подключений, поэтому тестовое сообщение стоит отправлять уже на выбранном тарифе.
Автоматизация без правил делает разрыв заметнее
После подключения каналов карточек обычно становится больше. Это не значит, что реклама внезапно начала приносить больше спроса. Возможно, компания просто впервые увидела обращения, которые раньше оставались в почте и чатах. Такой результат полезен, но его нельзя записывать в рост лидов без сравнения первичных источников.
До роботов и уведомлений договоритесь о правилах обработки. Для этой темы достаточно пяти решений:
- Что считается новой заявкой, а что является продолжением известного диалога.
- Кто принимает обращение из каждого канала и кто его заменяет.
- Какой срок первого ответа допустим в рабочее и нерабочее время.
- Какой следующий шаг сотрудник обязан указать после первого контакта.
- Какие результаты закрывают заявку: продажа, отказ с причиной, нецелевой запрос, повторный контакт в будущем.
Не превращайте эти правила в большой регламент. Менеджер должен понимать их во время звонка или переписки, без поиска инструкции. Если правило нельзя объяснить одной фразой, настройка почти наверняка станет исключением, которое сотрудники будут обходить.
В Битрикс24 очереди можно настроить для мессенджеров, почты, CRM-форм и телефонии; система поддерживает строгое, равномерное и одновременное распределение в зависимости от канала. Полный список условий есть в документации по распределению обращений. Не выбирайте «самый умный» режим из доступных. Выбирайте тот, для которого понятно, кто примет заявку, если первый сотрудник занят или отсутствует.
Дубли нужно разбирать как управленческое решение
Автоматическое сопоставление помогает, но не отменяет правила. Согласуйте признаки, по которым систему можно попросить искать клиента: телефон, e-mail, идентификатор мессенджера, ИНН компании или номер заказа. Для разных бизнесов набор будет разным. Номер телефона подходит не всегда: им могут пользоваться несколько сотрудников компании или члены семьи.
В Битрикс24 автоматическое объединение дубликатов доступно для лидов, контактов и компаний, но срабатывает при совпадении всех значений полей, одном ответственном и одинаковой стадии лида. Если данные различаются, карточки нужно объединять вручную. Точные условия и тарифные ограничения перечислены в справке об объединении дубликатов.
Это ограничение полезно: оно не даёт автоматически склеить похожие обращения без проверки. Перед запуском подготовьте несколько тестов: известный клиент пишет с нового канала; клиент обращается по другому продукту; письмо пришло с общего корпоративного адреса; форма отправлена повторно из-за ошибки. Результат теста должен быть заранее определён: новая карточка, привязка к существующей или ручная проверка сотрудником.
Условный пример: как оценить цену потерянных заявок
Сначала не пытайтесь посчитать «эффект от CRM». Посчитайте разницу между входящими обращениями в первичных источниках и тем, что попало в учёт. Для этого в течение двух недель выгрузите или вручную отметьте отправки форм, новые письма общего ящика и обращения в корпоративных чатах. Затем сопоставьте их с карточками в CRM.
Формула для первичной оценки такая:
Неучтённые обращения × конверсия в продажу × средняя выручка со сделки = выручка под риском
Это условная модель, а не прогноз. Допустим, за две недели компания нашла 8 обращений, которых нет в CRM. Если подставить свою конверсию 15% и среднюю выручку 80 000 рублей, получится 96 000 рублей: 8 × 0,15 × 80 000. Расчёт показывает порядок риска, но не доказывает, что все восемь обращений стали бы продажами. Для решения о проекте сравнивайте его с маржой, стоимостью настройки и реальной частотой пропусков.
После запуска измеряйте одинаковые периоды. Полезны доля обращений, созданных автоматически, количество карточек без ответственного, время до первого действия и число заявок без следующего шага. Эти показатели не украшают отчёт, зато быстро показывают, где маршрут всё ещё рвётся.
Практический инструмент: тест маршрута одного обращения
Не подключайте все каналы за один день. Начните с того, где больше всего запросов или дороже цена пропуска. Проведите тестовую заявку до результата, исправьте найденные разрывы и только затем переходите к следующему источнику.
Проверьте маршрут по чек-листу:
- Обращение создаётся в точке учёта без ручного копирования.
- В карточке сохранён источник и содержание первого сообщения или письма.
- Система ищет существующего клиента по согласованным признакам.
- Назначается конкретный сотрудник или рабочая очередь.
- При недоступности основного менеджера обращение получает замену.
- У ответственного есть срок первого действия.
- После ответа указан следующий шаг и дата.
- Карточку нельзя закрыть без понятного результата.
- Руководитель может открыть исходное обращение и увидеть просрочку.
Проведите такой тест в трёх вариантах: новый клиент, известный клиент и обращение в отсутствие основного менеджера. Для сайта добавьте отправку с каждой формы, для почты - новое письмо и ответ на старую цепочку, для мессенджера - сообщение в рабочий канал. Пока хотя бы один сценарий не проходит, подключение нельзя считать завершённым.
Короткие ответы на частые вопросы
01Можно начать только с заявок с сайта?
Да, если сайт даёт заметную часть обращений. Настройте создание карточки, назначение ответственного, срок первого ответа и результат обработки. Затем проверьте все формы, а не только основную. Рабочая схема одного канала полезнее нескольких формально подключённых источников.
02Что делать, если клиенты пишут менеджерам в личные мессенджеры?
Сначала закрепите правило: либо менеджер переводит диалог в корпоративный канал, либо компания подключает и контролирует рабочий аккаунт. Нельзя требовать полноты учёта и одновременно разрешать вести клиентские переписки только в личном телефоне сотрудника. Технический коннектор не восстановит историю, к которой у компании нет доступа.
03Обязательно ли создавать отдельную сделку на каждое сообщение?
Нет. Решение зависит от вашей модели продаж. Сообщение известного клиента может быть продолжением открытой сделки, а короткий вопрос - поводом для задачи, а не для новой воронки. Сначала определите признаки новой заявки и проверьте их на повторных обращениях.
04Как понять, что после запуска ничего не теряется?
Сверяйте CRM с первичными источниками. Количество отправок форм, новых писем и обращений в рабочих чатах должно объясняться карточками, дублями или зафиксированными техническими исключениями. Зелёный статус интеграции не заменяет такую сверку.
05Небольшой компании нужна CRM?
Размер команды не решает вопрос. Когда один человек ведёт немного заявок и общая таблица показывает весь маршрут, можно не усложнять процесс. Если сотрудники подменяют друг друга, а обращения приходят из нескольких мест, CRM становится способом закрепить ответственность и историю общения.
Собрать заявки в одном месте можно без большого проекта. Начните с одного реального маршрута, назначьте владельца на каждом переходе и проверьте его тестовым обращением. Только после этого имеет смысл масштабировать интеграции и отчёты.
Неясно, где именно теряются заявки?
На аудите входящих обращений команда «Код в деле» проследит путь запроса от формы, письма или сообщения до результата. После разбора будет понятно, где достаточно договориться о порядке работы, а где нужна интеграция или настройка CRM.
Разобрать путь заявки
Запросить аудит