vkus-ai-v2/input_data/Start data/Методика_ВКУС_CJM_capabilities_architecture_подробно.md

Витрина сервисного входа ВКУС

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

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

---

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

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

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

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

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

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

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

---

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

Не так

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

А вот так

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

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

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

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

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

---

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

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

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

Не так

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

А вот так

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

---

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

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

Этап клиентского пути
→ боль / разрыв
→ целевое изменение
→ 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, а что нет

Не так

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

А вот так

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. Целевая архитектурная рамка

Не так

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

А вот так

Пользователь
→ ВКУС: витрина сервисного входа
→ слой сценариев и намерений
→ слой знаний и каталога услуг
→ слой карточек и предзаполнения
→ интеграционный слой
→ 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

Не так

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

А вот так

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

---

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

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

Не так

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

А вот так

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

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 строится не от технических компонентов, а от изменений клиентского пути.

Не так

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

А вот так

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: упрощение карточки

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

Не так

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

А вот так

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

Что сделать:

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

Метрики:

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

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

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

Не так

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

А вот так

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

Метрики:

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

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

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

Не так

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

А вот так

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

Метрики:

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

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

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

Не так

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

А вот так

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

Метрики:

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

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

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

Не так

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

А вот так

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

Метрики:

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

---

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

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

Не так

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

А вот так

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

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. Ближайшие задачи

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 должен быть переработан в документ:

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. Итоговая формулировка

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

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

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

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

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

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