Service Blueprint: как построить карту банковского сервиса?

Клиент видит только небольшую часть того, что на самом деле происходит в банке. В мобильном приложении он нажимает кнопку, заполняет заявку, получает уведомление или переводит деньги. Кажется, что все просто. Но за каждым таким действием стоят десятки процессов: проверки, интеграции, принятие решений, работа сотрудников, обмен данными между системами и внутренние регламенты. Как связать то, что видит клиент, с тем, что в этот момент происходит внутри банка? Для этого используют Service Blueprint - карту сервиса.

Service Blueprint - это визуальная модель сервиса. Она показывает действия клиента и точки взаимодействия с организацией, а также процессы внутри компании, которые это взаимодействие обеспечивают. В классическом варианте карта показывает связь между действиями клиента, видимыми процессами, внутренними процессами и системами поддержки.

Метод Service Blueprint предложила Линн Шостак в 1984 году. Изначальная идея заключалась в том, чтобы смотреть на обслуживание клиента не только с точки зрения внешнего взаимодействия, но и как на систему связанных между собой процессов.

В банке финансовый продукт редко задействует только одно подразделение. Допустим, клиент - юридическое лицо - оформляет депозит. В этом процессе одновременно участвуют система дистанционного банковского обслуживания, клиентский менеджер, внутренняя CRM, комплаенс и другие подразделения и системы. Клиент воспринимает все это как одну услугу: «я хочу открыть депозит». Но за этим простым действием стоит целая цепочка процессов. Service Blueprint позволяет разложить услугу на составляющие и увидеть, что происходит на каждом этапе: что делает клиент, с чем он взаимодействует и какие процессы внутри банка стоят за этим взаимодействием.

Service Blueprint часто сравнивают с Customer Journey Map (CJM). Оба инструмента используют при проектировании клиентского опыта. Но смотрят они на разные стороны одного и того же сервиса.

CJM показывает клиентский опыт: что делает пользователь, какие у него возникают потребности, барьеры и эмоции, с какими точками контакта он сталкивается.

Service Blueprint показывает, что стоит за этим опытом: какие процессы и сотрудники обеспечивают каждый этап клиентского пути и какие системы участвуют в его реализации.

Предположим, в CJM мобильного банка есть такой этап:

Клиент хочет перевести деньги другому человеку, открывает раздел переводов, вводит данные и подтверждает операцию.

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

Что происходит внутри банка в этот момент?

Две карты рассматривают один и тот же сервис с разных сторон. CJM показывает опыт клиента, а Service Blueprint связывает этот опыт с организационной и технологической системой, которая его формирует.

Классическая структура Service Blueprint состоит из пяти уровней.

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

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

Важно описывать не абстрактную «покупку продукта», а конкретный пользовательский сценарий.

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

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

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

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

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

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

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

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

В Service Blueprint можно также добавить:

Временные показатели. Они показывают, сколько времени занимает каждое действие, операция или процесс. Например, время одобрения кредитной заявки помогает определить, на каком этапе возникает задержка и что можно изменить в процессе.

Бизнес-правила и правила обслуживания. Они определяют, что можно изменить в процессе, а какие действия должны выполняться в соответствии с установленными требованиями. Сюда относятся правила безопасности, информационная политика, порядок работы и зоны ответственности сотрудников.

Эмоции. Как и в CJM, в Service Blueprint можно фиксировать эмоции сотрудников во время работы и взаимодействия с клиентами. По ним можно определить проблемы, которые влияют не только на взаимодействие с клиентами, но и на работу сотрудников.

Метрики и показатели. Они позволяют оценить операционную эффективность: сколько времени и ресурсов занимает процесс, где возникают потери и какие изменения могут их сократить.

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

Линия взаимодействия проходит между действиями клиента и действиями компании.

Линия видимости отделяет процессы, которые доступны клиенту, от процессов, происходящих внутри организации.

Линия внутреннего взаимодействия показывает границу между сотрудниками, непосредственно работающими с клиентом, и подразделениями, которые обеспечивают работу сервиса изнутри.

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

Далее пошагово разберем, как построить Service Blueprint для банковского процесса и использовать его в работе.

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

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

Service Blueprint лучше строить вместе с сотрудниками, которые участвуют в процессе с разных сторон:

Каждый участник привносит свою экспертизу и видит процесс со своей стороны.

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

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

Каждый такой шаг нужно зафиксировать отдельно.

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

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

Теперь нужно посмотреть, что происходит внутри банка за каждой точкой взаимодействия.

Клиент отправляет заявку на открытие счета. Что происходит дальше? Данные передаются в банковскую систему, выполняются проверки, информация может передаваться в службу безопасности, а в отдельных случаях заявка может попасть на ручную обработку.

Такие процессы нужно связать с соответствующими действиями клиента. Не забывайте и про время. Сколько клиент ждет ответа? Сколько занимает отдельная проверка? Где заявка может остановиться? На каком этапе возникает задержка?

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

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

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

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

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

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

Остальные детали можно добавить позже, если они понадобятся для анализа.

Еще одна ошибка - смотреть на процесс только со стороны внутренних операций и систем. Service Blueprint показывает не только то, что происходит внутри банка, но и клиентский опыт. Если клиент несколько минут ждет подтверждения платежа, не понимает его статус или получает непонятное сообщение об ошибке, это тоже должно отражаться на карте.

Не стоит создавать Service Blueprint в одиночку. Один сотрудник может хорошо знать клиентский путь, но не видеть процессов внутри ИТ, операционного блока, безопасности или других подразделений. Поэтому карту лучше строить вместе с участниками процесса. Каждый из них видит свою часть работы, а вместе они позволяют собрать процесс целиком.

Наконец, Service Blueprint не должна оставаться статичной схемой. В банке меняются процессы, системы, ответственность подразделений и точки взаимодействия с клиентом. Если карту не обновлять, со временем она перестанет отражать реальную работу сервиса.

Service Blueprint позволяет посмотреть на банковский сервис целиком - от действий клиента до внутренних процессов и систем, которые обеспечивают его работу. Клиент видит интерфейс приложения, сообщение об ошибке или статус заявки. За каждым таким взаимодействием могут стоять десятки операций, сотрудников и информационных систем. Карта сервиса связывает эти элементы и помогает увидеть, где именно возникает разрыв между тем, что должен получить клиент, и тем, как на самом деле работает сервис. Это помогает понять, где возникает проблема, что именно ее вызывает и какие изменения нужны для улучшения сервиса.
Вадим Врублевский
Финансовые технологии и инновации
vrubleuski.com