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