# Витрина сервисного входа ВКУС  
## Подробный методический материал: связка CJM, capabilities и архитектуры

**Статус:** рабочий подробный companion-документ к резюмирующему PDF.  
**Назначение:** дать команде более подробную методическую и содержательную основу для самостоятельного изучения, уточнения HLD и подготовки roadmap.

---

## 0. Краткое резюме

Команда проектирует не новый канал общения с техподдержкой и не отдельный интерфейс вопрос-ответ, а **витрину сервисного входа ВКУС**.

Целевая витрина должна менять клиентский путь пользователя:

```text
Пользователь столкнулся с проблемой
→ описал задачу своим языком
→ получил быстрый ответ / инструкцию / сценарий / предзаполненную заявку
→ видит понятный статус и следующий шаг
→ получает результат
→ подтверждает качество
→ данные возвращаются в контур улучшения
```

Ключевой принцип:

```text
Изменение клиентского пути
→ business capability
→ data / process capability
→ technical capability
→ architecture component
→ MVP
→ metric
```

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

---

## 1. Почему не начинаем с интерфейсного решения

### Не так

```text
Нужно внедрить чат-бот / новый интерфейс для обращений в поддержку.
```

### А вот так

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

Интерфейсный паттерн — это только способ реализации. Он может быть разным:

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

Главный вопрос не «какой интерфейс сделать?», а:

> Какой пользовательский путь позволит быстрее и точнее решить обращение с минимальными усилиями пользователя?

---

## 2. Текущая проблема клиентского пути

Сейчас пользователь вынужден выполнять часть работы, которая на самом деле нужна не ему, а ИТ-поддержке:

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

### Не так

```text
Пользователь должен найти правильную услугу и заполнить анкету.
```

### А вот так

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

---

## 3. Базовая логика трассировки

Каждое изменение в целевом решении должно проходить полную цепочку:

```text
Этап клиентского пути
→ боль / разрыв
→ целевое изменение
→ business capability
→ data / process capability
→ technical capability
→ architecture component
→ metric
→ MVP / release
```

Эта цепочка нужна, чтобы:

- не внедрять функции без связи с клиентской ценностью;
- не смешивать capabilities, технические компоненты и UI-паттерны;
- показать, зачем нужна каждая архитектурная доработка;
- связать UX, бизнес-анализ и HLD;
- построить roadmap от клиентского пути, а не от технологий.

---

## 4. Главный рабочий артефакт: матрица трассировки

Матрица трассировки — основной документ для совместной работы бизнес-аналитика, UX/CX, архитектора, владельца ВКУС, владельца ITSM и команды реализации.

### Шаблон

| Этап CJM | Боль / разрыв | Целевое изменение | Business capability | Data / process capability | Technical capability | Архитектурные компоненты | Метрика | MVP |
|---|---|---|---|---|---|---|---|---|

### Пример заполнения

| Этап CJM | Боль / разрыв | Целевое изменение | Business capability | Data / process capability | Technical capability | Архитектурные компоненты | Метрика | MVP |
|---|---|---|---|---|---|---|---|---|
| Пользователь ищет услугу | Не знает внутреннюю классификацию ИТ-услуг | Описывает задачу своими словами, витрина предлагает сценарий | Понимание пользовательского намерения | Корпус обращений, поисковые запросы, словарь синонимов, история реклассов | Классификация намерения, семантический поиск | ВКУС, сервис классификации, каталог услуг, API Gateway, ITSM | Reclass rate, time to submit | MVP 3 |
| Пользователь заполняет карточку | Много обязательных полей, часть данных уже известна компании | Карточка предзаполнена, пользователь вводит только недостающее | Минимизация ручного ввода | Данные пользователя, подразделение, роль, система, история обращений | Предзаполнение формы, интеграция с мастер-данными | ВКУС, сервис предзаполнения, AD/IAM, HR, CMDB, ITSM | Количество ручных полей, time to submit | MVP 1 |
| Пользователь ищет инструкцию | Инструкции разрознены, поиск не помогает | Витрина предлагает короткий ответ или релевантную инструкцию до создания обращения | Помощь до создания обращения | База знаний, метаданные инструкций, история типовых ответов | Поиск по знаниям, ранжирование, ответ с источником | ВКУС, база знаний, RAG/search-контур, API Gateway | Deflection rate, search success rate | MVP 2 |
| Пользователь ожидает решение | Нет понятного статуса и следующего действия | Пользователь видит этап обработки, срок и что требуется от него | Управление статусом и ожиданиями | Статусы ITSM, SLA, комментарии, события процесса | Нормализация статусов, уведомления, next best action | ITSM, ВКУС, status/event service, notification service | CSAT по ожиданию, обращения «где статус» | MVP 4 |
| Пользователь оценивает результат | Обратная связь не превращается в улучшения | Оценка запускает улучшение карточек, знаний и маршрутизации | Управление качеством клиентского пути | Оценки, комментарии, переоткрытия, повторные обращения | Аналитика обратной связи, кластеризация проблем | ВКУС, ITSM, Data Mart, BI | Reopen rate, FCR, CSAT | MVP 5 |

