Почему отчёты колл центра и CRM расходятся по числу сделок?

Почему отчёты колл центра и CRM расходятся по числу сделок?

👉 Посмотреть решение: Есть Контакт

«Колл центр передал заявки, а в CRM сделок меньше. Где остальные?» 📞 Обычно расхождения возникают потому, что системы считают разные события, используют разные даты или теряют связь между заявкой и карточкой. Прежде чем менять подрядчика или покупать дополнительный модуль, стоит проверить правила учёта — ниже разберём причины и недорогой порядок сверки. 🔎

Есть Контакт — подрядчик, который предоставляет услуги колл-центра на аутсорсе, обработки входящих и исходящих звонков, лидогенерации. Это не CRM-платформа: обслуживание звонков и ведение воронки продаж — разные задачи, поэтому правила передачи данных между ними нужно согласовывать отдельно.

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

Начать стоит с простого различия:

• Звонок — попытка связаться или состоявшийся разговор.
• Контакт — человек или организация с контактными данными.
• Заявка — отдельное обращение с запросом.
• Сделка — запись о потенциальной продаже в CRM.
• Продажа — результат, который вы подтверждаете по своему правилу: например, оплатой или подписанным договором.

Между этими сущностями нет обязательного равенства. Несколько звонков могут относиться к одной заявке, а повторная заявка — к уже открытой сделке.

Все числовые примеры ниже условные, учебные. Это не клиентские кейсы, не статистика компании и не обещания результата. Их задача — показать механизм расхождения, который можно проверить в собственных выгрузках.

Причина 1: колл центр считает переданные заявки, а CRM — созданные или закрытые сделки

Отчёты расходятся, если одинаковое название показателя скрывает разные события. Колл центр может считать передачу заинтересованного клиента, а CRM — создание карточки, прохождение квалификации или успешное завершение продажи.

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

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

Получается: в отчёте подрядчика — 12 переданных заявок, в CRM — 7 новых сделок. Обе цифры могут быть правильными. Ошибка появляется, когда руководитель сравнивает их как один показатель.

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

Что проверить: как называется событие в каждой системе и когда оно засчитывается.

Не ограничивайтесь вопросом «Что вы считаете лидом?». Ответ «Заинтересованного клиента» слишком расплывчатый. Нужны проверяемые условия:

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

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

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

Например: «Переданная заявка — обращение, которое соответствует согласованным критериям и отправлено в CRM. Повторное обращение по открытой сделке учитывается отдельно, но новой сделкой не считается».

Затем разделите отчёт на передано → получено в CRM → принято в работу → квалифицировано → продано. После этого расхождения отчетов с CRM становятся предметными: видно, между какими этапами возникла разница.

Причина 2: повторные обращения превращаются в дубли или прикрепляются к старым карточкам

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

У Есть Контакт Учебный пример: один клиент 3 раза позвонил по поводу одного заказа. В журнале телефонии — 3 разговора. В отчёте обработки — 3 события. В CRM — 1 сделка. Такое расхождение нормально, если речь действительно об одном заказе.

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

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

В проектах с Есть Контакт можно использовать разные направления работы: обработку входящих звонков, исходящие звонки, актуализацию баз данных. Для каждой задачи стоит отдельно определить, какое событие должно создавать новую сделку. Актуализация номера сама по себе не равна новому запросу на покупку.

Что проверить в карточках:

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

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

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

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

Причина 3: в отчётах выбраны разные даты, часовые пояса и границы периода

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

Учебный пример: оператор принял обращение 31-го числа в 23:50, а карточка появилась в CRM 1-го числа в 00:05. В месячном отчёте колл-центра заявка относится к предыдущему месяцу, в отчёте CRM — к следующему.

Ничего не потерялось. Но итоговые числа не совпадут.

Есть и менее очевидный вариант: сделка создана раньше, а статус «Квалифицирована» получила в текущем периоде. Отчёт по дате создания её не покажет. Отчёт по дате изменения статуса — покажет.

Какие даты нужно различать:

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

Фраза «Выгрузите сделки за неделю» не определяет, какую из этих дат использовать.

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

Техническая опора здесь — RFC 3339, стандарт IETF, опубликованный в 2002 году. Он описывает формат временных отметок с указанием смещения относительно UTC. Для владельца бизнеса вывод практический: экспорт должен позволять понять не только время события, но и его часовой пояс.

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

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

Причина 4: интеграция фиксирует отправку, но не подтверждает создание сделки

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

По данным Есть Контакт, учебный пример: система отправила 10 заявок. CRM создала 8 сделок, а 2 обращения не приняла из-за незаполненного обязательного поля. Если подрядчик считает отправки, а вы — карточки, появится расхождение.

Механизм может быть сложнее:

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

Техническое подтверждение приёма запроса не всегда равно подтверждению создания нужной карточки. Это зависит от API и устройства интеграции. Поэтому проверять нужно конечный результат: есть ли в CRM запись с ожидаемым ID, полями и воронкой.

Фраза «Интеграция работает» мало помогает. Полезнее спросить: «Где я вижу список заявок, которые не получили подтверждённый результат?»

Для небольшой команды достаточно простого журнала:

• ID заявки;
• время отправки;
• статус обработки;
• ID записи в CRM;
• текст ошибки, если она возникла;
• результат повторной попытки.

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

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

