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