Сегодня мы поможем определить слабые места вашего бренда и также — в чем кроются потребности клиента в B2B — для этого предлагаем ответить на вопросы из этой статьи.
Попытка продать людям, которые не могут или не хотят покупать, — это огромная потеря производительности бюджета и команды. Лучшие тратить время только на тех, кто нуждается в вашем товаре, хочет и готов работать с вашим брендом для удовлетворения своих потребностей.
5 вопросов, чтобы определить проблемы и потребности клиента в B2B
1. Что вызывает наибольший дискомфорт?
Этот вопрос наверняка возбудит эмоции вашего потенциального клиента и поможет дойти до обсуждения главных потребностей. Независимо от того, сталкиваются ли клиенты с каким-то внешним препятствием перед покупкой, с непрофессионализмом вашей команды или чем-то другим, вопрос о том, что их больше всего расстраивает, — отличный способ найти корень проблемы и потенциальное решение.
2. Что думает шеф?
- Как правило, именно глава компании контролируют бюджет, определяет потребности клиента в B2B и принимает решение о заключении сделки.
- Если представитель вашего клиента не знает (или не думает) о деловых вопросах и потребностях своего босса, это может быть признаком того, что он слишком неопытен, чтобы помочь в продвижении сделки.
3. Какие задачи занимают больше всего времени в рабочем графике?
Это еще один угол подхода к проблемам в бизнесе клиента. Этот вопрос покажет конкретную ценность вашего продукта для второй стороны.
Как выявить потребности клиента? Как понять, что хочет клиент?
Спросите своего потенциального клиента о том, как решение вопроса повлияет на их команду. Это сэкономит им два часа рабочего времени в день? Поможет сократить вдвое время, проведенное на собраниях? Если вы сможете найти решение конкретной проблемы, которого хочет вторая сторона, то значительно продвинетесь к заключению долгосрочной сделки.
4. Какие претензии у рядового работника?
Вопрос может показаться незначительным, но ответы, которые вы получите, имеют чрезвычайно важное значение.
То, что начинается как жалоба на нехватку бумаги в рабочем принтере, может привести вас к большим болевым точкам, таким как: «У нас недостаточно бумаги, потому что бюджеты компании были сокращены в этом квартале. Мы фокусируем все доступные ресурсы на рекламе в ближайшие недели и месяцы».
Отсутствие бумаги, казалось бы, смехотворная и безобидная жалоба, но когда опытный продавец продолжит задавать последующие вопросы и копаться в теме, он сможет прийти к реальной проблеме и предложить ее решение.
5. Что мешает развитию взаимоотношений клиента с вами?
- Каким будет план борьбы с проблемами?
- Есть ли дедлайн, который вы поставили для решения проблемы?
- Каковы ваши ожидания: насколько сложным будет решение?
- Кто из вашей команды работает над проблемой прямо сейчас?
+ 3 совета для бренда
1. Используйте язык вашего потенциального клиента, когда говорите о его проблемах и потребностях
Это психологическая техника, которая поможет построить доверительные отношения с вашим потенциальным клиентом. Вместо того чтобы пытаться произвести впечатление, полагаясь на жаргон, понятный только вашим коллегам, покажите потенциальному клиенту, что вы интересуетесь им и его бизнесом, используя его язык и терминологию.
5 экспертных вопросов для выявления потребностей | Тренинг по продажам
2. Узнайте, кто уполномочен принимать решения со стороны клиента
Спросите своего потенциального клиента, из чьего бюджета будет производиться покупка и какие отделы должны будут участвовать в принятии решения о покупке. Нет смысла проводить часы в общении с человеком, не в компетенции которого заключить сделку.
3. Определите другие заинтересованные стороны сразу
Если за вашим клиентам стоит их компания-инвестор, у них могут быть совершенно разные приоритеты, и вам нужно знать об этом заранее. Если возникнет необходимость пройти двухмесячный юридический процесс, прежде чем вы сможете закрыть сделку, об этом тоже нужно знать заранее.
Клиенты в B2B-сфере иногда беспокоятся, что они будут выглядеть менее авторитетными, если не только их компания принимает решения, поэтому используйте дополнительные вопросы во избежание неожиданностей.
Источник: spark.ru
Исследование рынка и аудитории: как правильно определить потребности клиентов
В этой статье мы расскажем о всех аспектах проведения исследования и том, как его результаты помогают улучшить продукт, повысить удовлетворенность клиентов и увеличить прибыль компании.
194 просмотров
Что такое исследование рынка и аудитории?
Понимание направления развития рынка и интересов аудитории важный элемент при развитии любого бизнеса. Оно позволяет понять, какие продукты или услуги нужны потребителям, какие их потребности и какие проблемы они имеют, а также кто является конкурентами на рынке.
Исследование рынка и аудитории необходимо для комплексного подхода к изучению рынка и потребностей потенциальных клиентов, включающий в себя анализ данных о рынке, конкурентов, сегментации аудитории и потребностей клиентов. Он может проводиться как внутренними силами компании, так и с помощью внешних исследовательских агентств.
Цель исследования — выявить потенциальные возможности и проблемы на рынке, понять потребности клиентов и разработать стратегию, которая будет наиболее эффективной для удовлетворения этих потребностей и преодоления препятствий.
Для проведения исследования рынка и аудитории необходимо определить основные задачи исследования, выбрать методы исследования, опросить аудиторию и провести анализ данных. Результаты исследования помогают разработать более точную стратегию продаж, понять, какие продукты будут наиболее успешными на рынке и какие изменения необходимо внести для удовлетворения потребностей клиентов.
Таким образом, исследование рынка и аудитории является неотъемлемой частью бизнес-планирования и помогает компаниям лучше понимать свой рынок и аудиторию, принимать более обоснованные решения и добиваться большего успеха на рынке.
Подготовка к исследованию рынка и аудитории
Как правило, подготовка к исследованию рынка и аудитории включает в себя несколько этапов.
Во-первых, необходимо определить цель исследования. Например, целью может являться улучшение качества продукта, расширение целевой аудитории, увеличение продаж и т.д.
Во-вторых, необходимо определить методы сбора и анализа данных. В зависимости от цели исследования, вы можете использовать различные методы, такие как опросы, фокус-группы, интервью, анализ данных социальных сетей и т.д. Важно выбрать методы, которые позволят получить максимально точные и полезные данные.
В-третьих, необходимо определить целевую аудиторию. Это позволит собрать данные, которые отражают предпочтения и потребности именно вашей целевой аудитории. Например, если вы продаёте товары для женщин, то вам нужно определить основные параметры аудитории, такие как возраст, интересы, уровень дохода, семейное положение и т.д.
В-четвертых, необходимо разработать план исследования, включающий в себя детальный план действий, список вопросов для опросов и интервью, выборки, методы сбора и анализа данных.
Качественная подготовка к исследованию рынка и аудитории позволит получить наиболее точные и полезные данные, которые могут быть использованы для разработки маркетинговых стратегий и улучшения бизнес-модели.
Определение потребностей клиентов
Когда мы говорим об определении потребностей клиентов, мы говорим о процессе выявления того, что именно заставляет людей приобретать определенный продукт или услугу. Это важный шаг в маркетинговых исследованиях, потому что позволяет понять, как лучше нацелить свою маркетинговую стратегию и продвижение на целевую аудиторию.
Так же нам нужно ответить на следующие вопросы:
- Какие проблемы стоят перед вашей целевой аудиторией?
- Какие желания и потребности у клиентов?
- Какие пожелания у клиентов относительно вашего товара/услуги?
- Какие причины могут остановить клиента от покупки?
Ответы на эти вопросы помогут вам определить, что необходимо улучшить в вашей продукции/услугах, чтобы она максимально удовлетворяла потребности клиентов. Это может быть изменение качества товара, обновление дизайна или дополнительные услуги.
Кроме того, важно учитывать не только потребности клиентов, но и их мотивы, страхи и желания. Это поможет сформировать более эффективные маркетинговые сообщения и увеличить вероятность того, что клиенты приобретут продукт или услугу.
Наконец, определение потребностей клиентов — это постоянный процесс, который необходимо периодически обновлять и дополнять. Рынок и потребности клиентов постоянно меняются, поэтому необходимо следить за изменениями и адаптировать свою маркетинговую стратегию в соответствии с ними.
Применение результатов исследования
Важно понимать, что полученные в результате исследования данные необходимо использовать не только для создания новых продуктов или услуг, но и для оптимизации текущих бизнес-процессов.
Одним из примеров использования результатов исследования может быть изменение маркетинговой стратегии компании. Если исследование показало, что основная аудитория клиентов находится в определенном возрастном диапазоне, то компания может изменить тон и стиль своей рекламы, чтобы более точно привлекать эту аудиторию.
Еще одним примером является изменение дизайна сайта компании на основе полученной информации об интересах и предпочтениях клиентов. Если данные показывают, что клиенты предпочитают простые и лаконичные дизайны, компания может пересмотреть свой веб-сайт и упростить его интерфейс.
Кроме того, результаты исследования могут помочь оптимизировать производственные процессы компании. Например, если исследование показало, что клиенты ждут от компании быстрого и качественного обслуживания, то компания может пересмотреть свою логистику и ускорить процесс доставки товаров.
Важно понимать, что результаты исследования не являются конечными и должны регулярно обновляться и анализироваться, так как рынок и интересы аудитории постоянно меняются. Только так компания сможет сохранять свою конкурентоспособность и адаптироваться к новым требованиям рынка, улучшать свои продукты и услуги, чтобы они соответствовали потребностям и предпочтениям клиентов.
Источник: vc.ru
7 способов лучше понимать потребности пользователей и доносить их до команды разработки
Чем лучше команда разработки понимает потребности пользователей, тем больше вероятность того, что качество решения будет выше, система — успешной, а команда — более мотивирована развивать систему дальше. В этой статье мы рассмотрим некоторые практики, которые помогают делать работу по выявлению и описанию потребностей пользователей чуть качественней, чем делаем её обычно. Каждая практика сопровождается обилием ссылок на дополнительные материалы по теме. Статья не про то, как проводить интервью с заказчиками. Но используя принципы, которые в ней описаны, вы сможете проводить интервью более глубоко и качественно.
Статья будет полезна аналитикам, Product Owner’ам, руководителям проектов и всем, кто так или иначе связан с работой по выявлению и документированию потребностей.
Каждую практику можно использовать независимо, а можно применять их все — как вам удобнее в конкретном проекте.
1. Документировать выявленные потребности
Ключевая практика, которая сильно недооценивается. Очень часто донесение потребностей до команды ограничивается устным разговором и остается только в головах у тех, кто принимал в нем участие. Дело усугубляется тем, что каждый участник мог понять всё по-своему и в таком искаженном виде донести информацию до других членов команды.
Документирование позволит:
- Лучше понять эти самые потребности: когда перед глазами есть текст, то гораздо проще найти в нем ошибки, логические неточности, сформировать вопросы, про которые не подумал в первый раз, подвергнуть формальному анализу — об этом почти вся остальная часть статьи. Когда этот текст находится у тебя «в голове» в виде неструктурированного и часто «аморфного» ощущения, то такой анализ сделать практически невозможно.
- Лучше коммуницировать с командой: когда есть текст, то любой участник может точно так же найти в нем неточности и задать вопросы. Одна голова хорошо, а несколько — лучше 🙂
- Быстрее подключать к проекту новых людей.
- Валидировать решение: понять, что реализованная функциональность решает то, ради чего она задумывалась.
Это трудоемкий процесс, но пренебрегать этим не стоит, особенно в сложных проектах. Просто начните документировать «как можете», а дальше улучшайте с помощью описанных ниже практик. Например, проверяйте через верхнеуровневый чек-лист, про который будет написано ниже.
Дополнительные материалы по теме:
- Статья «Не пишешь = не думаешь. Мышление письмом/моделированием»
- Книга «Как делать полезные заметки»
2. Проверять описанные потребности через верхнеуровневый чек-лист
С помощью этого чек-листа можно проверять свои артефакты или артефакты, которые вы получили на вход от заказчика, бизнес-аналитика, Product Owner’а или других источников.
Проводим «тест на коробку из-под обуви»: берем формулировки и заменяем в них все названия системы на «коробка из-под обуви». Если смысл формулировки не меняется, то это повод насторожиться, скорее всего пропущена важная специфика вашей предметной области. «Система должна помогать проводить расследования» -> «Коробка из-под обуви должна помогать проводить расследования». Ну да, в нее можно, например, складывать бумаги по расследованию, чтобы не потерялись — вполне себе помощь в расследовании! Но для команды разработки такая формулировка бесполезна.
Проверяем контекст и пропущенные ролевые описания. Должно быть как-то так:
- Из описания можно понять контекст использования запрашиваемой функциональности: кто принимает участие в автоматизируемом системой процессе, какие есть смежные системы, какова их функция и пр. Для понимания контекста помогут несколько конкретных примеров из «жизни заказчика», где возникает необходимость в этой функциональности. Обращаем внимание на язык — если в нем слишком много внутренних терминов из нашей системы, а не терминов из предметной области заказчика, то это повод насторожиться.
- Из описания можно определить роли, для которых делается доработка или которые она затрагивает косвенно или напрямую.
- Для каждой роли понятны задачи, которые система должна помочь решить человеку, находящемуся в данной роли. В некоторых случаях система должна не помогать, а наоборот, создавать максимум препятствий для решения задачи. Например, для «негативных ролей»: мошенников, недобросовестных администраторов и пр.
- Решаемые ролью задачи должны быть связаны с бизнес-сценариями, а не со сценариями работы пользователя внутри системы. Чтобы понять, выбрана ли задача правильно, можно воспользоваться такой эвристикой: получает ли человек в этой роли за выполнение этой задачи зарплату. Например, офицеру безопасности платят не за составление «поискового запроса в DLP-системе», а за проработанный инцидент ИБ: своевременно выявлен нарушитель; выявлено и предотвращено намерение «слива» конфиденциальной информации и пр. Либо могут быть описаны задача и гипотеза сценария внутри системы, но проведена цепочка причинно-следственных связей до бизнес-сценария.
Проверяем полноту и корректность причинно-следственных цепочек. Связь между задачей и бизнес-сценарием не должна иметь пропущенных причинно-следственных цепочек. Пример пропущенных цепочек:
> Офицер безопасности хочет получить информацию про файлы, который Петров копировал с рабочего компьютера на флешки 12 декабря 2021. Ему нужен этот список, чтобы обеспечить безопасность своей организации. Пропущена цепочка или несколько цепочек, где объясняется для чего ему эта информация, что он с ней будет делать и как это приводит к обеспечению безопасности. От информации в пропущенных цепочках будет зависеть, например, атрибутный состав события копирования на флешку (только метаданные файлов, их содержимое и пр.), а от этого может сильно зависеть архитектура решения.
> Через API нужно выгружать список пользователей и действий, которые они совершили в нашей системе. Это нужно, чтобы руководитель смог сделать отчет и выявлять среди своих подчиненных самых неэффективных. Пропущена цепочка, связанная с тем, как именно руководитель будет принимать решение об эффективности сотрудников. От этого может сильно поменяться состав данных, которые нужно выгружать через API.
Дополнительные материалы по теме:
- про роли, потребности, системные уровни (то, что определяет «язык» описаний) — в книге «Практическое системное мышление 2022»;
- про чек-листы — в книге «Чек-лист. Как избежать глупых ошибок, ведущих к фатальным последствиям»;
- про причинно-следственные связи и пропущенные цепочки в объяснениях:
- статья и видео Максима Дорофеева про обоснование причинно-следственных связей;
- статья «Cause-effect diagrams: A pragmatic way of doing root-cause analysis»;
- статья «Ожидая короткие понятийные расстояния».
3. Проводить более глубокий анализ проблемы
Такой анализ позволяет лучше понять проблему: насколько она частая, насколько актуальная для заказчиков. Занимает больше времени, чем верхнеуровневый чек-лист, но позволяет выявить больше деталей. Также позволяет делать описание в более структурированном виде. Можно применять как до верхнеуровневого чек-листа, так и отдельно от него.
Получаем и документируем ответы на вопросы:
В чем состоит проблема/потребность, для которой нужна новая функциональность?
Выясняется общая пользовательская задача или проблема. Это может быть как «широкая»/жизненная/рабочая/общая потребность, по сути не связанная с нашим продуктом, так и как проблема, возникающая именно при использовании нашего продукта (эвристику см. в практике «Верхнеуровневый чек-лист»). Проблема может быть описана как в виде пошагового сценария, так и просто текстом. Если есть информация, то добавлять описание, как часто встречается эта проблема, когда она встречалась последний раз — дает понимание, что это действительно важная задача, которую нужно решать.
Как пользователи сейчас решают задачу? Описание текущего бизнес-процесса.
Выясняется то, как сейчас пользователь закрывает потребность/решает проблему. Текущим решением проблемы может быть необязательно наш продукт, это может быть другой софт или административные меры в организации. Если пользователь вообще никак не закрывает потребность и даже не пытается её решить, то это повод насторожиться — возможно (но не обязательно!), выбранная проблема недостаточно важна для наших потребителей, и они не будут готовы заплатить за её решение.
Какие проблемы пользователи испытывают с текущим решением? Как они сейчас эти проблемы решают?
Это те проблемы, которые мы планируем решить разработкой новой функциональности.
Какие проблемы испытывает наша компания с текущим решением? Как мы их решаем? Есть ли у конкурентов такая функциональность?
Изменения в продукте могут быть вызваны необязательно потребностями заказчиков, а также потребностями нашей компании. Например, большие затраты отдела внедрения на обновление системы у заказчиков; большое количество обращений в техподдержку с типовыми вопросами и пр.
Дополнительные материалы по теме:
- Книга «Спроси маму: Как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?»
- Книга «Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
- Метод Event Storming
4. Использовать DSM (design structure matrix)
При первичной проработке решения часто учитываются только видимые/очевидные модули системы, которые нужно доработать или создать. Но так как в системе много связей, то изменения в смежных модулях не всегда очевидны. Их можно забыть и это выявится только на поздних этапах работы над новой функциональностью.
Если иметь список связанных модулей, то можно задавать вопросы «наверх», то есть от нашей системы к надсистеме (организации заказчика, в бизнес-процессах которой участвует наша система): какая информация о бизнес-сценариях/потребностях нужна, чтобы принять решение о том, как должна выглядеть доработка в том или ином модуле системы? Какой информации нам не хватает, чтобы принять это решение? Не повлияет ли изменение в связанном модуле на другие бизнес-сценарии?
Часто изменение одного модуля требует внесения изменений в другой связанный модуль, но так как эти связи не всегда можно удерживать в голове и вспомнить в нужный момент, то необходим дополнительный инструмент: матрица связанности модулей — DSM (design structure matrix).
В столбцах и в строках размещаются сами модули, а на пересечениях — степень зависимости между ними, либо флаг, указывающий на наличие зависимости и опциональный комментарий, поясняющий суть зависимости.
Пример упрощенной матрицы для модулей автомобиля:
Метод применяется рекурсивно. Например, в рамках разработки одной функциональности изменили Модуль 1, по матрице выявили, что изменения в этом модули могут затрагивать Модуль 2. Анализируем выявленную связь и понимаем, что нужно вносить изменения и в Модуль 2 тоже. В свою очередь эти изменения в Модуле 2 затрагивают Модуль 10 и Модуль 15. Принимаем решения о доработке и этих модулей.
Проверяем, как эти изменения связаны с другими модулями системы и т.д. При этом при проработке требований к этим связанным модулям могут возникать точечные вопросы к бизнес-сценариям. Также этот способ позволяет не забывать те модули, которые часто упускаются из виду.
Ниже пример того, как выглядят связи в одном из наших продуктов (на скриншот поместилось меньше половины модулей, а качество картинки ухудшено специально):
Ячейки с красным флажком — это связи, где добавлено текстовое примечание о том, на что следует обратить особое внимание.
Составить такую матрицу для своего продукта может быть трудоемким делом, особенно если это большой продукт. Но в конечном счете, это окупится сторицей, а поддержание матрицы в актуальном состоянии не займет много сил в времени.
Дополнительные материалы по теме:
- Cайт dsmweb.org
- Статья «Applying The Design Structure Matrix To System Decomposition And Integration Problems: A Review And New Directions»
5. Записывать «выученные уроки», чтобы не наступать на одни и те же грабли дважды
Записываем проблемы, с которыми сталкиваемся в процессе разработки новой функциональности и используем как чек-лист. Такой список будет постоянно пополняться. Тут важно не лениться и все записывать — в текущем моменте нам кажется, что мы никогда не совершим такую же ошибку снова (она очевидна!), но проходит несколько недель и замотавшись в проектной суете можно наступить на те же грабли второй раз. А чек-лист всё надежно сохранит и вместе с привычкой регулярно к нему обращаться может сэкономить командам разработки очень много времени и сил. У нас список таких «выученных уроков» на текущий момент получился объемом примерно как вся эта статья, а некоторые из пунктов были обобщены и добавлены в верхнеуровневый чек-лист.
Примеры:
- При изменениях в версиях совместимого third-party ПО (СУБД, ОС, Антивирусы и пр):
- Какие предыдущие версии этого ПО поддерживаем? Поддерживаем ли их вообще или оставляем только одну новую?
- Поддерживаем ли обновление со старых версий этого ПО?
- Есть ли разница в поддержке third-party на разных операционных системах, на которых работает наш продукт (например, версия СУБД для InfoWath Traffic Monitor на Astra/CentOS/RHEL). Если разница технически есть, то уточняем у менеджера продукта необходимость поддержки на всех или только на какой-то конкретной ОС.
- .
6. Выявлять пропущенные требования качества
Используется как чек-лист: пройтись по каждому пункту и в контексте разрабатываемой функциональности задать вопрос: «нужно ли тут что-то учесть или подумать об этом?». Если да, то задать вопрос: какой информации от заказчика мне не хватает, чтобы выбрать подходящее решение?
Видов требований существуют десятки, но принадлежность к этим видам не так уж важна: если вы встретили в пустыне льва, вам же не нужно знать, что он из семейства кошачьих? Много важнее заметить, что этот лев рядом с вами! Главный источник ошибок в проекте — это неведение относительно наличия каких-то требований. Впрочем, классификация может помочь, если вы зададите себе вопрос: какие виды требований вы ещё не рассматривали для вашего проекта? Вот пример классификации требований качества — знаете ли вы их для вашего проекта?
В качестве чек-листа можно использовать список типов требований качества из книги Системноинженерное мышление:
7. Release early, release often
Всё учесть невозможно. Когда система начнет работать в боевой среде, обязательно будут выявляться неожиданные требования, которые в свою очередь могут потребовать значительных переделок системы. Поэтому, чем раньше очередной релиз будет выпущен и доставлен реальному заказчику, тем быстрее мы получим новую информацию и скорректируем вектор развития продукта.
В промежутках между релизами можно показывать образ решения — MVP или хотя бы макет — коллегам из подразделений, которые находятся близко к заказчику (продажи, внедрение, техподдержка и др.). Можно пригласить их на демо-митинги по спринтам или иногда проводить мини-коридорные исследования: показать кликабельные макеты и просить рассказать, как бы они выполнили те или иные сценарии. Когда люди видят образ решения, то они могут лучше представить его в рабочем/бизнес сценарии и могут более точечно понять, где будут слабые стороны решения или могут быть выявлены неочевидные бизнес-сценарии и проблемы.
Дополнительные материалы по теме:
- Книга «Метод Lean Startup для быстрого тестирования идей и выбора бизнес-модели»
- Книга «Why Greatness Cannot Be Planned: The Myth of the Objective»
На этом всё. Будем рады ответить на вопросы в комментариях!
- выявление потребностей
- аналитика
- руководство проектами
Источник: habr.com