---

## 5. Нормализация понятий: что является capability, а что нет

### Не так

```text
Capability = кнопка / экран / API / компонент / модуль.
```

### А вот так

```text
Capability = способность компании обеспечить нужное изменение клиентского пути.
```

| Не capability | Capability |
|---|---|
| Кнопка на форме | Минимизация ручного ввода |
| Поисковая строка | Помощь до создания обращения |
| API-интеграция | Управляемая оркестрация сервисного процесса |
| Экран статуса | Управление ожиданиями пользователя |
| BI-отчет | Аналитика клиентского пути |
| RAG-компонент | Поиск и использование знаний для помощи пользователю |
| Форма обращения | Создание обращения с достаточным контекстом |

---

## 6. Capability map целевой витрины

### 6.1. Клиентские capabilities

Эти возможности описывают, что должен ощущать и получать пользователь.

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

### 6.2. Business capabilities поддержки

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

- управление каталогом услуг;
- управление знаниями;
- управление обращениями;
- управление маршрутизацией;
- управление SLA и ожиданиями;
- управление обратной связью;
- управление качеством клиентского пути.

### 6.3. Data / analytics capabilities

Эти возможности обеспечивают доказательную базу и постоянное улучшение.

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

### 6.4. Technical capabilities

Эти возможности должна обеспечивать ИТ-архитектура.

- семантический поиск;
- поиск по базе знаний;
- классификация намерений;
- сопоставление намерения с услугой / инструкцией / обращением;
- предзаполнение формы;
- интеграция с мастер-системами;
- интеграция с ITSM;
- маршрутизация обращения;
- управление статусами;
- уведомления;
- аналитика и мониторинг качества.

---

## 7. Целевая архитектурная рамка

### Не так

```text
Пользователь → вопросно-ответный интерфейс → поиск ответа → ответ / заявка
```

### А вот так

```text
Пользователь
→ ВКУС: витрина сервисного входа
→ слой сценариев и намерений
→ слой знаний и каталога услуг
→ слой карточек и предзаполнения
→ интеграционный слой
→ ITSM-исполнение
→ статусы и уведомления
→ аналитика и улучшение качества
```

### 7.1. Архитектурные слои

| Слой | Назначение | Примеры компонентов | Какие capabilities реализует |
|---|---|---|---|
| Frontstage / ВКУС | То, что видит пользователь | Задачная главная, умный поиск, карточка, мастер решения, статус, оценка | Единый вход, снижение когнитивной нагрузки, статус, feedback |
| Scenario & Intent Layer | Понимание задачи пользователя | Intent service, scenario engine, clarification logic | Понимание намерения, выбор сценария, минимальные уточнения |
| Knowledge & Service Catalog Layer | Помощь до обращения и связь с услугами | База знаний, каталог услуг, RAG/search-контур, service mapping | Помощь до обращения, управление знаниями, intent → service |
| Form & Prefill Layer | Минимизация ручного ввода | Prefill service, form engine, validation rules, context package | Предзаполнение, минимальный ввод, качество заявки на входе |
| Integration & Orchestration Layer | Управляемые интеграции | API Gateway, connectors, auth, audit, policies | Оркестрация, безопасность, аудит, устойчивость |
| ITSM Execution Layer | Создание и исполнение обращений | ITSM / Creatio, routing, SLA, comments sync | Создание обращения, маршрутизация, SLA, исполнение |
| Status & Notification Layer | Понятное ожидание | Status/event service, notification service, next best action | Прозрачный статус, уведомления, управление ожиданиями |
| Analytics & Improvement Layer | Улучшение сервиса на данных | Event tracking, Data Mart, text analytics, BI, feedback loop | Аналитика пути, feedback loop, knowledge governance |

