Главный сценарий вкладки занимал меньшую часть интерфейса
Поддержка выросла внутри Тинькофф Мессенджера. В одной вкладке одновременно находились чат поддержки, маркетинговые боты, P2P-диалоги, представители, персональный менеджер и обращения второй линии.
Со временем поведение клиентов и устройство продукта разошлись.
71% пользователей вкладки открывали диалог поддержки. 65% приходили прочитать сообщение от поддержки. Поиск внутри поддержки использовали 31%.
При этом в среднестатистической сессии около 75% экрана занимали маркетинговые и P2P-диалоги — сценарии, которыми пользовались соответственно 7,8% и 1,6% месячной аудитории мобильного банка.
Мы фактически оптимизировали интерфейс вокруг устройства мессенджера, хотя его основной задачей уже стало получение помощи.
Нам нужно было одновременно уменьшить усилия клиента и стоимость обслуживания
В стратегии Центра поддержки была простая целевая модель:
Клиент закрывает проблему с минимумом усилий в удобном для себя формате.
Это не означало сделать чат максимально заметным и направлять всех туда.
Для одной проблемы быстрее позвонить. Для другой удобнее написать и приложить документы. Часть вопросов можно решить без сотрудника вообще. А если нужен человек, качество и стоимость зависят от того, кто и в каком канале подключается: бот, первая линия, профильный сотрудник или представитель.
Поэтому хороший Центр поддержки должен был одновременно быть:
- удобным — позволять использовать подходящий человеку канал;
- простым — показывать только актуальные действия;
- информативным — объяснять, что происходит с проблемой;
- доступным — давать цифровой опыт помощи не хуже офлайн-офиса.
Для бизнеса работала обратная сторона той же модели. Чем меньше коммуникаций требуется для решения вопроса, чем меньше времени сотрудника они занимают и чем больше вопросов клиент способен закрыть самостоятельно, тем дешевле обслуживание.
Получалось важное ограничение проекта:
Снижать стоимость поддержки, не перекладывая эту экономию в дополнительные усилия клиента.
Качество при этом нельзя было ухудшать: CSAT должен был оставаться высоким, SLA каналов — не расти, а нагрузка на персональных менеджеров высокодоходных клиентов — не увеличиваться.
Два исходных решения сохраняли старую продуктовую рамку
Когда в июле 2024 года появилась рабочая группа по Центру поддержки, обсуждались два направления.
Первое сохраняло мессенджер, но делало поддержку внутри него заметнее.
Второе превращало вход в поддержку в разводящую страницу с категориями, готовыми ответами и несколькими каналами.
Я не поддержал ни одну модель.
Они выглядели по-разному, но требовали от клиента одного и того же: сначала понять структуру сервиса и выбрать правильный путь, а уже потом начать решать проблему.
К этому моменту я больше двух лет развивал сам мессенджер. Поэтому смена рамки означала отказаться в том числе от продолжения продукта, который я сам помогал строить.
Основной вопрос для дизайна стал другим:
Зачем вообще заставлять клиента выбирать чат или подразделение, если он пришёл сюда за помощью?
Я предложил третью модель — начать с проблемы, а не со структуры банка
Исследование подтверждало, что поддержка была главным сценарием вкладки. Но оно не говорило, что правильным решением обязательно будет один диалог.
Это была дизайн-гипотеза.
Я собрал альтернативный концепт, в котором клиент попадал не в список сущностей и не в каталог помощи, а сразу в основной диалог поддержки.
Он мог просто сформулировать проблему.
Звонок, представитель, персональный менеджер и уже созданные обращения не исчезали — они появлялись рядом в подходящем контексте.
Автоматизация тоже оставалась внутри сценария. Бот мог решить вопрос самостоятельно или направить его дальше, но не должен был становиться обязательным барьером на пути к человеку.
Около 80% первой концепции я спроектировал сам. С ней мы прошли несколько раундов обсуждений с рабочей группой и бизнесом. После каждой встречи уточняли модель и возвращались с новой итерацией.
Спорить о вкусе было бесполезно, поэтому я защищал концепт метрикой, за которую бизнес отвечал сам. Целевой была не заметность чата, а усилия клиента. Разводящая с категориями добавляла шаг перед решением проблемы, а один диалог его убирал — то есть простая модель попадала в бизнес-цель точнее, чем обе исходные, и одновременно давала лучший опыт.
Защищать концепт пришлось на серии непростых встреч с бизнесом обслуживания, интерфейсов банка и командой дизайна. В итоге третий вариант приняли за основу Центра поддержки.
Один диалог оказался только началом
Если строить продукт вокруг проблемы клиента, недостаточно поменять главный экран.
Нужно было пересобрать весь путь — от момента, когда клиент понял, что ему нужна помощь, до момента, когда проблема решена.
Помочь выбрать наиболее эффективный путь
Чат и звонок появились рядом.
Клиент мог использовать тот формат, который удобнее именно для его ситуации, а сервис — переводить его в канал, где вопрос решается быстрее или качественнее.
На входе Топ-1-подсказка показывала наиболее вероятный вопрос и помогала сразу начать решение.
Не заставлять клиента понимать внутреннее устройство поддержки
Бот, первая линия и профильная команда могут быть разными частями операционного процесса. Для клиента это одна проблема.
Передачи между ними должны происходить внутри сервиса, а не превращаться в необходимость искать новый чат или заново объяснять контекст.
Показывать, что происходит после обращения
Если вопрос нельзя решить сразу и он уходил на вторую линию, клиент видел дорожную карту: текущий этап, статус и объяснение происходящего.
До её появления вопросы «когда решите?» и «можно ли быстрее?» создавали около 100 тысяч повторных коммуникаций в месяц.
В отдельном эксперименте дорожная карта снизила их примерно на 8% при плане 3,8%, а экономия оказалась на 60% выше ожидаемой.
ОТДЕЛЬНАЯ ИСТОРИЯ — ГОЛОСОВЫЕ СООБЩЕНИЯ
Голосовые сообщения появились как отдельная функция мессенджера. Для клиента это был естественный способ общения, но у функции не было очевидного прямого бизнес-эффекта, поэтому её запуск больше года не удавалось согласовать.
В какой-то момент я взял переговоры на себя, свёл позиции нескольких CPO и лично довёл договорённость до запуска. Это не центральная линия Центра поддержки, но важная часть моей роли: готовое интерфейсное решение стало продуктом только после того, как я сам провёл его через конфликт интересов.
Маркетинг превратил сервисный канал в источник раздражения
В старой вкладке маркетинговые боты находились рядом с поддержкой, а рекламные предложения могли появляться прямо внутри сервисной переписки.
Для отдельных направлений это был эффективный канал коммуникации и продаж. Для клиента граница между помощью и продвижением практически исчезла: в том же пространстве, где он ждал решения проблемы, банк продолжал присылать предложения.
Клиенты регулярно жаловались на рекламу в чатах. Количество и повторяемость таких отзывов показывали, что дело не в отдельных неудачных сообщениях — была нарушена сама граница сервисного канала.
Поддержку пришлось отделить от коммуникаций самого банка
Вместе с продуктом мы зафиксировали принцип:
Сервисный канал не должен конкурировать с другими коммуникациями банка за внимание клиента.
Для «чистой поддержки» нужно было изменить два уровня: убрать посторонние диалоги из пространства помощи и перестать использовать основной чат как канал нерелевантных обращению исходящих сообщений.
Это было не решение «убрать маркетинг», а разделение разных пользовательских намерений. Коммуникации банка сохраняли свою ценность, но больше не должны были маскироваться под помощь или мешать клиенту продолжить сервисный сценарий.
Моя роль была в том, чтобы закрепить эту границу в концепции и защищать её со стороны клиентского опыта.
Эта миграция не закончена. С августа 2026 года целевая модель работает на части аудитории, а переговоры о переносе оставшихся маркетинговых коммуникаций продолжаются. Изменение затрагивает много продуктовых команд, бизнес-процессов и значимый для банка канал, поэтому «чистая поддержка» здесь — не завершённая победа, а уже запущенный переход, который команда продолжает доводить до конца.
Единый принцип не означал одинаковый интерфейс для всех
Первую модель мы проектировали для массового сегмента, где общий чат поддержки был естественным основным входом.
Для Premium и Private ситуация отличалась.
Там персональный менеджер был самостоятельной частью ценности продукта с CSAT около 4,9 из 5.
При этом он не круглосуточный канал, а живой человек с рабочим днём и выходными. Многие клиенты выстраивают с ним близкие отношения и обсуждают то, что не должно смешиваться с общей перепиской поддержки. Схлопнуть его и поддержку в один диалог означало бы одновременно потерять приватность этого разговора и оставить клиента без понятного входа в помощь вне его графика.
Поэтому мы сохранили общий принцип — быстрый и понятный доступ к помощи, — но отказались от требования одинаково реализовать его во всех сегментах.
В Mass основным стал один диалог. В Premium и Private осталось несколько сервисных сущностей, но посторонние сценарии перестали определять структуру поддержки.
Эксперимент должен был проверить главный компромисс проекта
В апреле 2025 года мы запустили новый опыт в массовом сегменте.
В контроль и тест распределили 1,74 млн клиентов поровну. Два месяца набирали участников и ещё месяц наблюдали результат.
Нас интересовал не вопрос «стал ли новый экран лучше».
Мы хотели понять, сможем ли сделать получение помощи проще, не ухудшив при этом качество и экономику обслуживания.
Ответ пришёл не такой, какого мы ждали.
Каждое отдельное обращение стало эффективнее. Но обращаться начали чаще
На уровне одной коммуникации модель работала в ожидаемую сторону: усилия клиента снизились на 1,85%, время сотрудника на один чат — на 1,71%, а автоматизация чатов выросла на 1,68%.
Но Центр поддержки одновременно сделал помощь заметнее и проще для начала. Чатов на одного клиента стало на 9,59% больше, а чатов с участием сотрудника — на 7,52% больше.
Эта разница полностью поменяла картину. Сотруднику требовалось меньше времени на отдельный чат, но самих чатов стало больше. Поэтому в пересчёте на клиента выросли суммарные усилия, время сотрудников и стоимость обслуживания. CSAT при этом значимо не ухудшился.
Это и было главным результатом эксперимента.
Мы не сделали поддержку менее эффективной. Мы снизили барьер до неё и увидели объём потребности, который раньше частично скрывался за сложным входом.
У этой интерпретации есть предел, и я его проговариваю честно. Вместе с барьером изменился и состав обращений: когда написать стало проще, в поддержку пошли более простые вопросы, а они сами по себе требуют меньше усилий. Развести в этих данных вклад интерфейса и вклад изменившегося состава мы не можем. Но обе части одинаково поддерживают главный вывод: сложный вход был не эффективностью, а скрытым спросом.
Мы решили не возвращать прежние барьеры
После эксперимента можно было вернуть часть старой логики и снова сделать обращение сложнее. Это помогло бы экономике, но противоречило самой цели Центра поддержки.
Вместе с продуктом и бизнесом мы решили сохранить новую модель и раскатили её на весь массовый сегмент — уже зная, что стоимость обслуживания выросла.
Я представлял позицию дизайна: доступность помощи нельзя считать ошибкой только потому, что после её улучшения люди начали чаще обращаться за помощью.
Следующая задача продукта была уже другой — снижать стоимость самого обслуживания, а не экономить за счёт сложности доступа к нему.
При этом мы не стали защищать первую концепцию любой ценой.
Модель адаптировали для Premium и Private, а отделение поддержки от посторонних коммуникаций продолжили как отдельную миграцию.
Интерфейс перестал быть границей нашей работы
До Центра поддержки дизайнеры чатов в основном работали с мессенджером как с платформой: проектировали экраны, состояния, компоненты и привычные функции переписки.
Когда я собрал команду дизайнеров вокруг клиентской поддержки, мы продолжили отвечать за интерфейс, но перестали считать его границей клиентского опыта. Стали смотреть шире: что и каким тоном пишет сотрудник, как отвечает бот, через какие процедуры он проводит клиента, какие действия предлагает, что происходит при передаче вопроса между линиями и понимает ли клиент, что сейчас происходит с его проблемой.
Мы не забирали эти области у команд, которые за них отвечали. Если находили разрыв в опыте, формулировали проблему и приходили к её владельцам вместе искать решение.
Так дизайн-направление команды изменилось с «сделать удобный интерфейс чата» на «сделать целостным весь опыт решения проблемы». Это решение пережило сам проект: команда работает так до сих пор.
Моя роль
Я вошёл в проект как дизайн-лид с финальным словом по дизайну и вёл его от формирования концепции до массового запуска.
Моя зона ответственности:
- сформировал позицию дизайна по двум исходным направлениям и предложил третью продуктовую модель;
- спроектировал основную часть первой концепции и перевёл стратегические принципы в клиентский интерфейс;
- задал дизайн-направление после подключения ещё двух дизайнеров и расширил зону внимания команды от интерфейса до клиентского обслуживания целиком;
- представлял позицию клиентского опыта в обсуждениях с рабочей группой, бизнесом и топами;
- закрепил в концепции границу между сервисным и маркетинговым каналами и продолжил защищать её в незавершённой миграции;
- лично согласовал запуск голосовых сообщений с несколькими CPO после года безрезультатных попыток команды;
- принимал ключевые решения от дизайна и адаптировал модель после получения реальных данных.
Выбор целевой модели, эксперимент, запуск и крупные бизнес-компромиссы были совместными решениями команды.
Центр поддержки изменил не только интерфейс вкладки.
Поддержка перестала быть одним из чатов внутри мессенджера и стала самостоятельным продуктом, в котором интерфейс, канал и внутренняя структура банка подстраиваются под проблему клиента — а не наоборот.
Но Центр поддержки не был конечной точкой. Он упростил доступ к существующей модели обслуживания, а следующий этап требовал переосмыслить сам способ взаимодействия: не только дать клиенту удобный канал, но и понять его намерение, сохранить контекст и помочь пройти путь до результата.
Из этого выросло следующее направление — AI-native Support, где поиск, поддержка и AI складываются в единый сценарий взаимодействия с банком.