Как мигрировать 12 тысяч клиентов на новую версию интернет-банка. Делимся опытом из первых рук. На кону большие деньги

Вы создали классную новую платформу и она в сто раз лучше устаревшей. Дело за малым — осталось только перевести на неё клиентов.
И вот тут начинается самое интересное!

Как это сделать, сохранив и увеличив лояльность клиентов, не совершая при этом наших ошибок, рассказывает Роман Елисеев, Директор по цифровым проектам в Центре цифровых решений Корпоративного и инвестиционного бизнеса Росбанка.

Всем привет! Я с радостью расскажу вам про наш опыт – падения и успехи, профессиональную трагедию, и что я с этим делал.

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

Потом ты показал товар лицом (которое сияло до блеска): провёл несколько внутренних демо для коллег по цеху, написал новость на внутреннем новостном портале, презентовал на всех уровнях, в общем, заработал лайки в карьерную карму.

Клиенты из твоего пилотного проекта довольны, ты получил от них благодарные отзывы, с кем-то даже подружился и наладил общение... Ты купаешься в лучиках славы. Собой ты доволен: биг джоб из дан, и у тебя заслуженная награда!

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

Когда начнется миграция со старой платформы на новую, то точно будут комментарии вида:

Сейчас придётся посвящать этому много времени, завязнешь, появятся многочисленные вопросы внутри банка: от клиентских менеджеров (которым до этого тоже «спокойно жилось»), куча переписок и разъяснений, списков в экселях и огромных цепочек в переписке.

Такая реакция на изменения -- это нормально и в природе вещей. Но работа с ней всегда требует огромного количества времени и терпения, это довольно однообразно. Это всегда рутина.

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

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

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

Знаете на какой мысли я поймал себя в этот раз?
А вот на такой: «Я этим заниматься не буду и точка!!!»

Но по факту проект прилетел именно мне. Надо за него браться, подумал я, решив что это знак судьбы :)

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

Начало было неплохим, дали доступ к новой платформе и 10% клиентской базы в режиме параллельного использования (то есть с сохранением доступа к старой системе), собирали обратную связь и быстро исправляли косяки.

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

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

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

Маленький тизер: я втянулся и сейчас рад, что взялся.

Что самое главное, что тревожит пользователя-клиента при изменениях системы «банк-клиент для юридических лиц»?

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

Часто пользователи удовлетворяются традиционным набором – стабильно, не бесит, отправляет деньги, отдает выписки. В случае изменений главный страх пользователя – «я не смогу сделать свою работу, не смогу найти кнопку, новая система принесет новые ошибки, она будет дольше обрабатывать документы» – в общем всё то, что каждый банк, затевая переезд, стремится исключить. У нас пользователем как правило является наёмный сотрудник компании-клиента.

Меньше всего он хочет, чтоб из-за банковских программистов он не выполнил задачи своего руководства.

Задача: Все клиенты-юрлица должны быть аккуратно переведены из старого интернет-банка в новый.

Вводные:

Будет просто фантастически, если в вашей новой платформе готово всё до самых мелочей. Но на практике это не так.

По факту мы начали мигрировать клиентов, когда у нас было готово лишь 30% всех продуктов и разделов (то есть очевидно 70% - не готово). Да-да, сюрприз, мир продуктовой разработки несовершенен, но в этом нет ничего страшного. Всё не появляется сразу.

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

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

Итак, самое важное на первом шаге - определить продуктовый профиль своего клиента через базовые и дополнительные продуктовые атрибуты.

Базовые продуктовые атрибуты:

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

Например, в крупном разделе «Обмен валюты» у нас было три мелких раздела: «Покупка», «Продажа» и ещё отдельный модуль по торговле на открытом рынке. В итоге набралось около 30 таких продуктовых атрибутов.

Один атрибут соответствовал мелкому продуктовому разделу. Гранулярность зависит от готовности ваших крупных разделов к миграции. Если крупный раздел готов целиком, то вы счастливчик и берёте его за основу. Как вы понимаете, нам так не повезло. Крупные разделы не были готовы целиком и их пришлось дробить сильнее, а затем работать с мелкими.

Дополнительные атрибуты:

Помимо готовых / неготовых продуктов в банк-клиенте на работу пользователя влияют ещё несколько важных факторов:

На всё про всё в итоге набралось около 40 атрибутов: продуктовых и дополнительных. Часть из них мы определили сразу, а часть приросла по мере процесса миграции. Но опять же, чем лучше подумаете в начале пути - тем проще будет сам путь.

В конце этого шага появляется таблица, где у каждого вашего клиента есть профиль с N атрибутами. В нашем случае N равнялось 40.

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

Дельный совет - чем вы меньше поленитесь на этом этапе, тем дальше будет проще.

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

Для того, чтобы не мигрировать всех сразу, клиентскую базу обычно делят на волны, а затем волна за волной начинают переносить. Зачем вообще это делать?

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

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

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

Деление на волны - это проверенная классика. Мы велосипеда не изобретали, поступив ровно так же.

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

Недели две всё это составляли. Но в пользовании было очень удобно. Вот так это выглядело у нас. Страниц 20 в Confluence:

Далее в программе: