Переведите пожелание в рабочую проблему
Фраза «нам нужна автоматизация» ещё не описывает задачу. Спросите, какой процесс вызывает трудности, кто с ним работает и что происходит сейчас. Возможно, сотрудники несколько раз вводят одинаковые данные, а возможно, проблема связана с неясными правилами согласования. Во втором случае новая программа сама по себе может не устранить причину. Уточняйте последствия без нагнетания. Вместо «вы теряете огромные деньги каждый день» предложите разобраться, какие затраты времени или ошибки действительно наблюдаются. Если точных данных нет, обозначьте предположение и способ проверки. Не придумывайте стоимость проблемы ради убедительного расчёта. В учебной записи отдельно фиксируйте слова клиента, подтверждённые факты и свои гипотезы. Это помогает не строить предложение на удобной, но неподтверждённой истории.
Выясните критерии и участников решения
Пользователю может быть важна простота работы, руководителю — прозрачность процесса, технической команде — совместимость, а финансовой стороне — полная стоимость. Эти требования не всегда противоречат друг другу, но нуждаются в явном обсуждении. Спросите, кто будет оценивать решение и какие вопросы каждый должен проверить. Не пытайтесь обойти неудобного участника, если он отвечает за существенный риск. Запишите критерии до демонстрации. Например, система должна позволять найти статус заказа, ограничивать доступ по ролям и выгружать согласованный отчёт. Формулировка «должна быть современной» слишком расплывчата для проверки. Отдельно выясните ограничения по срокам, данным и внедрению. Не представляйте отсутствие возражений на встрече как согласие на покупку. Для следующего шага нужна понятная договорённость, а для обязательства — соответствующие полномочия.
Предложите проверяемый следующий шаг
Вместо большого предложения сразу можно подготовить демонстрацию одного сценария на вымышленных данных или согласованный ограниченный пилот. Заранее определите, что он должен показать и чего не проверяет. Демонстрация интерфейса не доказывает надёжность интеграции, а короткий пилот не описывает все расходы внедрения. Границы проверки должны быть понятны обеим сторонам. В коммерческом предложении разделите состав работ, предположения, исключения и обязанности клиента. Не скрывайте необходимые дополнительные расходы за низкой стартовой суммой. После встречи отправляют согласованное резюме в рамках разрешённой коммуникации: задача, критерии, открытые вопросы и следующий шаг. Если выяснилось, что продукт не подходит, честное обозначение ограничения полезнее попытки закрыть сделку любой ценой. Крупная продажа строится на согласованности ожиданий, а не на одном удачном приёме убеждения.
Попробуйте на практике
Подготовьте карту вымышленной B2B-сделки по системе учёта заказов.
- Опишите текущий процесс и одну наблюдаемую проблему, отдельно отметив неизвестные величины.
- Назовите три роли участников решения и по одному проверяемому критерию для каждой.
- Предложите демонстрацию одного сценария на вымышленных данных и укажите её ограничения.
- Составьте краткое резюме следующего шага без обещаний результата, давления и предположения, что бюджет уже утверждён.
Как проверить результат. Карта готова, если проблема подтверждается фактами, критерии можно проверить, роли различены, а следующий шаг не выдаётся за согласованную покупку.
Частые вопросы
Нужно ли сразу показывать все возможности продукта?
Нет. Сначала полезно понять задачу и выбрать релевантный сценарий. Избыточная демонстрация может скрыть важные ограничения.
Возражение означает, что клиент не заинтересован?
Не обязательно. Оно может указывать на реальное требование или риск. Уточняйте смысл и проверяйте соответствие, не превращая разговор в спор.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.