Иногда в сети можно встретить комментарии о том, что в наших магазинах на консультантов в торговых залах приходится охотиться. Якобы, в нужный момент их не оказывается рядом и покупатель остается с незнакомым ему товаром один на один.
Мы решили бросить вызов этому недугу и сделали мобильное приложение М.Видео еще полезнее - через него совсем скоро можно будет вызывать продавца в то место в магазине, где вы стоите.
Чтобы найти максимально простое и удобное решение, мы рассмотрели возможные поведенческие сценарии «вызова консультанта» через приложение, а затем провели полевое исследование трех наиболее вероятных на наш взгляд вариантов, по итогам которого лучший отдали в продакшен.
В первый сценарий мы закладывали идею того, что консультант проактивно видит интерес покупателя к товару и оперативно реагирует. Схема сценария была продуктово-ориентированной.
Сценарий №1:
Покупатель сканирует ценник ближайшего товара.
Консультант получает сообщение с координатами ценника.
Консультант находит покупателя.
Этот сценарий оказался самым простым и понятным для пользователей. Покупатели довольно легко понимали, что именно им нужно делать. Однако в результате эксперимента были выявлены два неочевидных на первый взгляд барьера:
люди считали, что им нельзя отойти от отсканированного товара;
у них были сомнения в том, что консультант быстро найдет нужный товар.
С другой стороны, консультанты отнеслись к этому сценарию прохладно и оценили его скорее, как неудобный. Они отмечали, что частые изменения товарной выкладки в зале магазина служат барьером в быстром поиске покупателя. Плюс, они всегда знали где нужный товар, но путались, когда был отсканирован товар с повторяющейся выкладкой: капсулы, батарейки и прочее.
Пользователи с большим сомнением относились к этому способу вызова консультанта, поскольку не могли поверить, что кто-то действительно их так сможет найти (хотя консультанты реально смогли бы).
Во втором сценарии мы ориентировались не на товар, а на человека, предположив, что продавцам будет легко его найти по описанию. Посетители должны были самостоятельно выбрать наименование отдела, в котором они находятся, и добавить комментарии с описанием своих отличительных черт, например, цвет верхней одежды (выбранный вариант).
Сценарий №2
Покупатель разрешает доступ к геопозиции.
Покупатель проверяет адрес магазина, в котором находится.
Покупатель выбирает отдел, в котором находится.
Покупатель пишет комментарий, например, описывает верхнюю одежду.
Консультант получает сообщение с названием отдела и комментарием покупателя.
Консультант находит покупателя.
Еще до начала эксперимента мы не возлагали особых надежд на описанную выше механику. Было понятно, что данный сценарий самый трудоемкий для пользователя из всех рассматриваемых. Однако, это не отменяло того, что он оставался понятным и относительно интуитивным. Кроме того, в процессе выполнения задачи покупатель понимал, как будет работать эта функциональность, что должно было снимать тревогу, вызванную вопросами: «Как консультант меня найдет?» и «Мне нельзя никуда уходить?» (см. Сценарий №1).
На удивление, именно этот сценарий оценили консультанты наших магазинов, снабдив его эпитетами: «понятный» и «рабочий». Объяснялось все тем, что продавцы получали сообщение с более подробными данными о клиенте (название отдела, комментарий о пользователе).
Покупатели говорили, что хотели бы видеть в приложении, за какое примерно время подойдет консультант (примерно, как в приложениях по вызову такси). А еще люди надеялись на то, что приложение самостоятельно определит отдел, в котором находится пользователь, по геолокации. Вот вам и приватность, и страх перед «Большим братом».
Третий сценарий был заточен на использование специальных артефактов, размещенных по торговым залам.
Сценарий №3
Покупатель находит плакаты «Вызвать консультанта».
Покупатель сканирует QR на плакате.
Консультант получает сообщение с координатами плаката.
Консультант находит покупателя.
У данного сценария обнаружилось сразу несколько проблем:
Пользователи воспринимали плакаты как рекламные постеры.
Люди не обращали внимание на изображение на плакате.
Покупатели не понимали, что нужно сканировать QR именно на плакате (сканировали ценник).
Игнорировали изображение плаката в онбординге, из-за этого не могли его найти.
Чтобы отсканировать плакат, нужно отойти от товара и найти плакат.
Консультанты, кстати, хорошо приняли данный сценарий. При этом, тоже были подводные камни, например, продавцы не знали, как поступить, если у плаката будут стоять сразу несколько человек.
Несмотря на наибольшее число шагов в сценарии, покупатели и консультанты определили вариант №2, как наиболее удобный и понятный. Именно его мы и взяли за основу при разработке новой функциональности клиентского приложения.
Приключения в «полях»
Полевые исследования зачастую сопровождаются всевозможными непредсказуемыми трудностями. Например, наша фича подразумевает участие, как минимум, двух человек - клиента и консультанта. Кроме того, в сценарии могут быть задействованы и другие участники, например, свободные консультанты, которые «нашли» клиента раньше, чем успел подойти вызванный консультант.
У нас есть чат-бот, который знает, какие сотрудники работают именно сегодня в конкретном магазине, и может отправлять информацию о том, что есть клиент, только им.
Мы имитировали работу этого чат-бота, собрав номера всех сотрудников магазина и отправляя им сообщение «вас ждет клиент в холодильниках» (условно), а как только кто-нибудь «принимал» (отвечал «беру»), отправляли всем остальным «вызов принят, отмена». Так мы смогли максимально приближенно к реальности протестировать весь флоу фичи.
В исследовании нам приходилось контролировать внешние факторы, такие как, «свободный консультант». Мы не могли исключить влияние данных факторов, поскольку в реальной жизни они имеют место.
Другие сложности: нам нужно было воспроизвести всю цепочку событий при использовании фичи. Клиент находит функциональность в приложении - формирует заявку - заявка падает в чат-бот консультанта - консультант замечает заявку - консультант принимает заявку - консультант ищет покупателя.
В авиакосмической отрасли, чем больше этапов «стыковки», тем выше риск провала. В нашем случае количество «стыковок» достигает пяти. При переходе между каждым этапом в исследовании был риск ошибки.
При формировании заявки исследователь должен был находиться рядом с респондентом, чтобы иметь возможность задавать вопросы по интерфейсу. Был вариант задать вопросы после исследования, но людям свойственно забывать, что побудило их совершить то или иное действие в моменте. Риск: консультанты в зале могли заметить исследователя с респондентом и запомнить последнего, что смажет результаты поиска «покупателя».
При отправке заявки в чат консультанта был риск потратить на подготовку и отправку сообщения слишком много времени, что повлияло бы на оценку затраченного времени.
В реальном сценарии подразумевается, что консультант может принять заявку, тогда она пропадает из общего чата, и другие консультанты уже не будут ее видеть. В нашем случае мы просили консультанта, принявшего заявку, написать в общий чат, что заявка уже принята.
Принятие заявки. В случае исследования консультанты менее замотивированы взять такую заявку, т.к. могут упустить настоящего клиента. Чтобы снизить влияние этого момента, мы платили консультантам гонорар респондента.
В реальной жизни поиск клиента может быть осложнен тем, что в магазине находится много людей, и консультант может не сразу понять, кто именно его вызвал (мы стремились упростить эту задачу, добавив поле комментария в заявку). В условиях исследования мы не могли заранее предсказать, когда в магазине будет много посетителей, т.к. волны клиентов приходили наплывами. В такие моменты мы стояли и высматривали, ходил ли рядом с нашим отделом кто-то из настоящих клиентов, и скрещивали пальцы, чтобы эти люди не уходили, и наш респондент мог затеряться среди них.
Самым сложным было собрать данные по работе консультантов. Нам предстояло выяснить, сколько времени прошло с момента получения заявки до того, как консультант заметит ее. И сколько времени проходит с момента «заметил заявку» до момента «начал искать клиента».
Поскольку мы не могли приставить исследователя к каждому консультанту (хотя такое желание у нас определенно было), нам приходилось оценивать эти моменты по косвенным признакам. Мы втихаря подглядывали за консультантами, но не могли точно знать, чем занимается консультант в смартфоне. К тому же, подглядывая за одним консультантом мы могли пропустить того, кто откликнулся на заявку.
Вершки и корешки
Еще несколько наблюдений. Люди готовы ждать помощи консультанта в среднем около пяти минут. Любопытное наблюдение, покупатели склонны субъективно преувеличивать время ожидания в среднем в два раза.
При этом, если помощь придет раньше отведенного времени, это значительно повышает вероятность повторного использования кнопки вызова консультанта (в среднем 8.6 из 10).
Сегодня компания все дальше уходит в OneRetail (что это такое, мы рассказывали ранее), поэтому онлайн-опыт взаимодействия покупателей с компанией трудно переоценить.
В настоящее время значительная часть усилий нашей команды разработки сконцентрирована на совершенствовании мобильных приложений и внутренних цифровых систем Группы. Мы стремительно оцифровываем все и вся.
Помимо вызова консультантов в магазине, компания считает важным развивать и исследовать пользовательский опыт (UX) в части покупки товара прямо у полки, без визита на кассу (если вы не знали, это уже работает в наших магазинах). Аналогично мы изучаем существующие сценарии покупок в нашем интернет-магазине.
Наша цель – сделать каждый контакт с М.Видео и Эльдорадо приятным, а процесс покупки простым и понятным. Конечно же, не обходится без курьезов, но, как говорится, дорогу осилит идущий!
P.S. В нашу команду по-прежнему нужны талантливые программисты. Больше актуальных вакансий по ссылке. Приходите, будет интересно.