---

## 8. Целевой путь: как было / как должно стать

| Область | Как было | Как должно стать |
|---|---|---|
| Вход в поддержку | Пользователь выбирает канал и услугу | Пользователь описывает задачу, витрина предлагает сценарий |
| Инструкции | Пользователь сам ищет и читает длинные материалы | Витрина предлагает короткий ответ, источник и следующий шаг |
| Карточка | Пользователь заполняет анкету для поддержки | Пользователь проверяет предзаполненный контекст |
| Маршрутизация | Ошибка выбора услуги ведет к переназначениям | Намерение сопоставляется с услугой и группой поддержки |
| Ожидание | Пользователь видит формальный статус | Пользователь понимает этап, срок и next best action |
| Результат | Обращение закрыто в ITSM | Пользователь подтвердил решение рабочей проблемы |
| Улучшение | Обратная связь собирается отдельно | Обратная связь попадает в backlog улучшений |

---

## 9. Gap-analysis текущего HLD

Текущий HLD содержит полезное ядро:

- ВКУС как точку входа;
- API Gateway;
- LiteLLM / LLM-шлюз;
- RAG/search-контур;
- интеграцию с ITSM / Creatio;
- передачу контекста;
- первичную обратную связь.

Но HLD должен быть расширен от описания отдельного интерфейсного решения до архитектуры витрины сервисного входа.

| Capability | Покрытие в HLD | Что требуется добавить |
|---|---|---|
| Поиск по инструкциям | Покрыто / частично | Требования к качеству источников, актуальности, владельцам знаний |
| Понимание намерения пользователя | Частично | Выделить intent detection как отдельную capability и компонент |
| Сопоставление намерения с услугой | Не покрыто | Добавить mapping: intent → service / knowledge / ticket |
| Предзаполнение обращения | Не покрыто | Добавить prefill service и интеграции с AD/IAM, HR, CMDB, ITSM |
| Динамическая карточка | Не покрыто | Добавить form/scenario engine |
| Прозрачный статус | Не покрыто | Добавить status/event service и UX-словарь статусов |
| Аналитика клиентского пути | Не покрыто | Добавить event tracking, Data Mart, BI, text analytics |
| Feedback loop | Частично | Связать оценки с backlog улучшений карточек, знаний и маршрутизации |

### Ключевая доработка HLD

### Не так

```text
High-Level Design: отдельный интерфейс вопрос-ответ для ИТ-поддержки.
```

### А вот так

```text
High-Level Design: витрина сервисного входа ВКУС.
```

---

## 10. MVP 0: Data Discovery как обязательный старт

MVP 0 — это не просто сбор нескольких метрик. Это **тотальный анализ обращений, ответов поддержки и логов действий**.

### Не так

```text
Берем одну услугу и экспертно решаем, что в ней улучшить.
```

### А вот так

```text
Сначала анализируем весь массив обращений, ответов и логов, строим фактическую карту проблематики, затем выбираем пилотную услугу на основании данных.
```

### 10.1. Что анализируем

| Источник | Ценность |
|---|---|
| Тексты обращений | Пользовательские намерения, реальные формулировки, частотные темы |
| Ответы поддержки | Типовые решения, повторяющиеся ответы, качество языка |
| Комментарии | Уточнения, потеря контекста, недостающие данные |
| Маршрутизация | Реклассы, переназначения, ошибки выбора услуги |
| Статусы и сроки | Ожидание, задержки, зависания |
| Переоткрытия | Где результат не решает проблему с первого раза |
| Оценки | Качество глазами пользователя |
| Поиск во ВКУС | Пользовательский язык поиска и пробелы каталога |
| Логи действий во ВКУС | Открытые карточки, возвраты, незавершенные обращения |
| Действия поддержки | Типовые ручные операции, запросы данных, смены групп |

### 10.2. Какие вопросы должен закрыть Data Discovery

