Привет! Я Даша Почекуева. Уже два года я работаю в Т-Банке лидом и дизайнером внутренних продуктов.
Внутренние продукты — это админки, CRM, системы аналитики, хитрые конструкторы: у крупных компаний множество полезных подкапотных систем с очень сложными задачами. Но говорят о них мало, и тренировать насмотренность негде.
Мы делимся опытом из закулисья, чтобы помочь коллегам и развивать индустрию. Сегодня вместе с UX-редактором Катей Дериглазовой в очередной раз продеремся через NDA-барьеры и расскажем про low-code-конструктор, который помогает нам обслуживать клиентов.
Статья будет полезна дизайнерам операционных сервисов и начинающим продактам.
Поехали ?
Обслуживание глазами клиента и оператора
Представим ситуацию. Клиент потерял карту и пишет в чат. Для него это выглядит как простой диалог с вопросами, ответами и инструкциями.
На стороне сотрудника банка, который разговаривает с клиентом, все намного сложнее. Он увидит нагруженный интерфейс.
Прежде чем ответить на вопрос, сотрудник должен проверить недавние события и внутрибанковские новости. Ему нужно держать перед глазами данные: имя, счет, карты, часовой пояс. А еще ему часто пишет много клиентов сразу. Не сойти с ума помогает правая часть экрана: поисковая строка, а под ней экранная форма с нужными данными — алгоритм для решения любой задачи. Все, что нужно сделать, — вбить ключевую фразу в поиск, и интерфейс подберет нужный алгоритм под обращение.
Такие алгоритмы мы называем процедурами. В нашем примере сотрудник открыл процедуру «Блокировка карты», выбрал нужную карту, и процедура ее заморозила. Осталось скопировать ответ в чат, и вопрос решен.
В общении с клиентом одной процедурой не обойдешься — нужна человечность. Тем не менее процедуры закрывают ключевую потребность — помогают быстро найти нужное решение, а затем адаптировать его под ситуацию. С каждым годом они становятся умнее и закрывают все больше обращений: помогают оформить карту, проконсультировать по маржинальной торговле, решить срочный вопрос с отменой рейса.
Если бы мы пытались отрисовать и разработать интерфейс под каждый кейс, нам потребовались бы продуктовые команды под каждый тип обращения. Как минимум дизайнер, который придумает сценарий, фронтендер, который сверстает форму, и бэкендер, который запрограммирует запросы в бэк. Это очень дорогой и неоптимальный путь.
Мы в Т-Банке поступили иначе и разработали собственный конструктор. Не нужно с нуля писать код и налаживать интеграции, чтобы собрать в нем простую процедуру под свои задачи.
Оранжевые блоки — это экраны, которые видит оператор, синие блоки — подкапотные запросы и проверки, зеленые — переходы к другим процедурам. Сотруднику не нужно искать в интерфейсе номер счета или проверять, заблокировалась ли карта: процедура сделает все автоматически.
Что особенного в наших процедурах
Если вы когда-нибудь работали с конструкторами для автоматизации, возможно, сейчас задаетесь вопросом: окей, а что в этом особенного? Достаточно вбить в поисковик no-code automatization software, и увидишь множество конструкторов, которые точно так же представляют бизнес-процессы в виде блок-схем, проводят подкапотные проверки и проводят пользователя за ручку через череду шагов. Не проще ли встроить какое-то из готовых решений, чем разрабатывать свое?
Поначалу это и правда было проще. Были времена, когда вместо разветвленных блок-схем собственной разработки мы использовали внешнее и уже готовое решение.
Сотрудник действовал по алгоритму с простой бинарной логикой и многое делал вручную. Например, рутинный процесс вроде открытия счета выглядел так:
Сотрудник консультировал клиента и шел по процедуре. На одном из шагов система требовала оформить заявку.
Не прерывая разговора, сотрудник переходил в стороннюю админку.
Вручную заполнял все поля, валидировал, отправлял.
Возвращался из админки в процедуру и переходил к следующему шагу.
Если система требовала еще каких-то заявок или проверок, повторял пункт 2, и так по кругу, пока процедура не подойдет к концу.
Для клиента это было долго, а для нас — дорого. Причем с каждым днем все дороже, ведь со временем клиентов становилось все больше, а вместе с ними и обращений. У Т-Банка исторически нет отделений, поэтому вся нагрузка не перераспределяется между офлайном и онлайном, а собирается только в онлайне.
Сотрудники, работающие в чатах и звонках, максимально загружены, их время — на вес золота. Стало ясно: мы не можем себе позволить такие длительные процессы, нужны интеграции между процедурами и админками. Для этого неизбежно пришлось перейти на внутреннюю разработку и сделать свой конструктор.
У сторонних решений всегда есть предел возможностей: не получится сделать так, чтобы процедура поддерживалась в десяти разных админках и мобильном приложении, удовлетворяла строгим принципам безопасности, адаптировалась под любой экран и под капотом ходила в сорок разных систем, да еще и присылала метрики и уведомления. А мы хотели, чтобы процедуры в Т-Банке умели все это делать.
В начале этого пути конструктор выглядел так:
А спустя несколько лет — так:
Если вы уже работали с системами моделирования вроде BPMN, то наверняка видите общие паттерны. В чем-то наши процедуры и правда похожи на BPMN-схемы: они тоже умеют делать проверки под капотом и обращаться во внутренние системы, имеют вшитые механизмы обработки ошибок и визуальное представление на графе. С таким конструктором сотрудникам уже не нужно самостоятельно ходить в разные админки и создавать там заявки: процедура делает это за них.
Сложность в том, что классические BPMN-движки диктуют асинхронное взаимодействие, а бизнес-процессы обслуживания клиентов в Т-Банке требуют движка диалогов в реальном времени. Клиента нужно обслуживать здесь и сейчас, и чем быстрее — тем лучше. Работая с процедурой, сотрудник не ждет асинхронных событий под капотом, а действует последовательно и быстро, двигаясь из точки А в точку Б.
Отсюда вытекают три ключевых требования к процедурам.
Стабильность работы. Каждая процедура должна работать быстро и предсказуемо, чтобы клиент не томился в ожидании, а банк не тратил лишние деньги на обслуживание.
Скорость внедрения изменений. Когда Центробанк меняет ставку, мы должны в тот же день внести изменения в бизнес-процесс, чтобы не дезинформировать клиентов и соблюдать регуляторные требования.
Масштабируемость. В конце 2022 года процедуры запускались 200 млн раз в месяц, а на момент написания этой статьи — 890 млн раз. Количество активных процедур за эти же два года выросло вдвое — с 26 до 50 тысяч. Процедуры должны выдерживать постоянный рост клиентской базы и количества обращений.
Принципы разработки конструктора
Достичь стабильности, быстрого изменения и масштабируемости нам помогают несколько принципов.
Не перегружать базу. Мы стараемся не хранить то, что не должны хранить. Например, ограничиваем время запуска процедуры и автоматически удаляем старые логи. Иногда это стесняет наши возможности: есть бизнес-линии, которым было бы удобно хранить информацию о логах как можно дольше и обращаться к ней год спустя. Но благодаря подобным ограничениям процедуры грузятся быстро.
Шаблонизировать все, что можно. Процедуры не пишутся с нуля — они собираются из готовых блоков: сообщений, форм, подкапотных проверок. Если процедура должна отправлять электронное письмо под капотом, создателю не нужно настраивать интеграцию с почтовыми клиентами — достаточно добавить блок с отправкой письма и указать в нем пару параметров.
Аналогичным образом работают интеграции с внутренними системами банка. Не нужен ресурс опытного разработчика, чтобы вывести в интерфейсе историю операций, доступные карты клиента и предыдущие заявки. С low-code-решением разберется технолог, прошедший обучение длительностью пару месяцев.
Оставаться в рамках low-code. Часто в нашей работе возникает соблазн сделать no-code-решение: пусть создатель процедуры добавит в нее небольшой блочок и настроит два параметра из выпадающего списка вместо того, чтобы писать код руками, — это же так удобно.
Не все функции можно комфортно превратить в no-code. Чтобы процедуры покрывали потребности большого числа бизнес-линий в банке, они должны быть гибкими и широко настраиваемыми: от кода не уйдешь, если нужно навернуть тестирование выражений или научиться вытягивать данные из массивов. Наш конструктор процедур умеет работать со сложными условиями видимости и функциями, в него можно встроить метаданные для ботов, есть мокирование данных и отдельные инструменты для тестирования и анализа — иными словами, это инструмент для визуального программирования, а не no-code-конструктор.
Наша задача — удерживать техническую сложность в рамках разумной: с одной стороны, подкачать инструмент полезными функциями, с другой — не повысить порог входа до критических значений.
Помнить о разных платформах. Процедура — это инструмент для разных задач, направлений и пользователей. Боты, обслуживающие клиентов, тоже ходят по сценариям, созданным в конструкторе. Часто тропинки подходят как человеку, так и роботу. Мы сами, как дизайнеры, пользуемся процедурами, например, чтобы завести задачу на исследователей.
Даже наши клиенты могут ходить по процедурам, не догадываясь об этом. К примеру, если клиент хочет заказать справку, для этого не нужен ни бот, ни сотрудник. Процедура берет все на себя и выгружает нужный документ.
Процедуры встраиваются в множество разных админок, на мобильную платформу, десктопную, на лендинги и в желтое приложение. В стратегическом видении на пять лет вперед мы бы хотели, чтобы процедуры запускались хоть на кофеварке в офисе. Это означает, что уже сейчас, продумывая архитектуру и инфраструктуру сервиса, мы должны закладываться на разные платформы.
Универсальность повышает стоимость разработки, но именно это — конкурентное преимущество процедур внутри Т-Банка: ни один другой инструмент автоматизации на рынке не предоставляет столь широкого покрытия.
Что дает конструктор процедур
Собственный конструктор процедур дает нам следующее.
Быстрое внедрение и изменение бизнес-процессов. Сейчас новый бизнес-процесс на процедурах в среднем запускается за 66 часов — то есть за 9,5 рабочих дней. Изменения в уже существующий процесс вносятся примерно за 14 часов. Цифры не идеально точные: мы еще работаем над методикой подсчета. Пока это время включает в себя и коммуникацию по задаче, и сборку процедуры, и тестирование с момента создания черновика до релиза. За счет улучшений конструктора показатель постоянно снижается.
Масштабируемость. При росте нагрузки мы можем оперативно подключить дополнительные ресурсы, оптимизировать базу и подготовиться к наплыву, поскольку не зависим от сторонних решений и отвечаем за стабильность самостоятельно. За последние четыре года клиентская база Т-Банка выросла с 10 млн клиентов до 40+ млн, и процедуры это выдержали.
Безопасность. Процедуры надежно защищены. Никакие клиентские данные не светятся там, где они не нужны, и тому, кому они не нужны.
Кроссплатформенность. У процедур есть универсальная оболочка, которая быстро встраивается в любое окружение — хоть в мобильное приложение для клиента, хоть в админку колл-центра, хоть в интерфейс представителя, доставляющего карту.
Шаблонизация. В процедуры уже вшиты типовые компоненты для разных случаев — кнопки, радиобаттоны, таблицы, галереи, селекты, — предсказуемо работающие на всех платформах, консистентные с остальным интерфейсом и знакомые сотруднику.
Обучение за три месяца. Конструктор требует от пользователей базовых технических знаний: умения написать простую функцию, собрать JSON и подставить в нужном месте тестовые данные, но не более того. Благодаря этому обучиться сборке процедур можно за 1—3 месяца.
Впрочем, нельзя сказать, что мы уже прошли весь путь и отточили работу до совершенства. Бизнес-процессы изменчивы, и конструктор каждый день должен под них подстраиваться. Решаешь один большой вызов — появляются следующие:
Как изменениями в конструкторе влиять на сами процедуры, их качество и метрики?
Как зарелизить большую фичу и не сломать уже созданные процедуры?
Как развивать функциональность конструктора так, чтобы он оставался доступным даже не разработчикам?
О том, как мы ищем ответы на эти вопросы, расскажем в следующий раз. Если интересно — задавайте вопросы и подписывайтесь на новый канал дизайнеров Т-Банка #ФФДД2Д. Все дизайн-новости быстрее всего публикуются там.