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

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

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

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

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

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

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

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

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

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

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

Чаще это происходит, когда объем ответственности каждой команды соответствует другим естественным структурам бизнеса, таким как каналы продаж, сегменты рынка или типы пользователей.

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

Вот несколько примеров такой согласованности:

• по типу пользователя или его имиджу (например, «команда гонщиков», «команда водителей»);

• сегменту рынка (например, «команда по электронике», «команда модельеров»);

• клиентскому пути (например, «команда по адаптации», «команда по удержанию персонала»);

• каналам продаж (например, «команда самообслуживания», «команда прямых продаж»);

• ключевым показателям эффективности бизнеса, KPI (например, «команда по привлечению новых пользователей», «команда по конверсии»);

• географическому положению (например, «команда Северо-Американского региона», «команда Азиатско-Тихоокеанского региона»).

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

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

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

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

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

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

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

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

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

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

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

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

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