Холодный обзвон почти всегда начинается одинаково: выгрузили список, скинули в Google Таблицу, раздали менеджерам по сто строк. Первые дни всё выглядит рабочим. Через месяц выясняется, что половина базы отмечена как «не дозвонились», и никто не знает, звонили этим людям один раз или пять.
Ещё через месяц таблица окончательно перестаёт что-либо означать. Её открывают, чтобы «посмотреть, что там», и закрывают.
Разберём, что именно ломается, как перенести обзвон в систему и почему заодно стоит закрыть вопрос с повторными продажами. С прицелом на бизнес в Минске и по всей Беларуси.
Почему таблица не выдерживает
Таблица - отличный инструмент для списка. Проблема в том, что обзвон - это не список, а процесс. У каждого контакта есть состояние, история попыток и следующее действие с датой. Таблица ничего из этого не помнит.
Что происходит на практике:
- Попытки не считаются. Менеджер отметил «не дозвонился». Второй раз он позвонит? Через день? Через неделю? Никогда? Ответ зависит от его настроения и памяти.
- Перезвоны теряются. Клиент сказал «наберите через две недели». Менеджер записал в личный блокнот или поставил напоминание в телефоне. Через две недели он в отпуске.
- Дубли звонков. Двое менеджеров звонят одному человеку с разницей в три дня. Клиент это запоминает - но не в хорошем смысле.
- Результат не собирается. Чтобы понять конверсию обзвона, кто-то должен вручную свести таблицу. Обычно этого не делает никто.
- База не переиспользуется. «Не сейчас, позвоните через полгода» - это ценный ответ. В таблице он умирает.
Отдельно: когда менеджер увольняется, его часть базы уходит вместе с контекстом. Формально строки на месте, фактически работать с ними невозможно - непонятно, что уже было сказано.
Обзвон - это не воронка продаж
Первая мысль при переносе обзвона в CRM - завести лиды и гонять их по воронке. Это работает плохо, и вот почему.
Воронка продаж описывает движение к сделке. Обзвон холодной базы - это в основном движение не к сделке: девять из десяти контактов не купят, и это нормальный, ожидаемый результат, а не провал.
Если весь обзвон складывать в воронку, происходит две неприятности:
- Воронка забивается. Тысяча лидов, из которых интерес проявили тридцать. Конверсия воронки становится нечитаемой, отчёты - бесполезными.
- Стадии не подходят. «Не дозвонились» и «перезвонить в марте» - это не стадии продажи, это состояния попытки контакта.
Поэтому обзвон удобнее вести отдельной сущностью - смарт-процессом со своими стадиями. А лид или сделка создаётся только тогда, когда контакт проявил интерес. Тогда воронка продаж остаётся чистой и показывает реальную картину, а обзвон живёт своей жизнью со своими метриками. Про сам механизм смарт-процессов - в статье «Смарт-процессы и BPM в Bitrix24».
Как это выглядит в работе
В одном из проектов сервисная компания вела обзвон холодной базы в Google Таблицах: кто кому звонил и чем закончилось - знал только сам менеджер, отчётность собиралась вручную, а повторные договоры продлевались по памяти и часто с опозданием. Механика решения (детали - в кейсе про обзвон и повторные сделки):
| Что происходит | Что делает система | Что получает бизнес |
|---|---|---|
| В работу берётся новый список базы | Под каждый контакт создаётся элемент обзвона со стадиями «не дозвонились / перезвонить / отказ / в работу» | Обзвон виден целиком, а не в личной таблице |
| Менеджер закрывает попытку дозвона | Планируется следующая попытка; после N неудачных контакт уходит в отдельный пул | Никто не звонит одному человеку по пять раз и не бросает базу после первой попытки |
| Подходит срок продления договора | Создаётся новая сделка с суммой и составом из предыдущей | Продления не зависят от памяти менеджера |
| Заканчивается день | BI-отчёт пересобирает воронку обзвона и продлений | Отчётность не собирается руками |
Третья строка про повторные продажи попала сюда не случайно. Она решает ту же болезнь, что и обзвон, только с другой стороны: и там, и там результат зависит от того, вспомнит ли человек вовремя.
Что нужно продумать до настройки
Сколько попыток и с каким интервалом. Три попытки в разное время суток - рабочий минимум. Звонить пять дней подряд в одно и то же время бессмысленно: если человек недоступен в 11 утра, он будет недоступен и завтра в 11.
Что считается отказом. «Нам не интересно» и «не сейчас» - разные вещи. Первое закрывает контакт надолго, второе назначает дату возврата. Если это не разделить, вы либо потеряете тёплую часть базы, либо будете звонить людям, которые уже сказали «нет».
Что делать с пулом «недозвон». Через сколько возвращаться, и возвращаться ли вообще. Обычно имеет смысл поднять такой пул через три-шесть месяцев, но уже с другим поводом для звонка.
Кто владеет контактом. Если менеджер звонил и договорился перезвонить, контакт закрепляется за ним. Иначе через месяц по нему позвонит другой, и разговор начнётся с нуля.
Как фиксируется причина отказа. Обязательно из справочника, а не текстом. Через три месяца это превращается в отчёт, который показывает, почему база не конвертируется, - и часто выясняется, что дело не в скрипте, а в том, что база не та.
Повторные продажи: та же болезнь, другая сторона
Если у вас есть услуги с периодом - обслуживание, подписка, договор на год, - то у вас точно есть проблема с продлениями. Она просто менее заметна, потому что клиент уже ваш и никуда особо не денется. До тех пор, пока не денется.
Механика простая: за N дней до окончания текущего договора система создаёт новую сделку с составом и суммой из предыдущей и ставит задачу ответственному. Не напоминание в календаре, а полноценную сделку, которая видна в воронке и по которой собирается отчёт.
Что это меняет:
- продление перестаёт зависеть от памяти конкретного человека;
- в воронке заранее видно объём будущих продлений - это планирование выручки, а не сюрприз;
- отказ от продления фиксируется как проигранная сделка с причиной, а не как тишина;
- становится измеримым отток - показатель, который в сервисном бизнесе важнее конверсии новых лидов.
Похожая механика есть и в кейсе про автоматизацию воронки, где повторные сделки создавались по сроку следующей покупки.