← Портфолио
Корпоративный SaaS Рабочий процесс с AI Мультиролевая система Service Design

AI Workspace
для команд поддержки

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

РольВедущий продуктовый дизайнер
ТипEnterprise B2B SaaS
Охват3 роли · Полный рабочий процесс
Год2026
00 — Мой вклад

От сценариев трёх ролей до интерактивных HTML-прототипов

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

Рабочие сценарии
Разобрал сценарии Support Agent, Senior Specialist и Team Lead: от первого ответа до эскалации и контроля очереди.
Ролевая IA
Спроектировал информационную архитектуру, где один продукт поддерживает разные режимы работы и уровни контекста.
AI trust-паттерны
Описал паттерны доверия к AI: источники, проверяемость, редактируемость ответа и прозрачную передачу контекста.
Подготовил Agent / Senior / Team Lead workspace и интерактивные HTML-прототипы, чтобы сценарии можно было проверить как рабочий продукт, а не только как статичные макеты.
01 — Проблема

Главная потеря времени в поддержке — не сам тикет, а поиск нужного контекста

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

Поэтому задача была не просто добавить AI-помощника, а перестроить рабочее пространство так, чтобы контекст приходил к человеку вовремя, а не собирался вручную из нескольких источников.

60–70%
Времени съедает поиск контекста
Агент успевает обойти CRM, систему поддержки, биллинг и историю тикетов, прежде чем написать хотя бы первую строку ответа.
каждое 4-е
SLA-нарушение можно было поймать раньше
Не из-за нехватки агентов, а из-за риска, который никто вовремя не увидел. Team Lead замечает перегрузку очереди, когда окно уже почти закрыто.
3–4 нед.
Онбординг нового агента
Без встроенных знаний новые операторы держатся на племенном знании: Slack-тредах, памяти команды и коллегах-сеньорах.
Дизайн-ограничение: AI должен помогать быстрее ориентироваться в ситуации, но не принимать решение вместо человека. Поэтому каждая подсказка должна быть понятной, проверяемой и легко редактируемой.
02 — Пользователи

Один продукт и три разные ментальные модели

Главный инсайт был в том, что Support Agent, Senior Specialist и Team Lead работают по-разному и принимают разные решения. Им нужен не один и тот же экран с разными правами, а три разных режима работы внутри одной системы.

Support Agent
Сфокусированный исполнитель
Режим: один тикет · глубокий фокус
Работает с одним тикетом за раз и почти всегда под давлением времени. Ему нужен быстрый контекст, понятное следующее действие и спокойный, без лишних шагов, путь к эскалации.
Мгновенный контекст без поиска
AI-черновик, который можно сразу редактировать
Чёткий путь к эскалации
Senior Specialist
Распознаватель паттернов
Режим: очередь эскалаций · глубина прецедентов
Берёт то, что агент не смог закрыть сам. Здесь важны структурированные передачи контекста, поиск по прецедентам и ясность в политиках. И ещё, что немаловажно, хороший контроль качества для базы знаний.
Структурированная передача контекста вместо простого переназначения
Распознавание паттернов по тикетам
Вклад в БЗ одним действием
Team Lead
Операционный наблюдатель
Режим: вся команда · предиктивный риск
Не живёт внутри одного тикета. Ему нужно видеть очередь целиком, заранее ловить SLA-провалы и перераспределять нагрузку за секунды. Иначе управление превращается в догонялки.
SLA-риск до нарушения, не после
Нагрузка на агента с первого взгляда
Переназначение одним действием
03 — Рабочий процесс

От входящего тикета до закрытия — AI рядом в каждой точке решения

Базовый рабочий процесс выглядит простым. Сложность начинается там, где появляется ветвление в каждой точке человеческого решения, а ещё — в качестве передачи контекста между ролями при эскалации. Плохая передача = потеря контекста. Структурированная передача = вдвое быстрее закрытие кейса.

01
Тикет создан
Приоритет, SLA-таймер и AI-контекст
AI
02
Агент изучает
Сводка, история, черновик ответа
Агент
?
Решение
Закрыть, запросить данные, эскалировать
Агент
04
Передача эскалации
Структурированный контекст: причина, сделано, ожидаемое действие
Сеньор
05
Сеньор решает
Поиск прецедента, проверка политики и вклад в БЗ
Сеньор
06
Закрыт + обратная связь
AI-черновик оценён · CSAT отправлен
AI
Принцип передачи контекста: каждый получатель должен знать три вещи — что от него ждут, почему тикет дошёл до него и что уже было сделано. Если выпадает хотя бы одна, контекст рассыпается. Время закрытия кейса удваивается.
04 — Дизайн-решения

Принципы, которые собрали каждый экран

