Большинство компаний в один голос заявляют, что целью выпуска продукта на рынок является удовлетворение потребностей пользователей, а обратная связь от них – очень ценный источник информации для развития в будущем. Но для большинства пользователей звонок в службу поддержки – невыносимая мука и страдание.
При одной только мысли обратиться в службу поддержки воображение рисует 40 минут ожидания ответа оператора, а когда он попросит оставаться на линии, потому что “необходимо уточнить информацию”, кажется, что собеседник занят чем угодно, но только не анализом обращения. Даже если пользователь расскажет оператору о своей проблеме, он не верит, что сотрудник поддержки ответит не на автомате, используя заранее подготовленные скрипты, и уж тем более не верит, что его мнение хоть кому-то интересно. Очевидно, что такое отношение к службам поддержки сформировалось не на пустом месте.
Качество и результат общения со специалистом зависят, в первую очередь, от профессионализма оператора. Зачастую они не являются опытными пользователями продукта, не знают его настолько хорошо, чтобы понять, в чем заключается несоответствие возможностей продукта и ожиданий пользователя. Операторы часто используют скрипты, написанные для ответа на типовые обращения, даже если к обращению требуется индивидуальный подход.
Нельзя исключать и человеческий фактор. Некоторые пользователи позволяют себе излишнюю эмоциональность при общении с оператором, а сотрудники, в свою очередь, из-за усталости, невнимательности, нежелания уточнять детали проблемы, стараются как можно скорее завершить разговор.
Есть еще один важный фактор – у сотрудника может быть недостаточно информации для принятия правильного решения. Если оператор не видит всей картины происходящего, установить истинную причину возникновения проблемы пользователя практически невозможно.
Поэтому сегодня хочу рассказать о том, как важно иметь качественный инструмент для обработки обращений, особенно если разрабатываемый сайт или мобильное приложение является полноценным источником заказов с возможностью онлайн-оплаты. В этом случае принятие ошибочного решения при обработке обращений может принести заказчику существенные финансовые потери, а также оказать негативное влияние на лояльность клиентов к бренду. Понимая это, мы стараемся приступать к разработке сервиса обработки обращений как можно раньше и отразить в нем как можно больше информации, чтобы сотрудникам службы поддержки легче было разобраться в ситуации при получении обращения.
На одном из наших проектов сервис для обработки обращений пользователей появился при запуске самой первой версии приложения. Его функционал был сильно ограничен, так как задачей приложения было лишь информирование пользователей о продуктах и услугах заказчика. По мере развития проекта (в нем появилась возможность оформить заказ и оплатить его) сервис обработки обращений претерпел существенные изменения – теперь мы знаем о работе пользователей с нашим приложением практически все* – начиная от количества устройств, на которых оно установлено, и заканчивая историей покупок как в самом приложении, так и непосредственно в оффлайн магазинах. Именно это позволяет нам видеть полную картину происходящего с заказами пользователей.
Сервис хранит информацию, которую мы получаем в том числе из сторонних систем – систем оплаты заказов, кассовой системы магазинов и оператора фискальных данных. Поэтому по заказам, оформленным в приложении, мы можем рассказать причину проблем при оплате заказа, а не просто порекомендовать пользователю обратиться в банк.
Когда вы видите все, что происходит с заказом внутри приложения и за его пределами, каждую минуту в течение жизненного цикла заказа, риск ошибиться при принятии решения, существенно ниже.
Рассмотрим несколько примеров, как внимательное отношение к обратной связи позволило нам улучшить опыт взаимодействия пользователей с продуктом, а клиенту избежать невостребованных заказов.
История одного обращения
Пользователь написал нам следующее (орфография и пунктуация автора сохранены):
Добрый день! купил сегодня впервые через приложение, у меня за один заказ списали деньги два раза! прошу один чек вернуть, а именно N рублей, два чека есть, не могу приложить в связи с тем, что только один файл крепится.
… решил делать заказы через приложение … разобраться было не совсем легко и вот когда выбрал заказ, я нажал оплат Gpay ,Внимание! код приходил один раз, а списали деньги два раза,потом вылезло окно в приложении с присвоеным номером, и закрывать его не стоило, а значит ни о каком втором заказе я видеть и знать не мог, получив заказ, только час спустя я заметил ,что денег списало два раза за один товар, а выдали один((...
После получения обращения, мы запросили у пользователя скриншот экрана с историей заказов и второй чек для подтверждения оплаты обоих заказов.
Первое, что мы сделали, посмотрели информацию об этих заказах в нашей учетной системе, но ничего подозрительного, кроме разницы во времени оформления заказов, не нашли. Затем проверили логи взаимодействия с кассовой системой магазина и платежным шлюзом банка: оба заказа успешно прошли все этапы обработки.
Но ощущение, что здесь что-то не так, нас не покидало: функция повтора заказа в приложении отсутствует, при переходе к оплате корзина заказа автоматически очищается. Так как же пользователю удалось оформить два одинаковых заказа с разницей всего в 20 секунд?
Несколько участников нашей команды провели тест – попробовали собрать на время точно такую же корзину заказа, как и пользователь. Но даже у опытных тестировщиков это заняло гораздо больше времени, чем у пользователя. А ведь он написал, что оформлял заказ в приложении впервые.
Текст обращения тоже показался нам необычным: пользователь не просто требовал вернуть деньги, он старался как можно подробнее описать, что происходило в приложении в момент оформления заказа. Мы начали разбирать текст обращения по отдельным кусочкам, анализируя заново каждый этап обработки заказа.
Пользователь утверждал, что оплатил заказ с помощью Google Pay. Логи это подтвердили. Но почему код подтверждения оплаты пришел только один раз? Оказалось, что заказы были оплачены разными картами, к одной из которых была подключена функция дополнительной защиты (3D Secure), а к другой – нет. При отсутствии этой функции подтверждение оплаты (ввод пароля из смс) не требуется. С этим вопросом разобрались.
Далее, сопоставив номера заказов и карты, которыми они были оплачены, мы поняли, что пользователь получил только второй заказ, и именно он был оплачен картой с поддержкой 3D Secure. Но идей, как мог быть оформлен первый заказ, у нас, по-прежнему, не было.
Немного погодя мы решили проверить, не мог ли пользователь оформить заказы с двух телефонов параллельно. Но оказалось, что он использует приложение только на одном устройстве. Теперь мы решили обратиться к ОС, на которой работает устройство пользователя. Проведя ряд тестов, обнаружили, что при оплате картой без 3D Secure, пока приложение обращается к Google Pay за получением данных, необходимых для оплаты заказа, системная кнопка возврата к предыдущему экрану не блокируется. Значит, пользователь может вернуться на предыдущий шаг оформления заказа (то есть в корзину) и создать еще один заказ.
Теперь мы полностью разобрались в ситуации. Пользователю был оформлен возврат, а для приложения в кратчайшие сроки было выпущено обновление.
Другая история
При разработке приложения в процессе оформления заказа на самовывоз был предусмотрен отдельный шаг для дополнительного информирования пользователя о способе и времени получения заказа. Фактически мы запрашивали подтверждение готовности пользователя прийти в выбранный магазин.
В процессе разработки наша команда решила отказаться от этого шага. Показалось, что он необходим при оформлении только первого заказа. При оформлении второго и последующих пользователь будет обладать уже достаточным опытом, и этот шаг может вызывать у него раздражение.
После запуска мы начали получать следующие сообщения: часть пользователей оформляла заказ в магазин на другом конце города и отказывалась ехать за ним, другая часть, оформив заказ, ожидала курьера, думая, что заказ будет передан в доставку. Таких обращений было довольно много.
Мы не спешили возвращать экран, от которого отказались в ходе разработки, но задачу улучшения пользовательского опыта взяли в работу. Важно было не только помочь этим пользователям, но и не усложнить процесс оформления заказа для остальных.
Довольно быстро мы выпустили обновление: в процессе формирования корзины заказа с помощью специального информера внимание пользователя акцентировалось на адресе магазина, в который нужно прийти для получения заказа. Это позволило нам существенно сократить количество обращений подобного рода.
Вся команда понимала, что информер – временное решение, так как фактически он прерывает процесс сбора корзины, поэтому мы продолжили работать над задачей. Совсем недавно вышло очередное обновление, в котором нам удалось без добавления лишнего шага и без отвлечения пользователя от процесса формирования заказа, еще раз напомнить ему адрес магазина, в котором нужно забрать заказ самостоятельно.
История третья
Если ваш продукт является одним из множества каналов продаж, то обращения пользователей могут стать дополнительным источником информации о качестве работы других каналов, особенно оффлайновых. При получении негативного опыта люди гораздо охотнее пишут обращение в поддержку мобильного приложения, чем оставляют отзыв в книге жалоб и предложений в точке продажи.
Как-то мы получили обращение, в котором пользователь просил вернуть деньги за заказ, так как не смог найти вход в магазин. В тексте говорилось, что ТЦ, в котором он расположен, находится на ремонте. Сотрудник охраны у главного входа ТЦ сказал пользователю, что все магазины этого ТЦ закрыты.
Мы проверили время работы магазина в момент оформления заказа пользователем. Магазин был открыт – мы видели, что в это время в магазине совершали покупки непосредственно через кассовую систему, видели подтверждение получения заказов, ранее оформленных через приложение.
Подобные обращения являются поводом для информирования руководства магазинов и корректировки их операционной деятельности.
Заключение
Конечно, описанные выше примеры являются исключением. Такое пристальное внимание к обращениям со стороны команды разработки возможно и потому, что обработка обращений на проекте выполняется в 2 этапа:
- сначала обращения попадают в центр поддержки пользователей;
- если у сотрудников центра возникли сомнения в ходе обработки обращения, они передают его в команду разработки.
Но тем не менее рассмотренные примеры наглядно демонстрируют, что внимательное отношение к обратной связи от пользователей можно использовать для развития продукта, улучшения пользовательского опыта и даже повышения качества обслуживания гостей в оффлайновых точках продаж.
Если вы писали в службу поддержки какого-либо приложения, но не получили мгновенного ответа, это не значит, что его проигнорировали. Возможно, разработчики как раз сейчас готовят обновление, чтобы вам было удобнее и приятнее пользоваться продуктом.
Если у вас есть интересные истории, связанные с обращениями пользователей, напишите, пожалуйста, в комментариях.
* сбор информации осуществляется в соответствии с требованиями законодательства РФ.