| Вопрос | Зачем нужен ответ |
|---|---|
| Какие пользовательские намерения создают основной поток обращений? | Основа для задачной главной и intent layer |
| Какие обращения можно было решить инструкцией без заявки? | Основа для помощи до обращения |
| Какие данные поддержка чаще всего уточняет? | Основа для предзаполнения и динамической карточки |
| Какие услуги чаще всего выбираются неверно? | Основа для intent → service mapping |
| Какие ответы поддержки повторяются? | Основа для базы знаний и шаблонов решений |
| Какие инструкции не находятся или не помогают? | Основа для knowledge governance |
| Где пользователь теряет время до подачи обращения? | Основа для UX-улучшений ВКУС |
| Где обращение теряет контекст между каналами и группами? | Основа для context package и ITSM-интеграции |
| Какие сценарии дают высокий reclass / reassignment / reopen? | Основа для приоритизации MVP |
| Какие карточки услуг являются наиболее проблемными? | Основа для выбора пилотной услуги |

### 10.3. Выходы MVP 0

- карта пользовательских намерений;
- топ проблемных услуг / карточек;
- список типовых недостающих данных;
- список повторяющихся ответов поддержки;
- список knowledge gaps;
- карта ошибок маршрутизации;
- baseline метрик;
- обоснованный выбор пилотной услуги.

---

## 11. Roadmap / MVP-логика

Roadmap строится не от технических компонентов, а от изменений клиентского пути.

### Не так

```text
MVP 1: поиск
MVP 2: LLM
MVP 3: интеграция с ITSM
MVP 4: аналитика
```

### А вот так

```text
MVP 0: построить фактическую карту проблем на данных
MVP 1: сократить ручное заполнение
MVP 2: помочь до создания обращения
MVP 3: убрать необходимость выбора услуги
MVP 4: сделать ожидание прозрачным
MVP 5: запустить контур постоянного улучшения
```

| MVP | Фокус | Изменение в клиентском пути | Основные capabilities | Ключевые компоненты | Метрики |
|---|---|---|---|---|---|
| MVP 0 | Data Discovery | Понять фактические разрывы текущего пути | Аналитика клиентского пути | Выгрузки ВКУС/ITSM, анализ текстов, логов, Data Mart light | Baseline, reclass, clarification, reopen |
| MVP 1 | Упрощение карточки | Быстрее и проще подать обращение | Предзаполнение, минимальный ввод | ВКУС, prefill, мастер-данные, ITSM | Time to submit, ручные поля, clarification rate |
| MVP 2 | Помощь до обращения | Решать часть вопросов без заявки | Поиск по знаниям, управление инструкциями | Knowledge layer, search/RAG, API Gateway | Deflection, search success, helpfulness |
| MVP 3 | Намерения | Не выбирать услугу вручную | Intent detection, service mapping, routing | Intent service, catalog, routing, ITSM | Reclass, reassignment, time to submit |
| MVP 4 | Статус | Понятно ждать и отвечать на уточнения | Status, notifications, next best action | Status/event service, notifications | CSAT, обращения по статусу |
| MVP 5 | Улучшение | Сервис сам выявляет, что улучшать | Analytics, feedback loop, governance | CX Data Mart, BI, text analytics | CSAT, FCR, reopen |

---

## 12. Детализация MVP

### 12.1. MVP 1: упрощение карточки

Цель — доказать, что снижение ручного ввода улучшает клиентский опыт.

### Не так

```text
Пользователь заполняет анкету для поддержки.
```

### А вот так

```text
Пользователь проверяет предзаполненный контекст и добавляет только то, чего система не знает.
```

Что сделать:

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

Метрики:

- количество ручных полей;
- time to submit;
- clarification rate;
- доля автозаполненных полей;
- CSAT по подаче.

### 12.2. MVP 2: помощь до обращения

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

### Не так

```text
Пользователь не знает, как сделать → ищет услугу → создает обращение.
```

### А вот так

```text
Пользователь не знает, как сделать → получает короткую инструкцию → создает обращение только если инструкция не помогла.
```

Метрики:

- deflection rate;
- search success rate;
- helpfulness score;
- knowledge gap rate.

### 12.3. MVP 3: намерения и маршрутизация

Цель — убрать необходимость пользователю знать внутреннюю классификацию ИТ-услуг.

### Не так

```text
Пользователь ищет правильную услугу в каталоге.
```

