Всем хочется, чтобы после обращения в поддержку клиент был доволен, и пользовательский опыт в этой точке был приятным, а не раздражающим. Рассказываем, как обнаружить слабые места в 90% обращений за три недели на конкретном примере.
Рассказывает
Дарья Лошкарева
К нам обратился сервис доставки еды (не называем компанию по условиям договора). Проблема — на поддержку жалуются! На то, как они решают вопросы, как говорят, в каком стиле общаются с клиентами. Кроме того, у компании появилось ощущение, что и в самом продукте есть слабые места, которые вредят пользовательскому опыту. На их поиск нам дали три недели. И вот что мы делали.
Определили 5 тематик, которые совокупно составляют 90% обращений
Поскольку нашей задачей было найти проблемы, чтобы поддержка получала меньше жалоб, мы сфокусировались на самых частых причинах, по которым пользователи пишут в чат или звонят саппортам.
Другими словами, исправлять нужно то, что больше всего бесит. Эти данные собрать легко, если в компании есть хотя бы один аналитик или просто удобная система.
В нашем случае в топ-5 самых популярных проблем попали:
- опоздание курьера
- неполная комплектация
- качество еды
- вопросы, связанные с отменой заказа.
Для каждой компании в каждом конкретном случае выборка может быть разной. Например, помимо самых популярных тематик, стоит посмотреть на самые критичные случаи, которые ведут к потере клиента или на самые частые жалобы или низкие оценки.
Мы изучали два варианта:
- Как пользователь решает проблему сам, и какие барьеры у него возникают в приложении
- Насколько хорошо справляется поддержка в тех случаях, когда пользователь не смог решить вопрос самостоятельно
Исследовали, как пользователи пробуют решить проблемы в приложении самостоятельно
Прототип приложения — простейший аналог его интерфейса. Сделали его сами — в Figma. Мы показывали приложение пользователям и задавали вопросы, например, что они будут делать, если курьера нет уже 45 минут, хотя обещал быть через 15. Пользователи нажимали на кнопки в прототипе, делились впечатлениями. Мы оценивали их ответы. Этот способ оценки называется юзабили-тестирование.
Юзабилити-тестирование
— интервью с клиентами, на котором исследователь озвучивает проблемную ситуацию и предлагает пользователю с помощью прототипа приложения решить проблему
Мы просили озвучивать все мысли и действия, чтобы понимать, почему возникла заминка и какой была логика действий. Помогали наводящие вопросы: «Что вы ожидали увидеть на этом экране?» или «Почему нажали на эту кнопку?». Затем мы отмечали, справился ли тестируемый с задачей — то есть прошел ли по нашему сценарию.
После каждой проблемной тематики уточняли: «Считаете ли вы, что справились с задачей?». Если по сценарию задача решена, а человек считает, что не справился, то приложение не дает нужного фидбека и это необходимо исправить.
А кого спрашивать?
Количество респондентов зависит от масштаба вашего исследования и, конечно, времени. Мы торопились, поэтому опрашивали пользователей, которые делают заказ не реже одного раза в месяц. Это средний сценарий. В идеале чем больше пользователей вы опросите, тем больше будете знать об их проблемах.
Мы также показывали пользователям готовые варианты ответов поддержки с просьбой прокомментировать. Неожиданно, мы узнали, что пользователям не нужны подробные объяснения, почему возникла проблема и такие же детальные извинения. Пользователям неинтересно, почему курьер опоздывает и через сколько он все-таки доберется до покупателя — им нужна компенсация, промокод, который сгладит впечатление.
В результате у нас получилась таблица, из которой было понятно, в каких сценариях есть проблемы и на каком этапе.
Стали тайными покупателями
Поскольку мы и сами с усами, то есть часто заказываем еду домой, мы сделали заказы с помощью сервиса и зафиксировали все шероховатости, которые возникали в процессе формирования и ожидания заказа. Смотрели, конечно, с особым пристрастием. 3 недели
8 интервью-тестов с клиентами
4 теста тайных покупателей
300 ревью чатов и звонков
30 ревью отзывов в соцсетях
Конечно, никакой анкеты у нас не было, но мы фиксировали каждую итерацию с сервисом, даже мысленную. Выглядело это так. Мы сделали заказ. Ждем. Думаем, что ждем слишком долго — фиксируем мысли. Если возникали отрицательные эмоции (а они возникали, потому что холодную пиццу не любит никто), мы считали это барьером. В общем записывали мы не только наши действия, но и мысли.
В процессе мы также увидели, что некоторые плашки и кнопки в приложении плохо заметны. Не понравилось, что не приходят пуш-уведомления, если изменяется прогноз времени доставки. Но больше всего негатива вызывал отмененный заказ в ресторане, и если это происходит через 20-120 минут. После такого пользоваться сервисом нет больше никакого желания.
Важный момент: клиент пробовал проводить такое исследование самостоятельно, но из-за того, что тайными покупателями были обычные люди, у которых не было особой мотивации давать качественный развернутый ответ, они не понимали, на что обращать внимание в первую очередь. Вывод: полноценный фидбек могут дать эксперты в сервисе.
Изучили опыт взаимодействия пользователей с поддержкой, если самостоятельно решить проблему не получается
Наша гипотеза была в том, что дополнительные усилия со стороны пользователя — это angry-фактор. Это то, что разочаровывает в сервисе. Грубо говоря, степень разочарованности пользователей можно измерить с помощью количества усилий, который нужно приложить, чтобы решить проблему. Поэтому мы составили эталонные сценарии, а затем нашли возможные варианты развития события в 300 диалогах с пользователям, сравнили найденные решения с эталонными. Оценивали по главному показателю: сколько усилий тратит пользователь. Если дополнительных усилий со стороны пользователя ноль, значит сценарий эталонный. Если усилий много, значит сценарий проблемный, и здесь есть боль, которую нужно решать.
Что такое эталонный сценарий?
Это сценарий, в котором клиент тратит минимум усилий со своей стороны для того, чтобы решить проблему. Дополнительные усилия — это, например, общение с ботом, объяснение проблемы несколько раз, самостоятельный звонок в ресторан или курьеру, необходимость прислать поддержке фотографии или другие артефакты.
Эталонный сценарий решает проблему, и клиенту не приходится повторно обращаться в поддержку. В идеале вопрос решается меньше, чем за 10 минут, и у пользователя не возникает желание высказаться в соцсетях, чтобы навредить имиджу компании.
Для каждой тематики мы составили список возможных сценариев решения проблемы. Например, если курьер опаздывает, то саппорт может позвонить курьеру сам, дать телефон курьера клиенту, позвонить ресторану, чтобы узнать, как давно курьер от них ушел, дать промокод за долгое ожидание. В общем мы выяснили, что сценариев много, а главное, что каждый заказ сулит неопределенность: что будет в каждом конкретном случае, пользователь не знает.
Мы обнаружили, что поддержка слишком часто переадресовывает вопрос третьей стороне, вместо того, чтобы помочь клиенту. И самое печальное — половинчатые решения были по всем сценариям: оказалось, что поддержка не может предложить решение, которого ожидает клиент.
Что в итоге
На основе всех этих данных, мы составили для нашего заказчика список слабых мест, где пользовательский опыт в приложении неравномерный, где юзер спотыкается и испытывает трудности. Это подскажет команде, что можно изменить в продукте, чтобы сделать приложение удобнее для клиентов. Списков получилось два.
Один мы назвали Quick Win: это небольшие изменения, которые точно принесут пользу. Например, добавить пуш уведомления, что курьер задерживается — и вот уже нет негативных мыслей: “Почему мне в дверь никто не звонит”. Второй список Long Win— с проблемами, для решения которых нужно больше ресурсов, включая время.
