Витрина сделала свою работу – и исчерпала себя
Десять лет цифровой банкинг развивался как витрина. В приложение перенесли все, что раньше происходило у стойки отделения: счета, вклады, кредиты, справки – каждый продукт получил собственный раздел. Метрикой успеха было покрытие: сколько операций доступно дистанционно, сколько разделов есть в меню, сколько продуктов можно оформить, не приходя в офис.
Эта логика себя оправдала: сегодня клиент почти не заходит в отделение, а мобильное приложение стало основным лицом банка. Но когда витрина достроена, она перестает быть преимуществом. Все участники рынка пришли примерно к одному набору разделов, схожим тарифам – а значит, теперь выбор клиента определяется тем, насколько легко банк помогает решить конкретную задачу.
Задача клиента никогда не формулируется в терминах банковских продуктов. Человек не хочет «оформить ипотечный продукт с аннуитетным графиком» – он хочет переехать в новую квартиру до сентября, чтобы ребенок пошел в школу рядом с домом. Предприниматель не хочет «открыть расчетный счет и подключить эквайринг» – он хочет начать продавать. Финансовый директор не хочет «получить услугу банковского сопровождения контракта» – он хочет пройти проверку по госконтракту без замечаний.
Раньше зазор между тем, как думает клиент, и тем, какие услуги предлагает банк, закрывал сотрудник отделения. В цифровом канале его не закрывает никто – клиент остается один с каталогом и вынужден самостоятельно собирать из продуктов решение своей ситуации.
Продуктовая VS ситуационная логика
Жизненная ситуация – это событие или период в жизни клиента, который порождает связанную цепочку финансовых и нефинансовых задач. Рождение ребенка, переезд, покупка автомобиля, выход на пенсию, поездка за границу, потеря работы, наследство, развод. Для бизнеса – регистрация компании, прием первого сотрудника, выход на маркетплейс, участие в тендере, налоговый период, кассовый разрыв, проверка контрагента, смена директора.
| Продуктовая логика | Ситуационная логика |
|---|---|
| Клиент планирует покупку квартиры. Он заходит в раздел «Ипотека», считает платеж в калькуляторе, отправляет заявку. Страхование он ищет в другом разделе. Про справку о доходах вспоминает, когда ее запрашивает застройщик. Про перевод коммунальных платежей и переоформление автоплатежей – уже после переезда, когда придет первая пеня. Каждый шаг он инициирует сам, каждый раз заново объясняя банку контекст, который банк и так должен знать. | Клиент отмечает цель «покупка жилья». Банк собирает вокруг нее маршрут: оценка бюджета по реальной истории доходов и расходов, накопительный счет под первоначальный взнос с автопополнением, предодобренный лимит, пакет документов, сформированный без запроса справок, страхование, аккредитив или эскроу, чек-лист сделки, а после переезда – перенос автоплатежей на новый адрес и напоминание о налоговом вычете в следующем году. Продукты те же, но теперь вместо карточки в каталоге маршрут клиента от намерения до результата. |
Ключевой сдвиг здесь – управленческий, а не интерфейсный. В продуктовой модели банк оптимизирует конверсию в продукт. В ситуационной – время и число усилий, которые клиенту нужны, чтобы дойти до результата. Это разные KPI, и они по-разному расставляют приоритеты в бэклоге.
Архитектура сервиса жизненных ситуаций: пять слоев
Практика показывает, что работающая модель, основанная на ситуационной логике, состоит из пяти слоев.
-
Данные и триггеры. Ситуацию нужно распознать раньше, чем клиент придет с вопросом. Сигналы уже есть в банке: изменение структуры платежей, появление детских товаров в транзакциях, регулярные переводы в другой регион, кассовый разрыв, который просматривается на две недели вперед. Триггеры позволяют оценить, с какими проблемами сталкивается клиент, и какой продукт ему нужен. Разница между двумя подходами быстро становится очевидной клиенту, и она определяет, будет ли он доверять подсказкам банка.
-
Сценарий и оркестрация. Ситуация – это связанная последовательность шагов с состоянием, ветвлениями и сроками. Значит, нужен слой, который хранит прогресс клиента по маршруту, знает, какой шаг следующий, какие документы уже собраны, какие согласия получены, и умеет вызывать нужные продуктовые сервисы в правильном порядке. Именно поэтому переход к ситуационной модели практически невозможен на монолитной системе: сценарий должен собираться из независимых сервисов, а не переписываться внутри одного большого приложения при каждом изменении.
-
Каналы и омниканальность. Клиент начинает маршрут в мобильном приложении, продолжает в веб-версии на большом экране, задает уточняющий вопрос в чате, звонит в контакт-центр. Ситуационный сервис имеет смысл только тогда, когда контекст переходит между каналами без потерь: оператор видит, на каком шаге маршрута клиент остановился, чат-бот не спрашивает того, что уже известно, а голосовой ассистент способен продолжить незавершенное действие. Разорванный контекст обнуляет весь эффект – клиент воспринимает такой сервис как навязчивый, а не как помогающий.
-
Партнерская обвязка. Большая часть жизненной ситуации лежит за границами банковской лицензии. Переезд – это риелтор, оценщик, и управляющая компания. Открытие бизнеса – онлайн-касса и бухгалтерия. Банк, который берет на себя роль сборщика этого маршрута, имеет больший контакт с клиентом, чем банк, продающий один продукт из цепочки. Экономика здесь тоже иная: стоимость привлечения распределяется сразу на несколько продуктовых вертикалей, а частота взаимодействия с клиентом вырастает на порядок, продлевая жизненный цикл отношений.
-
Метрики. Ситуационную модель нельзя измерять продуктовыми KPI – они будут показывать провал там, где есть успех. Работающий набор метрик: доля ситуаций, доведенных до результата; время от триггера до завершения; число обращений в контакт-центр на один маршрут; доля вопросов, решенных в цифровом канале без звонка; количество продуктов на клиента, полученных внутри сценария; NPS по ситуации, а не по банку в целом.
Сервис жизненных ситуаций для разных сегментов
Розница. Кроме покупки жилья, сценарии с наибольшей отдачей для бизнеса включают в себя рождение ребенка (пособия, выплаты, накопительная цель, страхование), поездку за границу (лимиты, уведомление о выезде, связь с банком в другой стране) или большие перемены (потеря дохода, реструктуризация, кредитные каникулы). Отдельный сценарий, который недооценивают, – когда что-то пошло не так: спорная операция, подозрение на мошенничество, блокировка. Именно в этих ситуациях клиент решает, останется ли он в банке.
Малый бизнес. Здесь ситуационная модель дает максимальный эффект, потому что у индивидуального предпринимателя нет ни финансового департамента, ни юриста. Сценарий «начинаю бизнес» – регистрация, счет, касса, эквайринг, первый сотрудник, выбор налогового режима, включая автоматизированную упрощенную систему налогообложения, где банк становится техническим оператором расчета налога. Сценарий «управляю деньгами» – понятная аналитика: динамика выручки, изменение среднего чека, просроченные оплаты, приближение обязательных платежей. Ценность здесь в том, что предприниматель видит проблему до того, как она становится критической. Сценарий «расту» – кредитная линия под оборот, факторинг, зарплатный проект, выход на маркетплейс.
Крупный бизнес и корпорации. Ситуации более масштабные и стандартизированные: сопровождение контракта, работа с отдельными счетами, интеграция расчетов в учетную систему по схеме host-to-host, управление ликвидностью группы, комплаенс-проверки, взаимодействие с регулятором. Логика та же – банк ведет клиента по регламентированному маршруту, снимая с него часть контрольной функции.
Что нужно перестроить внутри банка
Технологии здесь – не самая сложная часть: организация – гораздо сложнее.
Владелец ситуации вместо владельца продукта. Пока ответственность нарезана по продуктам, сквозной маршрут не соберется: у каждого продуктового владельца свой план и свои метрики, а ситуация проходит через все. Нужна роль с мандатом на сквозной результат и с правом требовать доработок у продуктовых команд.
Пересборка бэклога вокруг сценариев. Не «улучшить экран вклада», а «сократить путь клиента в сценарии переезда с 14 шагов до 5». Это меняет то, какие задачи вообще попадают в приоритет.
Модульная платформа и скорость изменений. Сценарии живут недолго: меняется регулирование, появляются новые госсервисы, меняется поведение клиентов. Значит, критична не функциональность на момент запуска, а стоимость и скорость следующего изменения. Микросервисная архитектура, готовые компоненты каналов, конструктор сценариев вместо кастомной разработки под каждый кейс.
Разгрузка контакт-центра как эффект, а не как цель. Когда клиент решает задачу в цифровом канале, обращений становится меньше, а те, что остаются, сложнее и требуют компетенции. Речевая аналитика на массиве этих обращений – самый честный источник понимания того, где ситуационный маршрут рвется.
С чего начать: практическая последовательность
-
Выберите ситуации, которые сможете «закрыть». Критерии: массовость, высокая частота обращений в контакт-центр, наличие нескольких продуктов внутри цепочки.
-
Опишите маршрут «как есть». Пройдите его сами, как клиент, и посчитайте шаги, документы, повторные вводы данных, переходы между каналами. Цифра почти всегда оказывается неприятной – и именно она становится базовой линией.
-
Найдите триггер. Определите, по какому сигналу в данных банк узнает о ситуации и в какой момент уместно предложить помощь.
-
Соберите пилот на существующих продуктах. Ситуационный сервис не требует новых продуктов – он требует новой сборки имеющихся.
-
Зафиксируйте метрики до запуска. Время до результата, число шагов, доля завершенных маршрутов, обращения на маршрут. Без базовой линии эффект будет невозможно доказать, а значит – невозможно масштабировать.
Витрина остается, но перестает быть главной
Речь не о том, чтобы убрать каталог продуктов. Клиенту, который точно знает, чего хочет, витрина нужна – быстрый доступ к переводу, вкладу, выписке. Речь о смене приоритета: витрина становится служебным слоем, а верхним уровнем взаимодействия – сценарии, которые говорят с клиентом на языке его задач.
Банки, которые сделают этот переход первыми, получат не столько технологическое, сколько поведенческое преимущество. Клиент привыкает к тому, кто снимает с него сложность, а не к тому, у кого на полке больше товаров. И такой результат гораздо труднее скопировать конкурентам, чем тарифную сетку или дизайн приложения.