### А вот так

```text
Пользователь описывает задачу, система предлагает сценарий, услугу, инструкцию или заявку.
```

Метрики:

- reclass rate;
- reassignment rate;
- intent accuracy;
- time to submit;
- clarification rate.

### 12.4. MVP 4: прозрачный статус

Цель — снизить неопределенность после создания обращения.

### Не так

```text
Пользователь получил номер обращения и ждет.
```

### А вот так

```text
Пользователь видит понятный статус, срок, следующий шаг и запросы к себе.
```

Метрики:

- обращения «где статус?»;
- CSAT по ожиданию;
- время ответа пользователя на уточнение;
- доля просроченных уточнений.

### 12.5. MVP 5: контур постоянного улучшения

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

### Не так

```text
Пользователь поставил оценку, но улучшения происходят нерегулярно.
```

### А вот так

```text
Оценки, тексты, логи и результаты формируют backlog улучшений.
```

Метрики:

- feedback-to-backlog rate;
- доля улучшенных карточек;
- доля обновленных инструкций;
- reopen rate;
- FCR;
- CSAT.

---

## 13. Метрики и критерии успеха

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

### Не так

```text
Реализовано предзаполнение карточки.
```

### А вот так

```text
Пользователь меньше вводит вручную, быстрее отправляет обращение, а поддержка реже запрашивает недостающие данные.
```

### 13.1. Минимальный дашборд

| Блок | Метрика |
|---|---|
| Усилия пользователя | Time to submit |
| Усилия пользователя | Количество ручных полей |
| Поиск / помощь | Search success rate |
| Поиск / помощь | Deflection rate |
| Качество входа | Reclass rate |
| Качество входа | Clarification rate |
| Исполнение | MTTR |
| Результат | Reopen rate |
| Результат | FCR |
| Опыт | CSAT |

### 13.2. Расширенный набор метрик

| Группа | Метрики |
|---|---|
| Усилия пользователя | time to submit, количество ручных полей, abandoned submission rate, количество открытых карточек до подачи |
| Понимание намерения | intent accuracy, reclass rate, reassignment rate, корректность предложенной услуги |
| Помощь до обращения | deflection rate, search success rate, helpfulness score, knowledge gap rate |
| Качество заявки на входе | clarification rate, доля обращений без доп. вопросов, time to first action |
| Ожидание | SLA transparency, обращения «где статус?», CSAT по ожиданию |
| Результат | FCR, reopen rate, repeat contact rate, CSAT по результату |
| Контур улучшения | feedback-to-backlog rate, доля улучшенных карточек, доля обновленных инструкций |

---

## 14. Данные как источник ценности

Анализ обращений, ответов поддержки и логов важен не только для отчетности. Это основа проектирования целевой витрины.

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

### 14.1. Ценность текстов обращений

Тексты обращений показывают:

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

### 14.2. Ценность ответов поддержки

Ответы поддержки показывают:

- какие решения повторяются;
- какие ответы можно стандартизировать;
- какие инструкции реально используются;
- где язык поддержки слишком технический;
- где результат не соответствует ожиданию;
- какие вопросы можно перевести в self-service.

### 14.3. Ценность комментариев

Комментарии показывают:

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

### 14.4. Ценность логов действий пользователя

Логи показывают невидимую часть пути до создания обращения:

- поисковые запросы;
- открытые карточки;
- возвраты назад;
- время на карточке;
- начатые, но не отправленные обращения;
- переходы между каналами;
- точки отказа.

### 14.5. Ценность логов поддержки

Логи поддержки показывают операционную механику:

- переназначения;
- реклассы;
- время до первого действия;
- типовые ручные операции;
- запросы данных;
- смену групп;
- закрытия типовыми формулировками.

---

## 15. Рабочие задачи для команды

### 15.1. Ближайшие задачи

```text
1. Утвердить принцип: проектируем витрину сервисного входа.
2. Утвердить формат матрицы трассировки.
3. Запустить тотальный анализ обращений, ответов поддержки и логов действий.
4. На основе анализа выбрать пилотную услугу.
5. Собрать baseline по текущей карточке пилотной услуги.
6. Разобрать пилотную услугу детально: поля, уточнения, ошибки, маршрутизация.
7. Спроектировать короткую предзаполненную карточку.
8. Описать mini-HLD пилота.
9. Запустить пилот на ограниченной группе пользователей.
10. Измерить эффект и принять решение о масштабировании.
```

