21 августа 2026 г. · Maksim Shchegolev

Аудит обработки заявок: почему теряются заявки в CRM

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

Хотите проверить это на своём сайте? Запустите бесплатную проверку видимости в ИИ, она занимает десять секунд и не требует почты.

Аудит обработки заявок это фиксированная диагностика, которая отвечает на один вопрос с доказательствами: между моментом, когда обращение пришло, и моментом, когда с ним реально начали работать, где исчезает объём и сколько его исчезает. Это не разбор конверсии и не мнение о воронке. Это сверка чисел по слоям на данных, которые у команды уже лежат.

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

Одним предложением

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

Что такое аудит обработки заявок и чем он не является

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

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

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

Почему отчёты веб-аналитики не видят большую часть потерь

Потому что веб-аналитика заканчивается на входе. Справка Google Analytics об источниках переходов описывает, как визит привязывается к источнику и кампании: это ровно то, что нужно для оценки привлечения, и ровно то, что бесполезно для оценки обработки. То же самое верно для Яндекс Метрики. Аналитика скажет, что форма отправлена. Она не скажет, создалась ли запись, есть ли у неё ответственный и позвонил ли кто-нибудь.

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

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

Задержка ответа это видимая верхушка. Сколько её бывает, показала работа Harvard Business Review 2011 года: 2 241 американская компания, медиана первого ответа 42 часа у тех, кто ответил. Цифра старая и про одну выборку, так что это описание неуправляемого потока, а не современный ориентир. Механика с тех пор не изменилась: ничто в карточке не обязывало человека ответить, и ни один отчёт не показывал, что он не ответил.

Какие данные собрать и за какой период

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

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

Выбор периода. Берите один закрытый период, а не скользящее окно, и выравнивайте его по целым рабочим неделям, чтобы выходные обращения не разрезались границей. Период должен быть достаточно длинным, чтобы внутри него успел завершиться ваш цикл дожима: если цепочка касаний идёт четырнадцать дней, записи прошлой недели ещё в работе и выглядят брошенными, не будучи брошенными. Он также должен пережить один отпуск и один всплеск рекламы, потому что отдельная неделя это в основном шум. Рабочий стартовый шаблон: полный квартал для четырёх счётчиков и один недавний полный месяц для подробного разбора по слоям. Подгоняйте под длину своего цикла, а не копируйте.

Исключения это задокументированное число, а не уборка. Тестовые отправки, очевидный спам, внутренний трафик и известные партнёры из выборки убираются, и каждое такое удаление фиксируется числом и правилом. Фраза «мусор мы убрали» это точка, в которой аудит перестаёт быть воспроизводимым, а размер категории «мусор» сам по себе часто оказывается находкой.

Сверка четырёх счётчиков, которая ловит потери без хозяина

Этот шаг почти никто не делает, и именно он ловит утечки, которые не приписаны ни одному слою. Четыре числа, один период, одинаковый набор каналов в каждом.

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

Б. Создано. Записи, которые существуют в CRM за тот же период и по тем же каналам.

В. С ответственным. Из Б те записи, у которых есть названный ответственный менеджер, активный в системе и не отсутствовавший всё окно целиком.

Г. В работе. Из В те записи, по которым есть хотя бы одна зафиксированная исходящая попытка внутри окна, заданного вашим регламентом.

Счётчик А самый трудный, и его трудность сама по себе диагностична. Если ответ на вопрос «сколько обращений пришло в прошлом месяце» собирается два дня из пяти выгрузок, вы уже нашли проблему слоя отчётности, ещё не посмотрев ни одной записи. У команд с работающим Lead Hub, то есть единым узлом, через который проходят все заявки, счётчик А получается сам собой, и это, по сути, главный аргумент за такой узел.

Два подводных камня испортят сверку, если их не убрать. Первый: решите, вы считаете события или людей, запишите это и держите одинаково во всех четырёх числах. Один покупатель, который позвонил, потом заполнил форму, потом написал в Telegram, это три события и один человек, а смешение двух подходов даёт разрывы, которые выглядят утечкой, а являются арифметикой. Если можете, показывайте оба числа: события измеряют нагрузку, люди измеряют рынок. Второй: склейка дублей законно уменьшает Б относительно А, поэтому её нужно посчитать отдельно, а не записать в потери. Журнал слияний с числами превращает необъяснённый разрыв в объяснённый.

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

