Все умеют переводить деньги. Почти никто не умеет объяснять отказ

Эта статья основана на собственной методике оценки мобильного банкинга, разработанной специально для данного исследования. В своей практике мы сталкивались с различными подходами и методологиями ведущих консалтинговых и исследовательских компаний (McKinsey, Deloitte, Markswebb). Взяв за основу лучшие практики, мы сформировали прикладную модель оценки, ориентированную не на формальное соответствие стандартам, а на реальный пользовательский опыт (ели очень захотелось посмотреть на модель то напиши скинем на нее ссылку).

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

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

Это не глобальный рейтинг и не попытка объявить победителя. Это сфокусированный срез европейского розничного банкинга с центром в польском рынке.

Мы не рассматривали приложения как витрину. В основе анализа — проверка одинаковых ключевых сценариев: вход и восстановление доступа, повседневные операции, цифровые сервисные задачи (например, открытие и управление продуктами), а также действия, связанные с безопасностью — лимиты, подтверждения, блокировки, повторная верификация и восстановление доступа.

После этого каждое приложение оценивалось по трём осям: UX, digital maturity и security UX. В рамках данной статьи основной акцент сделан на UX и security UX как на зонах, где проявляется наибольший разрыв между банками.

Логика метода близка к подходу McKinsey к customer journeys: оценивать не отдельные экраны или touchpoints, а сквозной путь клиента. Цифровой опыт рассматривается не по тому, как он начинается, а по тому, может ли пользователь пройти его до конца в цифровом канале.

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

Первый вывод выглядит даже немного скучным. И в этом его смысл.

В рамках исследования базовые платёжные сценарии практически перестали быть зоной конкуренции. Переводы, шаблоны операций и повторяемые платежи у всех банков реализованы на хорошем уровне. Поддержка Apple Pay и Google Pay стала стандартом, а не преимуществом.

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

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

Именно в этих моментах рынок начинает расходиться.

Если смотреть только на традиционные банки в выборке, средний уровень digital maturity составил 3,83 из 5. Средний показатель core UX — 3,67. При этом security UX оказался заметно ниже — 3,13.

Это важнее, чем кажется. Банки научились добавлять цифровые возможности быстрее, чем делать их понятными и безопасными для пользователя.

Наиболее слабые зоны показывают это особенно наглядно. Понятность причины блокировки получила в среднем 2,50. Понятность следующих шагов — 2,67. Контроль лимитов со стороны пользователя — также 2,67.

Это не проблема формулировок в интерфейсе. Это проблема доверия.

Когда действие блокируется без ясного объяснения, пользователь не чувствует себя защищённым — он чувствует потерю контроля. Когда следующий шаг сформулирован расплывчато, приложение перестаёт быть сервисом и начинает восприниматься как барьер. Когда лимиты, подтверждения или восстановление доступа невозможно удобно решить в самообслуживании, мобильный канал начинает выглядеть незавершённым.

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

Существует и другая проблема, которую банки часто маскируют словом digital.

Сценарий не становится по-настоящему цифровым только потому, что начинается в приложении. Пользователь оценивает его по тому, заканчивается ли он там же.

В рамках исследования у традиционных банков показатель полного онлайн-открытия продукта составил в среднем 3,00. Возможность завершить сценарий без визита в отделение — 3,17.

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

Проблема здесь не только в удобстве. Пользователь не разделяет дизайн интерфейса и реальную организацию сервиса. Если процесс начинается в приложении, но заканчивается фразой «обратитесь в поддержку» или «посетите отделение», весь путь воспринимается как неполноценный.

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

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

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

Ключевая проверка начинается в ситуациях сбоя: забытый пароль, отказ в операции, превышение лимита, невозможность завершить перевод, повторная верификация или восстановление доступа. То есть не в рамках happy path, а на recovery path.

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

В рамках исследования способность провести перевод end-to-end без перезапуска сценария составила в среднем 3,33. Способность корректно обработать ошибку без разрушения пользовательского потока — также 3,33.

Иными словами, в нормальном сценарии банки остаются сопоставимыми. Разрыв становится заметен тогда, когда что-то идёт не по плану.

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

Именно это формирует восприятие банка — не как набора функций, а как уровня контроля.

Слабый security UX — это не просто неудобство. Это прямые операционные и экономические потери.

Если приложение не объясняет причину отказа, пользователь обращается в поддержку. Если recovery запутан, сценарий обрывается. Если ключевые действия выносятся за пределы приложения, растёт cost-to-serve и одновременно снижается доверие к цифровому каналу.

В результате инвестиции в цифровой канал не конвертируются в эффективность.

Проблема не сводится к улучшению формулировок. Более понятные сценарии отказов снижают нагрузку на поддержку. Развитое самообслуживание удерживает больше операций внутри приложения. Качественный recovery снижает drop-off именно в тех точках, где пользователь наиболее чувствителен к негативному опыту.

При этом существует асимметрия восприятия. Успешные операции остаются незаметными. Непонятные отказы запоминаются и формируют общее отношение к банку.

Во-первых, объяснять отказы понятным языком: что произошло, почему это произошло и какие действия доступны пользователю дальше.

Во-вторых, переносить контроль в самообслуживание. Лимиты, доверенные устройства, активные сессии, способы подтверждения, настройки карт и восстановление доступа должны решаться внутри приложения в максимально возможном объёме.

Каждый вынужденный переход в контакт-центр или отделение — это индикатор недоверия самого банка к своему цифровому каналу.

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

Банки традиционно хорошо считают conversion. Значительно хуже — composure, то есть способность продукта сохранять ясность и управляемость в сложных ситуациях.

И именно composure становится ключевым качеством мобильного банкинга. Пользователю нужен не эффект и не новизна, а предсказуемость и контроль.

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

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

Именно здесь начинается реальное расслоение рынка.

В банковских сервисах понятность очень быстро начинает восприниматься как безопасность. А непонятность — как риск, даже если формально речь идёт о защите.

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

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

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

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

Tselikov Vladislav

Telegram: @vlad_ts

Viacheslav Kostin

Julia Strekalovskaya