Пользователь хочет купить. Почему компания все равно отказывается?

В корпоративной покупке положительная реакция пользователя еще не означает, что компания готова платить. У руководителя и закупщика свои основания для решения. Разберу, как выявить эти различия и проверить предложение до того, как команда начнет менять цену, презентацию или рекламу.

На демонстрации человек узнает свою проблему, задает вопросы и просит прислать предложение. Через неделю отвечает: «Обсудили внутри, пока не готовы». Продажи ищут причину в цене, маркетинг переписывает презентацию. Но возможно, продукт понравился человеку, который будет им пользоваться, а для остальных участников покупки его ценность так и осталась неясной.

В первой статье я разбирал, почему рынок может иначе прочитать обещание продукта. Здесь хочу продолжить эту мысль: даже понятное предложение еще должно пройти через людей с разными задачами и полномочиями. Интерес одного из них легко принять за готовность всей компании покупать.

Допустим, компания предлагает сервис, который собирает рабочие данные и автоматически готовит отчеты. В презентации написано: «Освободим вашу команду от ручной отчетности». Это условный пример, на котором удобно разобрать логику покупки.

Специалист, который каждую неделю сводит несколько таблиц, видит понятную пользу. Меньше копирования, меньше ошибок, больше времени на другую работу. Но он может спросить, кто перенесет старые данные, сколько времени займет настройка и придется ли потом вести отчеты сразу в двух системах.

Для руководителя экономия времени сама по себе еще не объясняет необходимость расходов. Ему нужно понять, станет ли информация доступна раньше, можно ли доверять расчетам и кто отвечает за результат. Если отчет теперь собирается быстрее, но решения принимаются по-прежнему, польза для подразделения требует отдельного обоснования.

Закупщик может соглашаться со всеми доводами и все равно не дать сделке двигаться дальше. Ему не хватает условий сопровождения, сведений о поставщике или понятного порядка выхода из договора. В такой ситуации более убедительное описание продукта не заменит недостающих документов.

Каждый из этих людей оценивает предложение по существу. Просто последствия покупки у них разные. Поэтому я бы сначала выяснил, на чьем вопросе остановилось решение, и только потом менял презентацию.

Схема «пользователь, руководитель, закупщик» помогает начать разговор, но не описывает любую компанию. В небольшой организации все эти функции может выполнять один человек. В крупной к покупке подключатся технические специалисты, юристы, служба безопасности и владелец бюджета.

Даже одинаковая должность не означает одинаковое участие в решении. Один руководитель самостоятельно оплачивает сервис. Другой рекомендует его финансовому директору и не может ничего обещать поставщику. Один специалист выбирает рабочие инструменты, другой получает уже принятое решение.

Как социолог, я бы смотрел прежде всего на то, как устроено взаимодействие внутри компании. Кто заметил проблему? Кто предложил искать решение? Кто согласует деньги, а кто может остановить покупку? Кому придется отвечать, если внедрение не получится?

Ответы нужны для вполне практической задачи: понять, с кем проводить исследование. Разговор с довольным пользователем не заменяет интервью с человеком, которому предстоит обосновать расходы.

Представим, что все участники оценили предложение как интересное. Команда получает хорошую обратную связь и решает, что можно усиливать продвижение. Но за одинаковыми оценками могут стоять оговорки.

Специалист готов пользоваться сервисом, если не придется вручную переносить историю данных. Руководитель поддерживает покупку, если будет понятен эффект для подразделения. Закупщик не возражает, если поставщик примет необходимые условия договора. Пока эти условия не выполнены, общая симпатия к идее мало говорит о следующем шаге.

В исследовании полезно разделять понимание предложения и возможность действовать. Человек может точно пересказать продукт, признать его пользу и при этом не иметь оснований рекомендовать покупку.

Мне здесь важнее ответ на вопрос «Что вам потребуется, чтобы вынести предложение на обсуждение?», чем оценка привлекательности по шкале. Он помогает увидеть недостающую информацию, внутренние согласования и риски, которые команда продавца могла не заметить.

В нашем примере я начал бы с короткого описания сервиса без пояснений продавца. Попросил бы человека своими словами рассказать, что получит компания и что ей придется сделать самой. Если он услышал «теперь отчеты всегда правильные», а сервис автоматизирует только сборку, сначала нужно исправить это расхождение.

Затем разобрал бы внедрение на конкретных действиях: подключение рабочих данных, передача доступа, назначение ответственного за настройку. Общий вопрос о доверии редко показывает, что произойдет, когда разговор дойдет до этих условий.

Дальнейшие вопросы зависят от участия человека в покупке. Пользователю важно обсудить, какую часть работы он готов изменить. Руководителю нужно сформулировать, по каким признакам он будет оценивать результат. С закупщиком стоит выяснить, чего не хватает для сравнения поставщиков и согласования договора.

Это не означает, что участники обязательно разойдутся во мнениях. Но если расхождение есть, его нельзя терять в средней оценке предложения.

В Synth Research мы используем синтетический предтест как предварительную проверку исследовательской конструкции. Можно предъявить одно предложение синтетам с разными задачами, полномочиями и ограничениями, затем сравнить возникшие вопросы и возражения.

Для нашего примера можно проверить две версии текста: одна объясняет экономию рабочего времени, другая подробнее описывает условия внедрения. Сам продукт и условия покупки при этом должны оставаться одинаковыми. Иначе мы будем сравнивать разные предложения и не поймем, что изменило ответ.

Многое зависит от того, как заданы сами участники решения. Просьба сыграть «типичного руководителя» может привести к воспроизведению стереотипов. Я бы опирался на известные условия работы, материалы предыдущих исследований и фактический порядок покупки. Недостающие сведения обозначал бы как допущения.

Такой предтест дает возможные объяснения и вопросы для проверки. Он не показывает доли реальных покупателей, не измеряет спрос и не доказывает, что одна версия увеличит продажи. Ключевые предположения нужно вынести в живые интервью или полевое исследование.

В живых интервью я бы разбирал опыт конкретных покупок: как выбирали поставщика, кто подключался к обсуждению, когда возникли задержки и какие аргументы потребовались. Это позволяет сопоставить найденное возражение с реальным порядком принятия решения.

Если пользователю непонятна нагрузка при внедрении, понадобится описание запуска. Если руководитель не видит результата для подразделения, нужны критерии оценки и основания для обещаний. Если закупщику не хватает условий договора, начинать с рекламного текста вообще не стоит.

У одного продукта при этом должно оставаться общее обещание. Меняются подробности, доказательства и ответы на вопросы, которые возникают на разных этапах покупки.

Перед следующей переработкой презентации я бы проверил, может ли заинтересованный человек объяснить пользу продукта коллегам и предложить им обоснованный следующий шаг. Если для этого ему не хватает информации, компании важно выяснить какой именно. Иначе продажи будут снова и снова получать интерес на встречах, который не удается превратить во внутреннее решение клиента.