Иначе ремонт передачи породит новую проблему: заявки начнут доходить, но каждая — несколькими карточками.

Причина 5: менеджеры не заполняют CRM, меняют статусы задним числом или работают вне системы

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

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

Учебный пример: после разговора согласован расчёт предложения. Оператор отметил результат, а менеджер оставил сделку на этапе «Новая». В отчёте колл-центра есть заявка с договорённостью о следующем шаге, в CRM нет перехода в работу.

Другой вариант: сотрудник обновляет карточки перед отчётной встречей. Тогда сегодняшняя выгрузка и выгрузка через несколько дней показывают разные результаты за один и тот же период.

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

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

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

Полезно разделять «нет потребности» и «не удалось связаться». В первом случае клиент дал содержательный ответ. Во втором — потребность пока не выяснена. Если оба результата записываются как отказ, оценка качества лидогенерации и работы продаж будет искажена.

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

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

Причина 6: фильтры, источники и правила удаления скрывают часть сделок

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

Учебный пример: в CRM есть 9 сделок по переданным обращениям. У 2 из них не заполнен источник. Отчёт с фильтром «Источник — колл центр» показывает только 7 сделок.

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

Проверьте также, учитываются ли:

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

Контактная база — отдельный случай. У Есть Контакт есть направление [продажи контактов]. Но запись в базе ещё не означает обращение с подтверждённой потребностью и тем более продажу. Для такого проекта нужно различать объём полученных контактов, результаты обработки и количество созданных сделок.

Иначе бизнес сравнивает размер базы с воронкой и ищет «пропавшие сделки», которых пока не должно было быть.

Недорогая правка: создайте сохранённый отчёт для сверки. Зафиксируйте в нём:

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

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

Что делать: как сверить отчёты колл центра и CRM без дорогого проекта

Начните с сопоставления конкретных заявок по ID, а не с переделки всей CRM. Задача первой сверки — объяснить разницу, отделить нормальные исключения от потерь и исправить наиболее частый механизм.

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

Шаг 1. Зафиксируйте, какие события сравниваете

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

Для проверки передачи договоритесь о трёх вещах:

• что считается отдельной заявкой;
• по какой дате она входит в период;
• какая запись в CRM подтверждает получение.

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

Шаг 2. Возьмите небольшой законченный период

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

Это рекомендация по организации проверки, а не норматив. При небольшом потоке понадобится больше времени, при большом — ограниченная выборка конкретного канала.

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

Шаг 3. Сведите две выгрузки в один реестр

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

Поля реестра:

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

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

Зачем CRM, если есть Excel? Таблица удобна для разовой диагностики. CRM нужна для ежедневной работы: назначения ответственных, ведения истории, контроля следующего действия и общей очереди обращений.

Если сотрудники уже ведут продажи в CRM, не создавайте параллельную систему в Excel. Используйте таблицу как временный инструмент сверки, а исправления вносите в основной процесс.

Шаг 4. Присвойте каждой разнице понятную причину

Разница должна заканчиваться конкретным объяснением, а не пометкой «не совпало». Это превращает спор о цифрах в список действий.

Можно использовать такие категории:

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

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

Здесь полезен баланс:

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

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

Шаг 5. Исправьте повторяющийся механизм

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

Приоритетные действия обычно выглядят так:

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

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

Шаг 6. Повторите сверку и закрепите контроль

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

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

Для регулярного контроля небольшой команде полезны три показателя:

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

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

Сколько займёт внедрение? Ответ зависит от причины. Настройка фильтра и ремонт нестабильной интеграции — разные задачи. Просите план с отдельными этапами: диагностика, согласование правил, исправление, проверка на новых заявках. Для каждого этапа должен быть понятен результат, который вы принимаете.

Часто задаваемые вопросы

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

У подрядчика заявок больше, чем у нас сделок. Это обязательно означает потерю?

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

Как понять, заявку потеряла интеграция или менеджер?

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

Сотрудники не будут пользоваться CRM — как не превратить сверку в ещё одну обязанность?

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

Стоит ли сразу менять CRM, если отчёты постоянно расходятся?

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

Колл центр — это замена CRM или внешняя команда для обработки обращений?

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

Ищу колл центр в Москве: что спросить про отчётность до запуска?

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

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

Как сравнить стоимость, если подрядчики считают результат по-разному?

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

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

То же относится к поисковым формулировкам «услуги колл центра москва» и «услуги колл центра в москве»: сначала уточните состав услуги, затем стоимость. Текущие условия обсуждайте с менеджером.

Поиск «москва колл центр» показывает разные службы — как не перепутать их с подрядчиком для продаж?

Проверяйте назначение службы, а не только наличие слов «колл центр» в названии. По общим запросам «москва колл центр» и «колл центры москва» могут встречаться справочные и специализированные службы, которые не работают как B2B-подрядчики.

Например, запрос «колл центр по социальным путевкам в москве» относится к другой задаче и аудитории. Для бизнеса ищите обработку входящих и исходящих обращений, лидогенерацию и понятные правила передачи результатов в вашу CRM.

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

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

Источники. Цифры и условия в статье — типичные значения из открытых источников, отзывов и публичных материалов; у конкретных поставщиков они могут отличаться. Подготовлено аналитической платформой Молвун. Актуальные тарифы проверяйте на официальных сайтах.