Методика · 21 сентября 2026 г.

Опрос ЛПР и рядового пользователя в B2B: зачем спрашивать обоих

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

Почему один опрос на компанию даёт искажённую картину

Привычная практика — отправить ссылку на анкету на общий email компании-клиента и считать задачу закрытой. Проблема в том, что B2B-аккаунт — это не один человек, а система ролей с разным опытом и разными интересами. Письмо на общий адрес обычно попадает к тому, кто административно отвечает за переписку с поставщиками, и этот человек в лучшем случае перешлёт его кому-то ещё, а в среднем случае просто не ответит, потому что вопрос не входит в его зону ответственности. Даже если письмо доходит до нужного человека, случайность выбора этого человека означает, что результат опроса на самом деле отражает мнение одной случайной точки в организации, а не сбалансированную картину — и в отчёте это подаётся как «мнение клиента», хотя на деле это мнение конкретного сотрудника, который просто оказался тем, кто открыл письмо.

Кто такой ЛПР и чем его опыт систематически отличается от опыта пользователя

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

Что спрашивать у ЛПР

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

Что спрашивать у рядового пользователя

У рядового пользователя стоит спрашивать про конкретный ежедневный опыт: какие действия в продукте занимают больше времени, чем хотелось бы, что приходится делать в обход продукта — в таблицах, в переписке, — потому что штатный способ неудобен или непонятен, какая функция осталась неосвоенной просто потому, что про неё никто толком не объяснил при внедрении. Важно не спрашивать пользователя напрямую про решение о продлении подписки — это не его зона ответственности, и вопрос либо ставит его в неловкое положение, либо провоцирует ответ наугад. Вместо этого его ответы про ежедневные трудности передаются ЛПР или аккаунт-менеджеру как материал, который тот использует в своём решении, а не как прямой голос в этом решении.

Как технически разделить эти два опроса, не запутав респондентов

Практически это означает две отдельные, разные по объёму анкеты, а не одну общую с веткой «выберите свою роль» в начале — разветвление внутри одной формы увеличивает длину и путает часть респондентов, которые не уверены, как правильно себя классифицировать. Проще отправить ЛПР персональное письмо с более длинной анкетой — пять-семь вопросов, а команде пользователей — короткую, в два-три вопроса, ссылку без явной привязки к теме продления или бюджета. Если контакты пользователей неизвестны напрямую, можно попросить ЛПР переслать короткую ссылку команде — но в этом случае стоит явно обозначить, что ответы анонимны и не будут связаны с конкретным именем при пересылке результата обратно тому же ЛПР, иначе пользователи отвечают формально из опасения, что их правки будут восприняты как жалоба на самих себя. В сервисе «До Сути» для этого удобно завести две отдельные короткие анкеты по разным ссылкам — автоматического объединения ответов по одному аккаунту между двумя разными опросами сервис не делает, сопоставлять ответы ЛПР и команды по конкретному клиенту нужно вручную, например по названию компании в открытом поле.

Как читать расхождение между ролями

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

Когда можно обойтись одной ролью

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

Когда решение принимает не один человек, а комитет закупки

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

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

Типичные ошибки

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

Ограничения подхода

У разделения по ролям есть свои границы. Оно требует знания оргструктуры аккаунта клиента — кто именно принимает решение и кто именно пользуется продуктом, — а эта информация не всегда доступна поставщику, особенно на аккаунтах, которые ведёт только один менеджер по продажам без плотного контакта с операционной командой. Разделение усложняет логистику рассылки: нужно минимум два списка контактов и минимум две версии анкеты вместо одной, что на практике означает больше ручной работы, если процесс не автоматизирован. И наконец, сам факт двух ролей — упрощение: в крупных организациях решение о продлении часто принимает не один ЛПР, а комитет из нескольких человек с разными приоритетами, и даже разделённый на две анкеты опрос не отражает эту внутреннюю многослойность полностью.

Пример: как это выглядит на реальном аккаунте

Компания из пятидесяти человек покупает CRM-систему для отдела продаж. ЛПР — коммерческий директор, согласовавший бюджет и подписавший контракт, — в опросе через полгода ставит высокую оценку: продажи выросли, отчёты стали удобнее готовить к совету директоров, вложение окупилось по его ощущению. Параллельный короткий опрос пяти менеджеров по продажам, которые реально вносят данные в систему каждый день, показывает другую картину: половина сделок заводится не в срок, потому что интерфейс карточки сделки требует слишком много кликов, а часть менеджеров ведёт параллельный список в таблице, потому что так быстрее. Коммерческий директор об этом параллельном списке не знает — для него система работает, раз отчёты приходят вовремя, — но именно этот список через несколько месяцев станет источником данных, когда придётся решать, продлевать ли подписку на более функциональный тариф. Без опроса менеджеров этот разрыв, скорее всего, вскрылся бы только на самом продлении, в виде сухого «давайте пока оставим прежний тариф», без объяснения истинной причины такого решения.

С чего начать

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

1. Выберите пять-десять крупнейших аккаунтов для пилота вместо всей базы клиентов сразу.
2. Зафиксируйте для каждого, кто был ЛПР на входе и кто сейчас реально пользуется продуктом.
3. Подготовьте две короткие версии анкеты — для ЛПР и для пользователей — вместо одной универсальной.
4. Разошлите обе версии и сравнивайте ответы по каждому аккаунту отдельно, а не сразу сводите в общую статистику.
5. Через один цикл оцените, где расхождение ролей оказалось самым информативным, и расширяйте пилот с этого сегмента.