В один из рабочих дней в канал корпоративного мессенджера написал менеджер по работе с клиентами, что ему поступила обратная связь от пользователя:

В обсуждение проблемы тут же высадился десант компетентных сотрудников с информацией о том, что надо делать и как помочь пользователю, да и вобще разъяснить ситуацию между собой, что происходит. Тут и берет свое начало проблема, решение которой растянулось на несколько недель.

Ниже описан процесс того, как нам удалось принять решение увеличить конверсию и просто сделать жизнь пользователей удобнее а доход компании чуть больше.

Итак, все те компетентные люди, которые написали в обсуждение, как быть пользователю, конечно, дали важную информацию, но каждый раз в каждой конкретной ситуации расписывать жалующимся, что надо сделать, не есть хорошо. Более того, 2 из 10 пользователя если не 1 вобще не идут в поддержку. После такого большинство просто уходят с сайта. И это не говоря уже о том, что многие уходят еще до того, как попадут в корзину.

И вот в один из дней пришел СЕО с гипотезой, что у этой проблемы есть корни и сейчас мы теряем клиентов. Давайте проверим эту гипотезу и внесем фикс, который позволит нам улучшить пользовательский опыт и что не мало важно, конверсию. Сказано - сделано, погнали!

Мы устроили командный синк и детальнее погрузились в проблему. Что происходит ?

У пользователей при оплате в корзине возникают ошибки, которые указывают, что платежная система не приняла карту. Причем ошибка не информативна она пишет, что "система отклонила оплату". Разумеется, пользователь зол, он не понимает, почему это произошло, и просто уходит либо идет в службу поддержки, но это редко.

Мы поймали фокус на конкретном примере: пользователь из Казахстана хочет купить товар в России. То бишь пользователь, находясь физически Казахстане, на сайте меняет локацию и выбирает адрес доставки в России. Так как по id стояла локация КЗ, а значит и валюта его версии сайта отображалась в местной валюте - Тенге. После смены адреса доставки - Россия, у пользователя сменилась валюта с Тенге на Рубли.

Как правило механизм должен работать под капотом сервиса. И какую бы карту не ввел покупатель, сервис должен ее считать и по внутреннему курсу сделать списание средств и разумеется, покупатель не обращает внимание на смену валюты. Он уверен, что он сможет использовать свою Тенговую карту и по внутренней конвертации с него спишется нужная сумма заказа.

Пользователь вводит данные своей карты или она уже привязана в личном кабинете и кликает оплатить. И тут то происходит ошибка! Проблема в смене локации и присвоенной этой локации валюте и то, какая платежная система обсуживает эту валюту !

После того как он поймал ошибку, ему просто нужно проследовать в футер и сменить валюту на ту в которой у него карта ( если конечно у него нет рублевой ). Но мы же помним про принцип не заставляйте меня думать. Собственно по этому то мы и решили добавить улучшение. Так же кейс работает и в обратном направлении. Когда пользователь из России хочет что то купить в Казахстане, он так же хочет купить с помощью рублевой карты и вводит данные в валютную платежную систему, в результате чего происходит не состыковка карты и платежной системы пользователь ловит ошибку. Мы теряем клиента.

Мы определили, наиболее важные поинты в полученной информации, синхронизировались с аналитиком, как будем мерить результат до и после, что бы посмотреть на сколько мы улучшим результат и улучшим ли вобще.

Так как эта проблема в системе оплаты отображается как ошибка с определенным номером, по этому параметру мы сможем замерить результат нашей проделанной работы после внедрения фитчи, станет ли этих ошибок меньше и как скажется на конверсии.

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

Вариант 1
В обсуждении первого концепта мы пришли к тому, что пользователю в принципе не совсем важно, через какую валюту происходит конвертация на сайте. Он уже согласился с ценой и уже нажал оплатить. Ему нужно, что бы оплата прошла, а если и произошла ошибка, то под рукой должно быть быстрое решение. По этому первым концептом мы предложили выводить модельное окно с выбором карты в случае, если система оплаты и его исходная карта не совпали

Ретро
Мы провели юзабили тест на нескольких респондентах и выяснили, что все же покадить корзину переходом на другое окно не очень удобно. Небольшой стресс для пользователя и не желательные лишние действия. Тут итак куча лишних кликов в процессе оплаты, которых быть не должно. Поэтому мы пошли думать дальше.

Вариант 2
Вторым концептом мы учли ошибки первого и, как выяснили, проведя небольшой опрос, что людям все же важно видеть, какую валюту им необходимо выбирать. К тому же, как мы поняли ранее, выход из корзины на другое окно - лишний стресс для пользователя. По этому мы решили разместить кнопки выбора валюты прямо в корзине в момент ошибки оплаты.

К слову, когда мы прорабатывали юзер флоу, мы обсудили, что было бы вобще не плохо иметь возможность уведомлять пользователя в момент смены локации ( выбора адреса доставки ), что на данном адресе доставки в качестве оплаты допуcтимы такие то валюты. Но пока эта задачка ушла в бэкглог.

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

Вариант 3
В 3 концепте мы учли обратную связь прошлых вариантов и решили заменить мелкие радио батоны на обычные кнопки. При этом решили, что эти же кнопки будут некими свитчерами, которые быстро перезагрузят пользователю страницу и выведут ему ровно тут платежную систему, к которой подходит его карта.

Да, конечно, тут есть одно маленькое неудобство с тем, что все же данные карты придется вести заново, так как платежные системы не связанны между собой и, разумеется, данные не передаются

Третий концепт всех устроил и дал наиболее положительные результаты тестирования, после чего ушел в разработку. В процессе разработки мы так же столкнулись с проблемой, которая могла сломать все наши ранее наработанные результаты, а именно, мы уперлись в то, что платежная система не могла отдавать нам кастомный текст ошибки. У нее был свой дефолтный, и мы думали, что это нам все сломает. Но позже наши чудесные ребята с бэка и фронта объединились и смогли решить это проблему.

Спустя неделю после запуска апдейта мы получили первые позитивные новости. По количеству ошибок в платежной системе ошибок оплат стало сильно меньше. И так же платежная система отобразила данные, что конверсия на 1. 8 увеличилась. И это только первая неделя. Мы не раскатывали апдейт на остальные платежные системы. А так как у сервиса их 4 и везде была одинаковая проблема, то данный метод показал свою эфективнсть и мы ушли внедрять его на остальные.

О результатах внедрения я расскажу в слудующих постах, если этот пост покажет свою эффективность и это будет интерсно вам, посетителяпем моего сайта. А в завершение данного поста я бы хотел добавит скрины из чатика, которые были некой точкой в первом отрезаке большго сложного задания, которое на первый взгляд выглядело очень легко. Но в процессе мы провели довльно глубокий и сльный этап работы, благодаря которому мы можем приментть подобный подход на другие платежные системы.