Пример SJM — onboarding и KYC

Учебная карта для открытия продукта новому клиенту. Конкретные KYC-требования, способы идентификации и состав данных зависят от продукта и юрисдикции: source_required.

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

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

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

Старт

Клиент выбирает продукт и начинает заявку.

Завершение

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

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

Конкретные правила риск-модели и score-алгоритмы.
Внутренние названия систем.
Детальная юридическая обработка спорных решений.

Слои карты

Этап	Действие клиента	Frontstage	Backstage / системы	Условия и ошибки	Метрики
1. Старт	Выбирает продукт	Описание продукта, требования, CTA	Инициация заявки	Непонятные условия, недоступная форма	Conversion, drop-off
2. Данные	Заполняет форму	Поля, подсказки, валидация	Сохранение черновика, проверки полноты	Лишние поля, повторный ввод, ошибка без объяснения	Completion rate, время заполнения
3. Подтверждение	Подтверждает данные и личность	Понятный статус шага	Идентификация, маршрутизация проверки	Тайм-аут, невозможность продолжить, ручная ветка	Доля успешных проверок, доля ручной обработки
4. Решение	Ожидает результат	Статус и следующий шаг	Формирование результата	Долгое ожидание, неясный отказ, нет recovery	Время решения, обращения по статусу
5. Завершение	Получает доступ или инструкцию	Подтверждение, доступные каналы помощи	Активация продукта или follow-up	Расхождение статусов, неуспешное уведомление	Activation rate, повторные обращения

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

Клиент выбирает продукт, заполняет форму с данными, проходит идентификацию и получает автоматическое решение. Если данных достаточно и проверка прошла — клиент сразу получает доступ.

flowchart TD
    A[Клиент начинает заявку] --> B[Форма сбора данных]
    B --> C{Данные полны?}
    C -->|Нет| D[Уточняющий запрос клиенту]
    D --> B
    C -->|Да| E[Идентификация и проверка]
    E --> F{Автоматическое решение}
    F -->|Одобрено| G[Активация продукта]
    F -->|Требуется ручная проверка| H[Ручная обработка]
    F -->|Отказ| I[Клиент получает объяснение]
    H --> G
    H --> I
    G --> J[Клиент получает доступ]

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

Клиент не понял требования к документам.
Форма выдаёт ошибку без объяснения причины.
Идентификация зависла или вернула технический тайм-аут.
Заявка направлена в ручную обработку без сроков и понятного статуса.
Решение отличается в разных каналах клиента.
Клиент получил отказ без возможности подать уточнённую заявку.

Узкие места

Избыточные поля формы, особенно повторный ввод уже известных данных.
Отсутствие сохранения черновика при тайм-ауте или прерывании.
Непрозрачный статус ручной проверки.
Нет понятного recovery для прерванной заявки.
Разрыв между решением системы и коммуникацией клиенту.

Сквозные checkpoints

Privacy: нужны ли все поля и понятна ли цель обработки данных?
Accessibility: доступна ли форма с клавиатуры, понятны ли ошибки и тайм-ауты?
Customer harm: может ли клиент неверно понять условия, статус или причину отказа?
Handoff: сохраняется ли контекст при переходе на ручную проверку?
Service recovery: может ли клиент продолжить прерванную заявку без повторного ввода?

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

Инструмент	Что должен поддерживать	Что проверить
Форма заявки / digital channel	черновик, понятная валидация, доступность	не приходится ли клиенту вводить данные повторно
CRM / клиентский профиль	предзаполнение из существующих данных, история заявок	видит ли ручная обработка полный контекст
Система идентификации	статусы, тайм-ауты, маршрут на ручную проверку	корректно ли передаются признаки прерванной проверки
Система уведомлений	промежуточные и итоговые статусы, информация о сроках	получает ли клиент уведомление при смене статуса
Отчётность и мониторинг	conversion funnel, drop-off, время решения, доля ручной обработки	можно ли отследить, где клиенты прерывают заявку

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

Проверка	Что подтвердить	Evidence
Требования	форма, статусы, условия идентификации и критерии ошибок описаны проверяемо	Тест-анализ требований сервиса
Чек-лист онбординга	есть positive, incomplete, timeout, manual review и rejection cases	Чек-листы и тест-кейсы сервиса
Accessibility	форма проходима с клавиатуры, ошибки понятны скринридеру	ручная проверка или axe-отчёт
Defect report	тайм-аут, непонятный отказ, нет recovery — каждый случай отдельный дефект	Дефекты сервиса и RCA
Regression	после изменения полей, маршрутизации или условий повторяются критичные проверки	regression set, QA report

Quick wins

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

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

Ввести предзаполнение формы из данных существующего клиентского профиля.
Обеспечить сохранение состояния заявки при тайм-ауте сессии.
Настроить SLA и контроль очереди ручной обработки.
Связать повторяющиеся причины отказов с анализом продуктовых и compliance-условий.
Обновлять SJM и условия продукта после изменения регуляторных требований.

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

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

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

Вывод

Онбординг и KYC — зона повышенного риска customer harm: клиент мотивирован, но уязвим перед непрозрачным статусом, непонятным отказом и отсутствием recovery. SJM помогает видеть не только технический маршрут, но и каждую точку, где клиент теряет понимание происходящего.