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