01
AI-контекст — главный контент, а не боковая панель
В большинстве инструментов AI остаётся функцией в правой боковой панели. Здесь AI-сводка, определение типа запроса и предложенный ответ попадают в основную зону чтения. Оператор видит AI-вывод до того, как погружается в переписку. Это сделано намеренно: AI-контекст меняет то, как ты читаешь разговор. Не наоборот.
Information Architecture
02
Эскалация — это структурированная передача контекста, не переназначение
Стандартные системы поддержки считают эскалацию переносом тикета. В этом продукте эскалация — задокументированная передача контекста: причина, что проверено, ожидаемое действие. Специалист видит это первым делом. Казалось бы, небольшая деталь, но именно она сокращает повторные объяснения, дублирующееся расследование и время закрытия кейса.
Service Design
03
AI-выводы всегда содержат источник и оценку уверенности
Каждая AI-рекомендация показывает источник: статья базы знаний, документ политики или предыдущий кейс. Уверенность видна сразу, без попытки спрятать сомнение под красивым интерфейсом. Если уверенность низкая, предупреждение появляется до отправки ответа. Так формируется калиброванное доверие: операторы понимают, когда опираться на AI, а когда его переопределять.
AI UX / Trust
04
Team Lead видит риск до того, как он стал нарушением
Панель управления показывает не только текущий статус. Она подсвечивает предсказанный SLA-риск на основе возраста тикета, нагрузки агента и исторического времени закрытия кейса. Перегруженный агент с P1-тикетом на 70% SLA-лимита получает флаг до нарушения, не после. Основное действие — переназначение — находится в одном клике от алерта.
Операционный дизайн
05
Ролевая информационная плотность, не общий UI
Agent View помогает быстро закрывать один кейс за раз. Senior View строится вокруг передачи эскалации и разбора сложных случаев. Lead View нужен для обзора очереди, рисков и нагрузки команды. Основа одна, но ритм работы у ролей разный, и интерфейс это должен уважать.
UX Strategy
06
Вклад в базу знаний — побочный эффект, не задача
Сеньоры не пишут БЗ-статьи — они решают кейсы. Вклад в БЗ запускается одним действием после закрытия кейса: AI собирает черновик статьи из кейса, сеньор одобряет. Система знаний растёт как естественное следствие работы, а не как ещё одна задача поверх всего остального.
Системное мышление
05 — Материалы

Три интерактивных прототипа, но один цельный продукт

Каждый экран — полностью интерактивный прототип на 1440px для десктопа. Внутри реалистичные данные, живой SLA-таймер, формы эскалации, панель AI-помощника и переключатель ролей для перехода между видами. Все три экрана держатся на одной дизайн-системе и соединены через переключатель ролей в верхней панели.

06 — Целевые продуктовые метрики

Ожидаемый эффект по метрикам продукта

Это не заявленные production-результаты, а измерительные рамки для пилота. Ниже — KPI, на которые нацелен продукт, и связь каждого из них с конкретными дизайн-решениями.

цель −38%
Среднее время обработки
AI-сборка контекста убирает ручной поиск
цель +22pp
SLA-соответствие
Риск виден до нарушения, а не после
цель −61%
Повторная работа при эскалации
Структурированная передача контекста убирает дублирующееся расследование
цель −70%
Время адаптации нового агента
Встроенная БЗ и AI-подсказки прямо во время работы
07 — Выводы

Что я понял и что стоит строить дальше

Ключевые выводы

  • Ролевой UI — это не только про права доступа. Важно учитывать, в каком режиме человек работает и сколько контекста ему нужно в конкретный момент.
  • Доверие к AI строится через прозрачность источников, не только через оценку уверенности. Показать откуда пришла рекомендация часто важнее, чем показать, насколько модель уверена.
  • Дизайн эскалации — это дизайн сервиса. Карточка передачи контекста оказалась самым влиятельным UI-элементом и, примечательно, самым недооценённым паттерном в существующих инструментах.
  • Операционная панель должна помогать замечать риск заранее. Для Team Lead важнее увидеть, где ситуация начинает ухудшаться, чем просто получить очередной статус-факт.

Что строить дальше

  • Петля обратной связи AI — встроенная оценка каждой рекомендации, без отдельного опроса. Это замыкает петлю улучшения модели без дополнительной нагрузки.
  • Мобильный вид для Team Lead — менеджерам смен нужна видимость SLA-рисков в движении, не только за рабочим столом.
  • Полный экран для сценария БЗ — путь вклада сеньора в БЗ просит отдельный экран: черновик, редактирование, теги, публикация.
  • Статус тикета для клиента — вторая половина петли поддержки. Что видит клиент, пока ждёт?
  • Онбординг новых агентов — рабочему пространству нужен режим с подсказками на реальных тикетах и AI-ограждениями.