Крупный банк РФ
2022-2024 / Продуктовый дизайнер
Внутренняя система банка для работы с данными юридических лиц.
Из сухого банковского требования собрал работающий продукт в связке
с аналитиком, продактом и методологами
Раньше: сотрудник менял данные клиента сам
Теперь: данные меняются только после согласования вторым сотрудником
Контекст и задача
В банке появилось новое правило: изменения данных клиента проходят через согласование вторым сотрудником
Данные юрлиц это основа всей работы банка с клиентом: кредитные решения, юридические вопросы, обслуживание. Если в данных есть ошибка или кто-то меняет их в личных интересах, банк теряет деньги. Согласование вторым сотрудником закрывает этот риск
Погружение в процесс
Готовых требований не было, сел собирать сценарий с нуля. Что должен видеть пользователь, какие у него развилки, что происходит при ошибках и отзывах
Параллельно обсуждал решения с продактом и аналитиком. Они подсказывали что технически реализуемо и какие данные есть на бэке. Готовые куски показывали методологам, чтобы сверить с юридической частью
Так и проектировал: решение → правки с командой → согласование с методологами
Создание заявки
Один дропдаун для редактирования и удаления
Форму создания оставил почти такой же, как в старом редактировании. Добавил поле с комментариеминициатор объясняет зачем меняются данные, согласующий не тратит время на уточнения
Просмотр изменений
Таблица с тремя колонками: атрибут, старое значение, новое. Строки где что-то поменялось подсвечены жёлтым
Паттерн универсальный и одинаково работает для банкротства, адресов, контактов и любых других данных
Принятие решения
Заявка построена на одном компоненте для обеих ролей. Согласующий видит дополнительный блок с выбором решения и комментарием
При отклонении и доработке комментарий становится обязательным. Инициатор сразу понимает, что исправить
Связанные организации
Некоторые клиенты связаны общим ИНН и изменения применяются ко всем сразу. Показываем список затронутых организаций и при создании заявки, и в самой заявке
Обе стороны понимают масштаб изменений до того как принять решение
Email-уведомления
Сотрудник работает в куче сервисов банка и про заявку легко забыть. Письмо на каждое событие помогает обеим сторонам быть в курсе и не терять заявки
История согласования
Каждое действие по заявке фиксируется: кто создал, кто отправил на доработку, кто отклонил и с каким комментарием. Весь путь заявки виден в одном месте
Список заявок
Отдельного раздела для заявок в требованиях не было. Стало понятно что без него процесс не работает: согласующий не знает что у него висит, инициатор
не видит статус своих заявок
Сделал отдельный раздел с двумя вкладками, фильтром по статусу и поиском по клиенту
Результаты
Продукт ушёл в прод. Решение для банкротства масштабировалось на все остальные типы данных клиента: адреса, контакты, реквизиты.
Получился универсальный сервис согласования изменений
