Нам важно увеличить конверсии. Представьте: на разборе недели РОП делит число оплат на число новых заявок за ту же неделю. Обращений стало больше, оплат — столько же. Процент упал. Собственник собирается отключить источник, который привёл лишнюю работу вместо денег.
Я бы сначала попросил открыть любую оплату из этого расчёта. Когда покупатель впервые обратился? Если до начала недели, он попал в число продаж, но в число заявок, с которым эти продажи сравнили, не попал. А вчерашнее обращение уже ухудшило показатель, хотя клиент ещё согласовывает состав заказа.
В таком отчёте встречаются разные покупатели. По нему уже собираются принять одно решение.
Оплативший клиент пришёл раньше тех, кого сейчас оценивают
Продолжим условную ситуацию. Клиент, оплативший сегодня, начал разговор раньше: прислал требования, получил расчёт, согласовал условия. Новый клиент пока только передал данные для расчёта. Отдел должен провести его через оставшиеся шаги. Сделать это задним числом, чтобы он успел в отчётную неделю, невозможно.
Календарный отчёт сам по себе нужен. Собственнику надо видеть, сколько обращений пришло, сколько заказов оплачено и хватит ли денег на расходы. Ошибка появляется в момент, когда отношение этих двух чисел называют долей заявок, дошедших до оплаты. Для такого вывода нужно проследить путь одних и тех же обращений.
У ошибки есть неприятная обратная сторона. Если новых заявок станет меньше, а старые сделки продолжат оплачиваться, этот же процент вырастет. Отчёт покажет улучшение ровно тогда, когда отдел начинает терять будущую работу.
Поэтому сначала стоит восстановить связь: из какого обращения получилась каждая оплата. Если её нельзя показать, новая диаграмма конверсии пока ничего не исправит. Нужно связать заказ с исходной заявкой, сохранив дату первого обращения. Вопрос о качестве источника остаётся открытым.
Дайте разным заявкам одинаковое время
Чтобы проверить источник, РОП выбирает сопоставимые обращения: один продукт, один тип покупателя, первая покупка. Повторный заказ постоянного клиента лучше разобрать отдельно: он может пройти путь, который новому покупателю ещё только предстоит.

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

Ждать окончательной доли оплат иногда действительно приходится. Ждать обещанного расчёта, который менеджер уже просрочил, — незачем.
В той же условной группе один покупатель согласовал дату обсуждения условий, и она ещё не наступила. Другому продавец должен был отправить расчёт, но не отправил. Третий прямо отказался, потому что компания не может выполнить нужное условие. Оплаты нет у всех. Работы для РОПа — разные.
- Согласованная дата ещё впереди — сохранить основание ожидания и вернуться в назначенный день. Завтрашний планёрочный отчёт не делает клиента просроченным.
- Обещание отдела уже нарушено — восстановить исполнение сейчас, выяснить причину задержки и проверить следующий такой расчёт. Ссылка на длинный цикл здесь не отвечает на вопрос.
- Есть подтверждённый отказ — записать конкретное условие, на котором остановились, и проверить, повторяется ли оно в похожих обращениях. Ещё один месяц ожидания этот отказ не изменит.
Так руководитель отделяет срок решения покупателя от задержки своей команды. Для этого не нужно дожидаться итоговой конверсии. Нужны договорённость, её дата и след выполненного действия.
Сократить заявки — способ быстро улучшить неверную цифру
Вернёмся к решению отключить источник. Если уменьшить входящий поток, а оплаты старых заказов пока сохранятся, отношение оплат к новым заявкам станет выше. Собственник получит подтверждение собственной правоты из того же расчёта, который подтолкнул его к ошибке.

Но новая работа у менеджеров уже исчезла. Когда закончатся старые сделки, это станет видно и по оплатам.
Из этого не следует, что любой источник надо продолжать финансировать. Заявки могут действительно не подходить, отдел может не справляться с обработкой, а у бизнеса может не быть денег на дальнейшую проверку. Только решение в каждом случае опирается на свой факт.
Если в сопоставимых обращениях повторяется подтверждённая причина отказа, РОП приносит маркетингу конкретные запросы и ограничения. Если новая нагрузка привела к пропуску обещанных сроков, сначала определяет, какую работу команда успевает выполнить и где нужна помощь. Если заканчивается допустимый бюджет, собственник может остановить проверку, даже не получив полного ответа о качестве источника.
Последнее — нормальное решение. Компания не обязана покупать окончательную ясность любой ценой. Но в записи о результате должно остаться: проверку остановили по деньгам, будущие исходы пока неизвестны. Иначе следующему руководителю передадут неподтверждённый вывод, что этот источник не работает.
На следующий разбор принесите тот же список
Первый шаг можно сделать на ближайшем разборе с РОПом: взять источник, который хотят сократить из-за конверсии, и попросить показать, какие именно заявки стоят за числом оплат. Если это разные периоды прихода, решение по одному проценту откладывается до проверки состава расчёта.
До следующего недельного разбора РОП собирает по выбранной группе дату обращения, действия клиента, обещанные шаги отдела, оплаты и отказы. Заранее называет, что собирается выяснить за этот срок. Например, выясняет ли менеджер задачу и передаёт ли расчёт к обещанной дате. Покупка может потребовать больше времени; выполненное обещание отдела видно уже сейчас.
На следующую встречу приходит тот же список с новыми событиями. Появившиеся позднее заявки идут отдельно. По каждой прежней видно, что изменилось за неделю, а по обнаруженной задержке — какое действие назначил РОП и выполнено ли оно. Это мешает незаметно заменить неудобную группу более удачной и назвать замену улучшением.
Для сравнения с прошлым руководитель восстанавливает те же события на таком же сроке жизни прежних обращений. Если истории нет или обращений слишком мало, он не объявляет источник лучше либо хуже. Показывает отдельные наблюдения и говорит, какого факта пока не хватает.
Дату следующего решения по источнику назначают с учётом реального пути покупки и доступных денег. За основу берут историю похожих обращений, включая отказы и незавершённые сделки, а не только быстрые успешные продажи. На назначенную дату смотрят весь исходный список: сколько дошло до оплаты, сколько отказалось, что осталось открытым и на каком подтверждённом основании. Менять эту дату можно с объяснением, какое событие ещё ждут и сколько стоит ждать дальше.
У собственника остаётся решение о бюджете и допустимом сроке проверки. У РОПа — работа со сделками внутри этого срока. Просьба потерпеть должна сопровождаться событиями в тех же заявках, а не свежей датой в презентации.
В RENTROP «Управление продажами под ключ» включает именно такую ежедневную работу: РОП проверяет путь обращений, возвращает менеджеров к обещанным действиям и передаёт маркетингу подтверждённые причины потерь. Директор по развитию проверяет решения самого РОПа: на каких сделках они основаны и что изменилось после вмешательства. При смене руководителя исходный список, события и причины решений остаются в компании — повторять проверку вслепую не приходится. Рекламный бюджет за собственника мы не выбираем.
У новой заявки ещё может не быть оплаты. У решения отключить источник уже должно быть основание.