От Центра поддержки к AI-треку
В этом кейсе я рассказывал, как мы перестали развивать поддержку внутри мессенджера, собрали отдельный сервис вокруг проблемы клиента и начали отделять сервисный канал от маркетинговых коммуникаций.
Но поддержка в Т‑Банке к этому моменту уже была больше, чем местом для решения проблем.
За девятнадцать лет банк научился отвечать на любой вопрос, и клиенты этим пользовались буквально. Только около четверти обращений были связаны непосредственно с проблемой. Остальное:
- навигация: «как открыть накопительный счёт?»;
- дискавери: «куда лучше вложить деньги?»;
- вопросы вообще не по адресу — от рецептов до просьбы спеть песню.
И сотрудники отвечали на всё. Это было сильной стороной банка и одновременно объясняло, почему поддержка стала для клиентов одной из главных точек входа в экосистему.
Центр поддержки сделал этот вход проще и убрал из него часть лишнего шума. Но продуктовая модель осталась прежней: клиенту всё ещё нужно было прийти в отдельный раздел, сформулировать вопрос и дальше взаимодействовать с существующей связкой бота и сотрудников.
От стратегии к целевой версии
В четвёртом квартале 2025 года появилась стратегия обслуживания до 2030 года. Она задала другой целевой образ: девять из десяти проблем решаются автоматически и в одно касание, система знает контекст до обращения, а человек подключается там, где нужны эмпатия, экспертиза или сложное решение.
На уровне интерфейсов мы с продакт-лидом начали описывать целевую версию умной поддержки — вышел общий сценарный слой между поиском и поддержкой.
Клиенту не нужно заранее понимать, где искать функцию, где задавать вопрос, а где обращаться за помощью. Он формулирует намерение в контексте текущего экрана, а система сама решает, что сделать дальше: провести к нужному действию, дать ответ, запустить сценарий или подключить поддержку.
При этом мы намеренно не ушли от модели чата. Это дало нам целевой образ интерфейса. Но между ним и существующим чатом не было готовой продуктовой дороги.
Как собрали план развития
Мы самостоятельно пошли от целевого опыта назад и разложили развитие продукта на последовательные итерации.
Сначала нужно было заменить техническую основу чата и научиться постепенно переносить на неё существующие сценарии. Затем — собрать мультимодальное взаимодействие и динамические ответы, подключить AI, объединить сценарный слой поиска и поддержки и только после этого двигаться к единой точке входа.
Когда свели продуктовые изменения, архитектуру и порядок внедрения в один план, получился горизонт на 24 месяца.
Это был не срок, заданный стратегией, а результат декомпозиции: столько занимал реалистичный путь от текущего продукта к целевой версии без одномоментной перестройки критичного сервисного канала.
Что мешало реализовать план
Чат работал на старом SDK с большим техническим долгом. Мы считали дефекты на фичу и видели, что почти каждая новая функциональность приносила новые баги. Разработка уходила их исправлять, продукт терял предсказуемость бэклога, а роадмап постоянно сдвигался.
Для дизайна это выглядело так: вместо лучшего решения всё чаще приходилось искать интерфейсный обход для очередного «технически так не можем». Я не хотел строить следующий продукт как набор компенсаций поверх старой архитектуры.
На встрече лидов сошлись три позиции:
- разработка не могла дальше предсказуемо развивать старую основу;
- продукт не мог планировать сложные изменения, пока ресурсы постоянно уходили на дефекты;
- дизайн не мог собрать целевой опыт из интерфейсных обходов.
Решение переписать SDK было общим. Новая архитектура стала первым этапом 24-месячного плана.
Первые продуктовые итерации мы сознательно запланировали без LLM: сначала новая основа и интерфейс, затем интеллект. Клиенту не нужно одновременно привыкать к двум большим изменениям, а команде бессмысленно тестировать агентов на нестабильной архитектуре.
Как инициативу провели через гейты
В Т‑Банке новая продуктовая инициатива проходит систему гейтов, прежде чем получить команду, ставки и квоты.
Для защиты мы собрали в одну инициативу:
- концепцию целевого клиентского опыта;
- план развития на 24 месяца;
- новый SDK и архитектуру;
- порядок перехода со старой основы;
- ресурсы для запуска отдельного трека.
Я собрал первый концепт AI-native Support. В нём клиент формулировал намерение любым удобным способом, а система сама определяла, кто должен ответить и какое действие предложить: модель со знаниями банка, проверенный сценарный бот или сотрудник.
Концепт был не финальным интерфейсом и не иллюстрацией чужой стратегии. Он показывал, ради какого клиентского опыта нужно менять продукт и его техническую основу.
Инициатива прошла защиту и получила отдельную команду и ресурсы.
Команда под новый трек
Дизайнеры моей группы вели текущие продуктовые задачи. Передать одному из них ещё и AI-направление означало бы поставить новый продукт в очередь за обязательным delivery.
Нужен был дизайнер, который понимает AI-продукты, умеет работать с высокой неопределённостью и готов проектировать не только экраны, но и поведение работающей системы.
Я описал профиль и нанял человека специально под этот трек. Дизайнер вышел в феврале 2026 года. Я передал ему продуктовый контекст и первый концепт, остался за финальными решениями по дизайну и договорённостями со стейкхолдерами. Ежедневное развитие продукта он вёл сам.
К апрелю у нас уже была первая работающая версия целевого опыта на устройстве.
Найм закрепил AI-native Support как отдельную зону работы, под которую можно было менять процесс, не останавливая развитие существующего продукта.
Почему ушли из Figma в код
В новом чате качество определяли задержка и стриминг ответа, переход между текстом и голосом, хаптика, поведение вложений, динамические действия и передача контекста сотруднику. По последовательности заранее подготовленных экранов эти решения принять нельзя.
Особенно быстро ограничение проявилось на Liquid Glass. В Figma можно было приблизительно показать внешний вид материала, но нельзя было достоверно настроить tint, scroll edge, системные состояния и поведение стекла в движении.
Поэтому мы выбрали другой стек: Claude Code и Codex для работы с нативными сборками, Xcode и Android Studio для запуска и настройки поведения, GitHub как общую базу проекта.
Сборка больше не жила локально у одного дизайнера. В репозитории сохранялись актуальное состояние, варианты решений и правила, по которым с ней могли работать остальные участники команды.
Figma осталась для статичных состояний, корнер-кейсов, спецификаций и дизайн-системы. Изменился источник решения: поведение мы проектировали на устройстве, а в макетах фиксировали то, что нужно передать дальше.
Как проверяли целевой опыт
Нам не нужен был прототип с заранее подготовленными ответами. Он хорошо работает на демонстрации, но ничего не говорит о реальном темпе диалога, длине ответа, паузах, ошибках и реакции интерфейса на непредсказуемый контент.
В продуктовой поставке AI должен был появиться после перехода на новую архитектуру. Но в дизайн-сборке модель была нужна сразу: без неё нельзя было проверить, как целевой интерфейс ведёт себя в реальном диалоге.
Я подключил OpenAI API, и внутри сборки работала настоящая LLM. Ответы генерировались в момент диалога, стриминг был живым, а голос, вложения и интерактивные элементы отрабатывали максимально близко к целевому сценарию.
Код сборки не был продовым и не должен был им становиться.
Как передавали решения в разработку
Сборка помогла согласовать идею именно потому, что вела себя как продукт. Стейкхолдеры могли пройти сценарий руками и оценивать не обещание, а опыт. Дизайн-система обсуждала не картинку стекла, а материал и компоненты в движении.
Liquid Glass был новым и для разработчиков. У них ещё не было готового опыта, как системный материал должен вести себя именно в нашем продукте и где заканчиваются платформенные правила и начинаются правила дизайн-системы банка.
Мы настроили основные состояния в нативной сборке, зафиксировали поведение и на её основе онбордили разработчиков: разбирали tint, scroll edge, переходы, анимации и системные ограничения прямо на устройстве.
Разработчики получали репозиторий до груминга и видели механику целиком, а не восстанавливали её по макетам и комментариям. Если поведение вызывало вопрос, команда могла открыть ту же сборку, сравнить варианты и принять решение до продовой реализации.
Сборка стала общим референсом и сокращала разрыв между тем, что задумал дизайнер, что понял разработчик и что в итоге увидит клиент.
Изменения начали с воркшопов
Внутри AI-трека дизайнер стал работать с продуктом в его естественной среде: с реальной задержкой, динамикой, системными ограничениями и непредсказуемым ответом модели.
Для одной команды это уже изменило качество решений. Но для меня как для лида важнее был следующий вопрос: как превратить локальную практику в доступную компетенцию для всей профессии.
В компании около 600 дизайнеров. Мы с дизайнером провели серию встреч и воркшопов; отдельные форматы собирали от 150 до 300 человек. После них команды приходили отдельно разбирать свои задачи.
Воркшопы дали общий язык и интерес, но не изменили регулярный процесс. Чтобы новая практика действительно масштабировалась, её нужно было встроить в работу, которую дизайнеры и так делают каждую неделю.
Такой точкой я выбрал дизайн-ревью.
Наш подход к дизайн-ревью
На дизайн-ревью регулярно попадали фичи с базовыми расхождениями со спецификацией: неверным отступом, тенью или цветом, другой кривой анимации, неправильным таймингом.
Это не всегда ловят разработчик и тестировщик: они проверяют работоспособность и сценарий через другую оптику. В результате дизайнер тратит время на механическую сверку вместо продуктовой логики и общего качества опыта.
Целевой процесс выглядит так:
1. Задача переходит на дизайн-ревью.
2. Агент идёт в репозиторий разработки, находит нужную ветку или последний мердж и сверяет реализацию с дизайн-спецификацией и рабочим референсом. Отдельный скилл задаёт правила проверки.
3. Формальные расхождения возвращаются разработчику, а задачи на исправление создаются автоматически.
4. Дизайнер подключается, когда базовая точность уже проверена, и оценивает логику, сценарий и качество опыта целиком.
Первую итерацию MVP мы сознательно упростили: агент сравнивает со спецификацией скриншот реализации, а не идёт в код. Так быстрее проверить, способен ли он стабильно находить типовые расхождения, не начиная сразу с интеграции в разные репозитории и процессы разработки.
Проверка через код и автоматическая постановка задач остаются целевым виженом. Если MVP подтвердит качество сравнения, следующим шагом станет подключение к ветке разработки и полный проход до передачи готовой фичи дизайнеру.
Моя роль
Я вошёл в проект как дизайн-лид с финальным словом по дизайну и веду его с декабря 2025 года.
Моя зона ответственности:
- вместе с продакт-лидом описал целевой опыт умной поддержки и разложил путь к нему в план на 24 месяца;
- собрал первый концепт AI-native Support и использовал его при защите инициативы на гейтах;
- участвовал в общем решении переписать SDK и отстаивал отказ от интерфейсных компенсаций старой архитектуры;
- описал профиль и нанял дизайнера специально под AI-трек;
- перенёс ключевые решения по поведению из макетов в нативную сборку, подключил настоящую LLM и сделал сборку общим референсом для команды;
- вместе с дизайнером онбордил разработчиков и провёл серию воркшопов для дизайнеров компании;
- предложил агентное дизайн-ревью как следующую точку масштабирования и готовлю его MVP по скриншотам.
Стратегия обслуживания задала общий вектор. Решение о новой архитектуре, защита трека и выделение ресурсов были совместной работой продукта, разработки, дизайна и бизнеса. Моя часть — связать этот вектор с клиентским опытом, собрать дизайн-компетенцию под новое направление и изменить способ, которым команда этот опыт проектирует.
Продукт и новый SDK ещё в разработке, поэтому клиентских метрик пока нет. Результат этого этапа — собранный AI-трек: план на 24 месяца, команда, новая техническая основа, работающая модель продукта и новый способ проектирования.