Обычный разговор: сайт работает, реклама крутится, менеджеры на месте — обращения приходят, но до CRM и следующего шага доезжают не все. При этом каждый участок по отдельности может выглядеть исправным.
Так и есть. Проблема может находиться не внутри одной системы, а на передаче от одной к другой. Заявка не доезжает между участками — на переходе от рекламы к сайту, от сайта к мессенджеру, от мессенджера к человеку, от человека к CRM. У одного участка есть хозяин, у другого тоже. А за саму передачу между ними иногда не отвечает никто.
Поэтому вопрос «где теряются заявки» полезнее решать не списком мест, а маршрутом: проследить путь одного обращения от объявления до сделки и посмотреть, где он прерывается.
Почему список мест не отвечает на вопрос, где теряются заявки
Списки «10 причин потери заявок» устроены так, будто поломка сидит в одной точке: плохая форма, медленный ответ, ленивый менеджер. Иногда так и есть.
Но если каждая система по отдельности исправна — сайт открывается, бот отвечает, CRM работает, — искать надо не сломанную деталь, а место, где одна деталь передаёт другой. Причём передача может держаться на ручном действии человека: кто-то должен заметить, скопировать, перенести, напомнить. Чем больше обращений и ручных передач, тем выше цена ошибки: одно сообщение проще не заметить, перенос — отложить, повторное касание — забыть.
Ниже — пять таких переходов. Не все они есть у каждого бизнеса: у кого-то нет рекламы, у кого-то нет CRM. Смысл не в том, чтобы найти у себя все пять, а в том, чтобы понять, какие из них у вас вообще есть.
Весь маршрут целиком выглядит так:
Источник → канал → единый вход → ответственный → CRM → следующий шаг
А стык — это стрелка между двумя соседними шагами. У каждой свой вопрос:
| Переход | Вопрос |
|---|---|
| Источник → канал | откуда пришло? |
| Канал → единый вход | куда доставилось? |
| Единый вход → ответственный | кто взял? |
| Ответственный → CRM | записалось ли? |
| CRM → следующий шаг | что дальше? |
Стык 1. Реклама → сайт
Человек нажал на объявление и попал на страницу. Обращение может не состояться уже здесь, и причины лежат до формы: обещание в объявлении не совпало с тем, что на странице, номер в объявлении отличается от номера на сайте, посадочная — общая главная вместо страницы про нужную услугу.
Есть и вторая потеря, тихая: связь между обращением и источником. Заявка пришла, а из какой кампании — неизвестно. Это не теряет клиента, но теряет возможность понять, какая реклама работает, — и через месяц бюджет распределяется наугад.
Что происходит с человеком после клика и до отправки формы — отдельная тема, я разбирал её по шагам в двенадцати точках потери на сайте. Здесь важно другое: этот стык заканчивается там, где человек решил написать.
Стык 2. Сайт → канал связи
Человек решил обратиться — и вот тут маршрут раздваивается. Часть людей заполняет форму. Часть находит в подвале мессенджер и пишет туда. Часть звонит.
Форму обычно проще всего направить в заранее заданный маршрут: вы сами определяете, куда уйдут данные после отправки. Для мессенджеров и звонков маршрут приходится организовывать отдельно — обращение приходит туда, куда человеку было удобнее написать: в личный аккаунт сотрудника, в общий чат компании, на почту, которую смотрят раз в день.
Отсюда простой признак: если у вас есть каналы, которые не сводятся в одно место, значит часть обращений живёт только там, куда пришла. Такое обращение существует только в исходном канале — пока его не перенесли в общее место, остальная система о нём просто не знает.
Стык 3. Канал → человек
Обращение пришло. Дальше кто-то должен взять его в работу — и здесь ломается не техника, а распределение ответственности.
Первый случай — общий чат и вопрос «кто возьмёт?». Если сообщение видят несколько человек, но конкретный ответственный не назначается, каждый может ожидать, что его возьмёт кто-то другой.
Второй случай мягче и потому незаметнее: ответственный есть, но он один и сейчас занят. Обращение не потеряно, оно ждёт — и никакого сигнала о том, что оно ждёт слишком долго, ни у кого не появляется.
Про то, как измерить эту задержку по своим данным и что делать с обращениями вне рабочего времени, у меня есть отдельный разбор с методикой подсчёта. Здесь мы смотрим не на скорость, а на то, доехало ли обращение до конкретного человека вообще.
Стык 4. Человек → CRM
Если CRM не связана с каналами автоматически, между ними появляется ручной перенос: кто-то копирует контакт, заводит сделку, проставляет поля.
При ручном переносе появляется два риска. Первый — запись откладывают: сначала отвечают клиенту, а CRM заполняют позже, и второе действие случается не всегда. Второй — часть обращений может вообще не попасть в систему, например если сотрудник решил, что это ещё не полноценная заявка. Тогда воронка, построенная по CRM, описывает не весь поток, а ту его часть, которая в неё попала.
Проверить это можно грубо, но быстро: сравните число обращений в каналах за неделю с числом созданных за ту же неделю сделок. Совпадения ждать не стоит — часть обращений не заявки. Но если разрыв большой, это повод разобрать несколько обращений вручную и понять, на каком основании они не превратились в записи.
Стык 5. CRM → следующий шаг
Заявка зафиксирована, ответственный назначен, сделка есть. И это ещё не значит, что с ней что-то происходит.
Здесь теряются не обращения, а продолжения: человек не ответил на первое сообщение, и на этом всё закончилось. Не потому, что так решили, а потому, что напомнить было некому — задача нигде не стоит, срока у неё нет.
Признак этого стыка виден в самой CRM: сделки без следующей задачи или даты следующего контакта — при статусе «в работе».
Как проследить свой маршрут за час
Теория заканчивается здесь. Дальше — упражнение, для которого не нужны ни аналитика, ни доступ к чужим системам.
Возьмите пять последних обращений — по одному из каждого канала, если каналов несколько. И по каждому пройдите путь назад, отвечая на четыре вопроса:
- Куда оно пришло физически? Не «на сайт», а конкретно: в какой ящик, чат, аккаунт.
- Кто его туда перенёс дальше и когда? Если никто — так и запишите.
- В какой момент у него появился ответственный? И появился ли.
- Что было последним действием и когда?
Пять обращений — это не статистика, а срез. На нём уже можно поискать повторяющиеся ручные передачи; если картина вышла неясной — расширьте выборку. Такие места особенно стоит проверить при росте потока или когда конкретного сотрудника нет на месте.
И отдельно отметьте, на каких переходах передача происходит сама, а где нужно ручное действие. Так видно не «автоматизировано или нет», а где именно процесс зависит от человека.
Что чинится без автоматизации
Сначала то, что стоит времени, а не денег.
Свести каналы к одному входу. Не обязательно технически: иногда достаточно договориться, что все обращения пересылаются в одно место, и назначить, кто это делает.
Назвать ответственного поимённо. Не «отдел», не «мы», а человек — и заместитель на случай отпуска. Это снимает главную неопределённость третьего стыка: становится понятно, кто должен взять обращение.
Договориться о сроке реакции и о том, что считается ответом. Автоответ подтверждает получение обращения, но не заменяет ответ по существу — путать их не стоит.
Завести правило второго касания. Не ответил — напомнить через день. Пока обращений немного, это делается вручную по списку.
Если после этих четырёх шагов маршрут перестал рваться — дальше можно не усложнять и не тратить деньги на систему.
Когда нужна система
Ручные договорённости зависят от внимания людей, а при росте потока следить за ними становится сложнее. Вот три сигнала, при которых уже имеет смысл считать автоматизацию.
Каналы не сводятся в одно место, и ручная пересылка создаёт пропуски или задержки. Пересылка руками из нескольких мест в одно становится отдельной операцией, за которой приходится следить.
Обращений столько, что «помнить» перестало работать. Точного порога здесь нет: он зависит от числа людей и длины разговора с клиентом. Признак не в цифре, а в том, что вы находите просроченные обращения задним числом.
Нужны данные, а не ощущения. Сколько обращений, из каких источников, сколько дошло до сделки. Пока перенос ручной, эти числа описывают не поток, а то, что в него попало.
Если ручные договорённости уже не держат маршрут, следующий вопрос — что именно автоматизировать: передачу обращения после поступления или связку каналов с CRM. Это два разных объёма работ, и разбираю я их отдельно. Здесь достаточно понять, какой стык у вас рвётся; из чего складываются оба варианта — на странице автоматизации.
Чего этот разбор не покажет
Три вещи, чтобы не переоценить упражнение.
Он не скажет, сколько денег вы теряете. Посчитать «недополученную выручку» по пяти обращениям нельзя, и любая такая цифра будет оценкой, а не замером. Маршрут показывает разрывы, а не их стоимость.
Он не заменяет разговор с людьми. Часть переносов и напоминаний живёт в головах, а не в системах, и в схеме их не видно. Спросите менеджеров, что они делают руками: часть маршрута существует только в этом виде и в схему не попадёт.
Он не чинит то, что происходит до обращения. Если человек ушёл с сайта, не написав, маршрута у него не было вовсе. Это другая задача, и решается она в другом месте.
Что сделать на этой неделе
Пройдите пять обращений по четырём вопросам. Это час работы, и после него разговор про автоматизацию перестаёт быть разговором про инструменты: у вас на руках список конкретных мест, где путь заявки держится на человеке.
Пришлите этот список — или просто перечислите каналы, куда к вам приходят обращения, и скажите, кто переносит их в одно место. Отвечу, какие стыки у вас есть, что из них чинится договорённостями за вечер и что действительно требует системы.
Если окажется, что автоматизировать нечего, — так и скажу. Маршрут из двух шагов не нуждается в схеме.