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