Как устроена послойная диагностика

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

Приём и идентификация: заявка вообще стала записью?

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

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

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

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

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

Квалификация и назначение: кто-нибудь стал ответственным?

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

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

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

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

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

Ответ и дожим: работа действительно была?

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

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

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

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

Отчётность и атрибуция: это вообще кому-то видно?

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

Самая чистая проверка занимает час. Возьмите одно число, которое руководство видит каждую неделю, и пересчитайте его из сырых выгрузок, не заглядывая в сводку. Если результаты разошлись, разберитесь с этим до обсуждения всего остального. Обычные причины: забытый фильтр, не то поле даты, записи, отрезанные фильтром по ответственному, или два определения одного слова в двух системах.

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

Это утечка или нехватка мощности?

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

Последняя строка это надёжный разделитель. Численность людей никак не влияет на то, становится ли пришедшее обращение записью, поэтому любой разрыв между А и Б это утечка по определению, независимо от того, насколько команда загружена. Проводите сверку до того, как кто-нибудь произнесёт слово «не хватает рук».

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

Как ранжировать находки по стоимости, а не по лёгкости

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

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

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

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

Как выглядит результат аудита

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

Заполненная строка читается так, и цифры здесь условные, показывающие форму записи, а не чей-то реальный результат: Н3, слой приёма. Обращения с партнёрского портала не создают записи в дни, когда ночной обмен падает. Доказательство: выгрузка портала, соединённая с датами создания в CRM по дням, период с апреля по июнь, запрос лежит в папке аудита. Затронуто: сумма дневных разрывов за период, в событиях. Возвратность: частично, контакты остались в портале. Ответственный: названный по имени инженер. Гайд-владелец: приём заявок на сайте. Статус: открыто.

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

Заметка оператора. Разослать таблицу находок без разбора это надёжный способ похоронить аудит. Первая реакция на крупную находку в слое приёма это недоверие, а недоверие, направленное на числа вместо процесса, хоронит весь отчёт целиком. Показывайте по порядку: счётчик А, счётчик Б и то соединение, которое дало разрыв, и дайте людям повторить это самим. Находка, которую кто-то воспроизвёл, это находка, которую кто-то починит.

Когда диагноз это не утечка

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

Самая быстрая одиночная проверка это распределение причин отказа. Если лидирует «не отвечает» или «не дозвонились», диагноз в обработке и этот гайд применим. Если лидируют цена, сроки или несовпадение профиля, скорость ответа не поможет, а перестройка правил распределения превратится в дорогой спектакль. Работает эта проверка только на справочнике причин: причины отказа свободным текстом не говорят ничего, и это отдельная находка для автоматизации обработки заявок в CRM.

Как превратить аудит в регулярную ревизию

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

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

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

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

Что чинить первым и где лежит каждое исправление

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

1. Приборы. Время приёма в карточке, своё значение источника у каждого канала, очередь сбоев, которую кто-то читает, и записанные правила распределения и ответа.
2. Приём. Закрыть разрыв между А и Б по каналам, начиная с самого крупного. Владелец: приём заявок на сайте.
3. Идентификация. Искать дубли до назначения, чтобы владение и история перестали разъезжаться. Владелец: автоматизация обработки заявок в CRM.
4. Владение. Довести число записей без ответственного до нуля и добавить резервную ветку к каждому правилу. Владелец: плейбук по распределению заявок.
5. Ответ. Запустить таймер от приёма и работать с хвостом распределения, а не с медианой. Владелец: скорость ответа на заявку.
6. Дожим. Убрать подвешенные записи: у каждой либо открытая задача, либо закрывающий этап. Владелец: система дожима заявок.
7. Отчётность. Вывести четыре счётчика в постоянный отчёт, чтобы следующий аудит стал чтением. Владелец: отчётность по входящим заявкам.
8. Повторный замер. Прогнать каждый запрос из закрытых находок на более позднем периоде и записать новое число.

Если проваливаются сразу несколько слоёв, вопрос уже не в последовательности починок, а в архитектуре, и границу здесь помогает провести гайд Lead Hub или CRM. Карта всех модулей лежит в гайде про операционный стек для входящих заявок, интерактивная версия того же потока на главной странице OperStack, а варианты объёма работ на странице тарифов.

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

Цены