### 15.2. Рабочие артефакты

| Артефакт | Назначение |
|---|---|
| Нормализованный AS IS / TO BE путь | Показать изменение клиентского опыта |
| Матрица трассировки | Связать CJM, capabilities, архитектуру и метрики |
| Capability map | Развести бизнес-, data-, technical capabilities |
| Gap-analysis HLD | Понять, что есть и что нужно добавить |
| Целевая архитектурная рамка | Описать слои витрины сервисного входа |
| MVP-roadmap | Разложить реализацию по этапам |
| Дашборд метрик | Измерять эффект изменений |

---

## 16. Требования к HLD

HLD должен быть переработан в документ:

```text
High-Level Design: Витрина сервисного входа ВКУС
```

В нем должны быть разделы:

1. Цель архитектуры и связь с клиентским путем.
2. Capability layer.
3. Frontstage layer ВКУС.
4. Scenario & Intent layer.
5. Knowledge & Service Catalog layer.
6. Form & Prefill layer.
7. Integration & Orchestration layer.
8. ITSM Execution layer.
9. Status & Notification layer.
10. Analytics & Improvement layer.
11. Security / audit / data protection.
12. MVP roadmap.
13. Метрики качества.

---

## 17. Роли и зоны ответственности

| Роль | Ответственность |
|---|---|
| Product owner / владелец витрины | Приоритизация клиентского пути и roadmap |
| CX / UX-эксперт | CJM, сценарии, карточки, понятность статусов |
| Бизнес-аналитик | Матрица трассировки, требования, метрики |
| Архитектор | HLD, слои, компоненты, интеграции |
| Владелец ITSM | Процессы обращений, статусы, SLA, маршрутизация |
| Владелец каталога услуг | Качество услуг, карточек, связка intent → service |
| Владелец базы знаний | Инструкции, актуальность, источники, gaps |
| Data analyst | Аналитика обращений, логов, метрик |
| Security / ИБ | Доступы, аудит, персональные данные, обезличивание |

---

## 18. Риски и способы контроля

| Риск | Как проявится | Как контролировать |
|---|---|---|
| Возврат к интерфейсному мышлению | Команда снова обсуждает конкретный UI вместо пути | Использовать матрицу трассировки как обязательный артефакт |
| Слишком большой MVP | Попытка реализовать все слои сразу | Начать с одной услуги и измеримого эффекта |
| Нет данных для baseline | Невозможно доказать улучшение | MVP 0 сделать обязательным |
| Предзаполнение без качества данных | Подставляются неверные данные | Проверить источники и правила валидации |
| База знаний неактуальна | Витрина дает плохие ответы | Ввести knowledge governance |
| Статусы остаются внутренними | Пользователь не понимает «В работе» / «Назначено» | Создать пользовательский словарь статусов |
| Метрики не имеют владельцев | Дашборд есть, улучшений нет | Назначить владельцев метрик и backlog |
| Витрина становится новой анкетой | Пользователь проходит те же вопросы в новом интерфейсе | Ограничить ручной ввод и проверять time to submit |

---

## 19. Рабочие правила команды

1. Не начинать с выбора интерфейсного решения.
2. Любая функция должна быть связана с болью клиента.
3. Технический компонент не является capability.
4. Интерфейсный паттерн не является бизнес-возможностью.
5. Каждая capability должна иметь владельца и метрику.
6. Каждое изменение HLD должно быть связано с изменением в клиентском пути.
7. Roadmap должен начинаться с анализа данных и baseline.
8. Гипотезы улучшений проверяются на конкретных услугах и сценариях.
9. Витрина должна снижать усилия пользователя, а не переносить анкетирование в новый интерфейс.
10. Целевой результат — не создание обращения, а решение пользовательской проблемы.

---

## 20. Итоговая формулировка

Команда проектирует не новый канал общения с поддержкой, а **витрину сервисного входа во ВКУС**.

Витрина должна менять клиентский путь:

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

Каждая функция витрины должна быть связана с:

```text
этапом клиентского пути
→ business capability
→ data / process capability
→ technical capability
→ архитектурным компонентом
→ метрикой эффекта
```

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