Максим Карабовский
Маркетинг

Почему ваш отчёт Salebot → amoCRM врёт: 6 ловушек в данных, которые съедают доверие руководителя

Разбор без магии — какие ошибки в данных ломают отчёт и как их отловить до того, как цифры увидит руководитель.

Коротко

  • Ручная сверка чат-бота и CRM занимала около часа в день, теперь — несколько минут.
  • В данных нашлось шесть ловушек: перезапись дат, «вечные» метки, сотрудники, дубли эфиров, теги вместо сделок, пустое поле продукта.
  • Сверка идёт по уровням надёжности: Telegram ID, затем телефон и email, затем имя и время.
  • Главная польза — не скорость, а цифры, которым верит руководитель и с которыми не спорят продажи

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

На бумаге это пять минут. На практике — около часа: сверить людей по двум системам, отсеять мусор, понять, почему в CRM 41 сделка, а реальных продуктовых ноль. Пять часов в неделю на то, чтобы просто узнать, что произошло вчера.

На этом примере видно, почему даже опытный глаз не может найти совпадения
На этом примере видно, почему даже опытный глаз не может найти совпадения

В этой статье — как я перевёл этот отчёт на автоматическую сборку и, главное, какие ловушки в данных пришлось найти по дороге. Если у вас заявки идут через чат-бота в CRM, почти все они есть и у вас

Где теряются заявки между ботом и CRM

Схема типичная. Человек пишет в чат-бота в Telegram или Max. Бот собирает контакт, вешает теги интереса и в какой-то момент ставит метку «Контакт передан в АМО». В amoCRM создаётся сделка, её подхватывает менеджер.

В этой цепочке три точки, где отчёт начинает врать:

  1. Обращение есть, передачи нет. Человек написал, но до передачи в CRM не дошёл. Это нормальная воронка, но её надо видеть.
  2. Передача есть, сделки нет. Бот отметил передачу, а сделки в CRM не нашлось. Это и есть потерянный лид — или ложная тревога, о чём ниже.
  3. Сделка есть, но она не про продукт. Регистрации на эфир, дубли, тесты, пропущенные звонки без имени. В CRM это выглядит как поток лидов, а продажам работать не с чем.
путь лида от бота до сделки · 3 разрыва
путь лида от бота до сделки · 3 разрыва

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

Шесть ловушек, на которые я наступил

  1. Дата последнего контакта перезаписывается
    В выгрузке Salebot есть поле «Дата последнего контакта». Кажется логичным резать по нему срез за день. Но поле обновляется при каждом новом сообщении: если человек написал во вторник и снова в четверг, во вторнике его уже нет.

    Вывод: срез за день делается по свежей выгрузке в тот же или на следующий день. Восстановить прошлую неделю задним числом нельзя — максимум новых клиентов по «Дате первого контакта». Строки, посчитанные вовремя, я больше не переписываю: они точнее.
  2. Метка «передан в CRM» остаётся навсегда
    Клиента передали в CRM месяц назад, сегодня он вернулся в бота с вопросом. Метка на нём висит, и в дневной цифре он считается как новая передача. Лид учитывается дважды, конверсия плывёт.

    Решение: считать передачей дня только метки, появившиеся в этот день. Возвраты — отдельно.
  3. Сотрудники выглядят как потерянные лиды
    Коллеги тестируют бота, проходят воронку, получают метку передачи. Их сделки в CRM потом удаляют. В отчёте это превращается в «передан, сделки нет» — то есть в потерю, которой не было.

    Решение: список сотрудников, которых скрипт исключает из статистики всегда. Мелочь, но без неё каждую неделю приходилось объяснять руководителю, почему «потеряли» лида, который сидит в соседнем кабинете.
  4. Эфирный бот плодит дубли
    В дни вебинаров бот регистрации создаёт по две сделки на человека с разницей в одну-две секунды, плюс пустые сделки без контакта. В один такой день в CRM было 41 сделка, из них 37 эфирных, уникальных людей среди них — около 21. Продуктовых — ноль.

    Если не отделять шум, цифра «сделок в CRM» в эфирные дни вырастает втрое, и динамику по неделям сравнивать невозможно. Теперь в отчёте всегда две цифры: «37 сделок, уникальных ~21», а уникальность считается по Telegram ID.
  5. Тег в боте — это интерес, а не сделка
    Бот вешает продуктовые теги по тому, что человек нажал или прочитал. Соблазнительно считать по ним спрос. Но тег — это интерес, сделкой он становится только в CRM. В продуктовые колонки отчёта идут только сделки по полю интереса в CRM.

    При этом разрыв сам по себе — ценный вывод. «7 меток интереса к направлению в боте против 0 сделок» — это сигнал, что люди интересуются, а до менеджера не доходят.
  6. Менеджеры не проставляют тег продукта
    Сделка заведена, менеджер с клиентом работает, а поле продукта пустое. В отчёте по направлениям её нет. Я не выбрасываю такие сделки: беру Telegram ID из CRM, нахожу человека в боте и смотрю его теги. Если там явный продуктовый интерес — сделка уходит в список «уточнить» с пометкой источника.

    Важно: если тег в боте расходится с тем, что вписал менеджер, ничего не перезаписывается. Расхождение помечается для проверки — менеджер знает клиента лучше.

