2x быстрее одобрение займа
Время одобрения сократилось вдвое — от ручного процесса к связанному цифровому сценарию.
RxPay — часть экосистемы RxAll: финансовый продукт для оплаты лечения, лекарств и аптечных закупок на рынках, где традиционные банковские займы часто недоступны.
Система объединяла мобильное приложение и операционную платформу и проектировалась для реальных условий рынка: разного уровня цифровой и финансовой грамотности, недорогих Android-устройств, нестабильного интернета и процессов, в которых бумажные документы всё ещё оставались частью работы.
Пациенту может понадобиться лечение раньше, чем у него появится возможность его оплатить. Аптекам необходимо пополнять запасы лекарств, даже когда собственного оборотного капитала для следующей закупки недостаточно.
При этом традиционные банки могут отказывать в кредитовании людям и небольшим организациям, у которых нет достаточной финансовой истории.
RxPay был создан, чтобы закрыть этот разрыв.
Первоначальный процесс во многом строился на ручных проверках, физических документах и личном присутствии. Из-за этого одобрение займа занимало много времени, плохо отслеживалось и с трудом масштабировалось.
Нужно было превратить этот процесс в работающий финансовый продукт, не предполагая, что каждый пользователь уже знаком с цифровым банкингом или располагает современным устройством и стабильным интернетом.
RxAll / RXPay
HealthTech / FinTech
Африканские рынки
RXPay
Был разобран ручной кредитный процесс, типы пользователей, KYC, документы, платежи и ограничения локального рынка.
Была сформирована связанная система ролей, кредитных продуктов, заявок, состояний, платежей, документов и административных процессов.
Были спроектированы сценарии регистрации и KYC, выбора кредитного продукта, работы с лимитами, платежами и погашениями, историей операций и подтверждающими документами.
Были созданы UX/UI мобильного Android-продукта и операционного RXPay Admin, подготовлены интерфейсные тексты и выполнено сопровождение реализации.
RxPay проектировался не как последовательность отдельных мобильных экранов. В рабочем файле одновременно развивались ветвящиеся пользовательские сценарии, кредитные состояния, KYC, платежи и связанные операционные процессы.
Ниже — карта ключевых ветвей продукта. Она не перечисляет каждый экран, а сразу показывает, как роли, проверка, кредитные продукты, счёт и платежи складывались в одну систему.











Одного универсального интерфейса было недостаточно. RxPay должен был обслуживать три разные группы пользователей:
Каждая роль требовала собственного набора информации, документов, действий и финансовых сценариев, оставаясь при этом частью единой продуктовой экосистемы.
UX-архитектура строилась вокруг этих различий, а не пыталась провести всех пользователей через один универсальный процесс.








Регистрация включала подтверждение личности, контактные данные, финансовую информацию, сбор документов, проверку кредитоспособности и выбор кредитного продукта.
В обычном потребительском приложении очевидной UX-задачей могло бы стать удаление как можно большего количества шагов.
Здесь многие шаги были необходимы.
Прежде чем получить кредит, пользователь должен был понять, какие финансовые обязательства он принимает. Поэтому регистрация объединяла KYC и проверку документов с последовательным объяснением того, как работает займ.
Основные понятия раскрывались постепенно, а перед продолжением пользователь должен был пройти обязательную проверку понимания условий.
Цель состояла не в том, чтобы сделать регистрацию максимально короткой, а в том, чтобы необходимый и потенциально сложный процесс можно было безопасно понять и пройти.







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





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





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







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




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



Мобильное приложение было только пользовательской частью RxPay. Проверка заявок и документов, работа с пользователями, транзакциями, счетами и кредитными продуктами происходила в отдельном веб-интерфейсе.
RxPay Admin обслуживал разные роли — sales, compliance, credit, finance and operations, legal и collections. Команды согласовывали заявки, меняли кредитные лимиты, связывали пользователей с кредитными продуктами и отслеживали платёжную активность.



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




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