Как мы исследуем клиентов в сложном B2B

01. Какое решение должно измениться после исследования

Исследование нужно, когда у компании есть конкретный вопрос, на который нельзя ответить по CRM и внутренним обсуждениям. Например, клиент признаёт техническое соответствие продукта, но не покупает его; поставщик хочет предложить обслуживание вместо разовых поставок, но не знает, какую работу клиент готов передать; заказчик не продлевает договор, хотя формальные показатели поставки выполнены.

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

До рекрутинга согласуем вопрос исследования и решение, для которого нужны ответы. Для нового сервиса вопрос может звучать так: «Какие операции клиент готов поручить поставщику и при каких условиях?» Результат поможет определить содержание услуги, границы ответственности и требования к проверке сервиса. Для проигранных сделок выясняем, какие требования и условия повлияли на отказ; результат используем при пересмотре предложения и материалов продажи.

02. Кого интервьюируем: компании и роли внутри них

Сначала определяем, какие различия между заказами, проектами и клиентскими компаниями существенны для вопроса исследования. Это могут быть применение продукта, отраслевые требования, способ закупки или объём обслуживания. Затем для каждой значимой группы ищем компании и людей с нужным опытом. Если финансовый анализ уже выделил разные типы заказов или контрактов, показываем, какие респонденты помогут исследовать каждую такую ветвь.

Отдельно учитываем отношения компании с поставщиком. Этот признак нельзя смешивать с ролью человека в покупке.

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

Технический покупатель определяет пригодность решения: проверяет характеристики, совместимость, нормативные требования и условия технической приёмки. Экономический покупатель распоряжается бюджетом или утверждает расходы, сопоставляет стоимость и риск и принимает решение об оплате. Конечный эксплуатант непосредственно работает с продуктом или получает услугу и может объяснить, что происходит в повседневной работе.

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

Не полагаемся только на клиентский список заказчика. Заранее планируем самостоятельный поиск неклиентов, приглашения и резерв. Объём интервью зависит от числа значимых групп, доступности людей и незакрытых вопросов. В плане и факте видны приглашения, согласования, проведённые разговоры и непокрытые компании и роли. Большое общее число интервью не компенсирует отсутствие нужной роли.

03. Как готовим вопросы и проводим интервью

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

Ниже — примеры тем, из которых собираем гайд, а не обязательный порядок вопросов для каждого интервью.

Вопрос «Что для вас важно при выборе поставщика?» методически допустим. После ответа просим объяснить смысл названного фактора и привести пример, если у человека есть соответствующий опыт. «Надёжность» может означать стабильную работу продукта, наличие запасных частей или своевременную реакцию поддержки. Без уточнения эти ответы нельзя объединять в один вывод.

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

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

04. Как анализируем ответы: от фрагмента к выводу

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

Различаем рабочую задачу клиента, фактор выбора поставщика, боль при использовании, ценность результата и барьер принятия новой услуги. Например, сотруднику нужен пригодный комплект к началу смены — это результат его рабочей задачи. Прозрачный расчёт стоимости помогает владельцу бюджета согласовать покупку — это условие экономического принятия. Эти формулировки нельзя автоматически считать одной основной задачей.

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

При необходимости используем словари ценности и модели принятия продукта. Они помогают сопоставлять ответы, но не заменяют содержание интервью. В представленной сервисной презентации отдельно размечены обязательные условия, факторы дополнительной ценности и препятствия передаче операций. Это прикладная разметка; она не подтверждает проведение формального исследования Кано. Упоминание статистического метода также не доказывает расчёт без исходной матрицы и проверки.

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

05. Как различаем роли и факторы выбора

Три обязательные покупательские роли задают покрытие интервью. Внутри них могут быть несколько участников: например, техническое решение оценивают руководитель информационной безопасности, технический директор и ИТ-директор. Мы не приравниваем должность к покупательской роли: один руководитель может и определять технические требования, и утверждать бюджет.

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

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

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

Из интервью получаем требования к аргументации и проверкам. Для технического покупателя это могут быть испытания совместимости, для экономического — расчёт на данных его компании, для эксплуатанта — проверка реального рабочего сценария. Конкретный состав доказательств определяем по ответам, а не заранее назначаем всем одинаковый пилот.

06. Когда нужна карта клиентского пути

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

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

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

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

07. Как проверяем возможность выполнить требования клиента

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

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

В рабочей карте процесса опыта связываем контакт клиента с действием поставщика, ответственным человеком, источником данных и критерием проверки. Ниже перерисован состав строки из сервисной презентации; значения в строке — методический пример, не факты о конкретной компании.

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

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

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

08. Что заказчик получает и как использует

Состав результата согласуем до начала интервью. Для сложного B2B он может включать следующие материалы.

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

Исследование и внедрение — разные этапы. Отчёт может обосновать изменение предложения или обслуживания, но разработка CRM, обучение команды и запуск новых операций требуют отдельного состава работ. Не называем разработанную модель уже внедрённым решением.

09. Что интервью подтверждают и где нужны другие данные

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

Частоту упоминаний в интервью можно посчитать внутри корпуса с указанием базы. Её нельзя выдавать за долю рынка или статистическую распространённость потребности. Для такого вывода потребуется отдельный количественный дизайн.

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

Готовность респондента рассмотреть новую услугу не равна договору, оплате или успешному использованию. Предлагаем проверку, которая соответствует принятому решению, и заранее определяем, по какому наблюдаемому результату заказчик будет судить о ней.

Иллюстрации в методике перерисованы по аналитическим презентациям и обезличены. Они объясняют способ работы; не подтверждают результаты внедрения и не раскрывают первичные клиентские реплики.