Как устроен отчёт сейчас

От логики на бумаге к Python-скрипту за вечер

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

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

Теперь утром я загружаю две выгрузки и получаю готовый результат. Цикл из четырёх шагов:

  1. Срез бота за день. Скрипт считает обращения, разбивку по мессенджерам, новых клиентов и новые передачи в CRM, отделяет возвраты и исключает сотрудников.
  2. Разбор CRM. Сделки по воронкам и стадиям, отдельно продуктовые, отдельно шум. Дубли схлопываются по Telegram ID. Формат выгрузки amoCRM бывает с английскими и с русскими заголовками — скрипт понимает оба.
  3. Сверка бота и CRM. Каждый переданный лид ищется в сделках.
  4. Итог. Короткий пост для руководителя в Telegram и строка в сводной таблице.

Сверка в третьем шаге идёт по уровням надёжности, и это главное, чему я научился:

  • Подтверждено по ID — Telegram ID в сделке совпал с ID в боте. Это факт.
  • Вероятное совпадение — совпали имя и время: передача и сделка в один день, сделка позже. Так и пишется в отчёте, с предложением уточнить у менеджера.
  • Сделки нет — только после проверки, что это не сотрудник, сделка не создана в другой день и не закрыта сразу как дубль. Только тогда это потеря.

Как именно ищется совпадение

В комментариях к таким статьям всегда спрашивают: а если в CRM телефон +7916…, а в боте 8916…? Именно поэтому сравнивать «как есть» нельзя. Перед сверкой каждый идентификатор приводится к одному виду:

  • Telegram ID — самый надёжный ключ. Нюанс: в выгрузках он часто читается как дробное число (468970848.0), хвост приходится отрезать, иначе совпадений не будет вовсе.
  • Телефон — из номера убирается всё, кроме цифр, а российские номера с ведущей 8 переводятся на 7. Без этого 89161234567 и +7 916 123-45-67 считаются разными людьми.
  • Email — в нижний регистр, без пробелов. Значения без @ отбрасываются: в полях попадаются заглушки вроде «нет».
  • Имя и время — последний уровень, только как «вероятное совпадение», никогда как факт.

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

Про персональные данные: для сверки мы используем Telegram ID как технический ключ. Сами выгрузки хранятся на корпоративном портале. По 152-ФЗ Telegram ID в связке с ФИО и телефоном является персональными данными, поэтому доступ к итоговой таблице строго ограничен

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

Ещё одна деталь, которая окупилась: в сводной таблице у каждой неочевидной цифры есть примечание с раскладкой. Например: «41 сделка = 37 эфирных (уникальных ~21) + …». Через месяц никто не вспомнит, почему в колонке «сделок» стоит 41, а продуктовых ноль.

Теперь руководитель видит не просто цифру “41”, а её структуру
Теперь руководитель видит не просто цифру “41”, а её структуру

Что это дало

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

Главное — изменилось качество цифр. Руководитель видит не «41 сделка», а «0 продуктовых, остальное — эфир». Видит, сколько людей интересуется направлением в боте и не доходит до менеджера. Видит конкретных переданных лидов без сделки — и можно спросить с ответственного, а не гадать.

Три вывода, которые подойдут любой связке бота и CRM:

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

Вопрос к вам. У меня связка Salebot + amoCRM. Если у вас другая — BotHelp и Битрикс24, Senler и RetailCRM, напишите в комментариях, где у вас главная боль со сверкой. Самые частые случаи разберу в следующей статье. А готовые шаблоны, куски кода и идеи для маркетологов я выкладываю в своем Telegram-канале.