Пример SJM — омниканальный переход

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

Назначение карты

Показать, как каналы должны работать как единый сервис: клиент не должен повторять данные, объяснять историю или получать разные ответы в разных точках входа.

Границы процесса

Старт

Клиент начинает запрос в цифровом канале.

Завершение

Запрос решён или клиент получил понятный следующий шаг.

Что не входит в карту

• Конкретные внутренние роли и системы без подтверждённого evidence.
• Детальные SLA по конкретным каналам.
• Технические протоколы интеграции каналов.

Слои карты

Этап	Действие клиента	Frontstage	Backstage / системы	Handoff	Риск	Метрики
1. Приложение	Пытается решить вопрос самостоятельно	Экран, FAQ, чат	Инициация сессии, logging контекста	Контекст обращения формируется	Ошибка, непонятная инструкция	Self-service completion, drop-off
2. Поддержка	Обращается к сотруднику	Чат или звонок	CRM, система обращений, история операций	Сотрудник получает историю и статус	Клиент повторяет объяснение	FCR, время ответа
3. Отделение	Приходит по инструкции	Сотрудник видит маршрут и необходимые данные	CRM, identity verification, локальные системы	Передача результата обратно в общий контекст	Клиента отправляют по кругу	Доля повторных визитов, время решения
4. Завершение	Получает итог	Уведомление в удобном канале	Единый статус в системе обращений	Все каналы показывают единый статус	Расхождение статусов	Reopen rate, обращения по статусу

Основной сценарий

Клиент пробует решить вопрос самостоятельно в приложении. Если не получается — обращается к оператору поддержки с уже известным контекстом. При необходимости — доходит до отделения, где сотрудник видит полный маршрут и не требует повторного объяснения.

flowchart TD
    A[Клиент открывает приложение] --> B{Решаема задача самостоятельно?}
    B -->|Да| C[Клиент решает в self-service]
    B -->|Нет| D[Переход в поддержку]
    D --> E{Сотрудник видит контекст?}
    E -->|Да| F[Поддержка решает вопрос]
    E -->|Нет| G[Клиент повторяет объяснение]
    G --> F
    F --> H{Требует очного визита?}
    H -->|Нет| I[Ответ в канале]
    H -->|Да| J[Направление в отделение]
    J --> K{Сотрудник отделения видит маршрут?}
    K -->|Да| L[Вопрос решён в отделении]
    K -->|Нет| M[Клиент объясняет заново]
    M --> L
    L --> N[Статус обновлён во всех каналах]
    C --> N
    I --> N

Исключения и ошибки

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

Узкие места

• Контекст из приложения не передаётся оператору поддержки.
• Нет единого идентификатора сессии клиента между каналами.
• Отделение работает с другой системой или изолированной очередью.
• Уведомление о результате не приходит в канал, где клиент ожидает ответа.
• Статус обращения обновляется только в одном канале.

Checkpoints

• Какой канал выбрал клиент для ответа?
• Сохраняется ли контекст при каждом handoff?
• Не требуется ли повторно передавать уже имеющиеся данные?
• Доступен ли путь клиенту с ограничениями (доступность офиса, цифровые барьеры)?
• Как выглядит recovery, если отделение не может завершить сценарий?
• Единый ли статус видят все каналы после закрытия вопроса?

Tooling и сопровождение

Инструмент	Что должен поддерживать	Что проверить
CRM / система обращений	единый профиль и история по всем каналам	видит ли оператор поддержки историю из приложения
Self-service канал	логирование действий клиента, точка handoff	передаётся ли контекст при переходе на живого сотрудника
Система уведомлений	подтверждение в предпочтительном канале, статус после визита	получает ли клиент уведомление о закрытии независимо от канала
Система отделения	доступ к маршруту и истории обращения	может ли сотрудник продолжить, а не начать заново
Мониторинг	доля повторных объяснений, reopen rate, handoff gaps	есть ли метрика потери контекста при переходе канала

Тестовый слой

Проверка	Что подтвердить	Evidence
Требования	handoff, контекст, статус и уведомления описаны проверяемо	Тест-анализ требований сервиса
Чек-лист	есть self-service success, channel switch, repeat explanation, branch failure cases	Чек-листы и тест-кейсы сервиса
Accessibility	путь доступен клиенту без возможности визита в отделение	ручная проверка альтернативных веток
Defect report	потеря контекста, расхождение статусов, неверный канал уведомления — отдельные дефекты	Дефекты сервиса и RCA
Regression	после изменения интеграций, системы уведомлений или CRM повторяются handoff-проверки	regression set, QA report

Quick wins

• Передавать в поддержку последний экран или действие клиента из приложения.
• Добавить видимый клиенту идентификатор обращения при переходе на поддержку.
• Убедиться, что статус обращения одинаков в приложении и у оператора.
• Уточнять предпочтительный канал уведомления при первом обращении.
• Давать клиенту понятную инструкцию, если отделение не может решить вопрос.

Системные улучшения

• Ввести единый session context, видимый во всех каналах сотрудниками и системами.
• Настроить handoff-события с передачей последнего статуса и действий клиента.
• Обеспечить доступ сотрудника отделения к системе обращений, а не только к CRM.
• Ввести контроль handoff-gap: когда контекст потерян, фиксировать как инцидент.
• Связать reopen rate с причинами и каналами для анализа recurring проблем.

Вопросы для уточнения

• Что именно передаётся оператору при переходе из приложения?
• Какова доля обращений, где клиент повторяет уже данную информацию?
• Может ли сотрудник отделения продолжить обращение, начатое онлайн?
• В каком канале клиент предпочитает получать ответ?
• Как часто статус расходится между приложением и поддержкой?
• Какие причины reopen связаны с переходом между каналами?

Связанные материалы

• SJM — accessibility и inclusive design
• SJM — privacy, compliance и customer harm
• Метрики для SJM
• Тестирование и качество сервисов
• Тест-анализ требований сервиса
• Дефекты сервиса и RCA

Вывод

Омниканальность — это не набор каналов, а сохранение клиентского контекста между ними. SJM для этого сценария показывает, где разрыв в handoff превращается в повторное объяснение, круговую маршрутизацию и потерю доверия.