Чтобы построить карту сервиса с ИИ, зафиксируйте границы сервиса и подтверждённый путь клиента, затем расположите согласованными слоями действия клиента, видимые взаимодействия, внутреннюю работу, поддерживающие процессы, системы, доказательства, передачи и владельцев. Держите предположения явно отделёнными: правдоподобная история о внутренней работе — не наблюдаемый процесс.

Ответственный процесс работы с ИИ помогает упорядочить записи и найти пробелы. Реальную работу подтверждают исполнители и владелец сервиса.

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

Карта пути клиента описывает его опыт; карта сервиса связывает этот опыт с организацией услуги.

Сначала зафиксируйте область сервиса, актёра, сценарий, канал, начало и конец.

Линия видимости отделяет воспринимаемое клиентом от внутренней работы.

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

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

Что меняется, когда нужно построить карту сервиса с ИИ?

Карта опыта или пути клиента показывает, что пользователь делает, с чем сталкивается, о чём думает и что ему нужно во времени. GOV.UK советует командам строить карты опыта на основе исследований и использовать их, чтобы понимать опыт целиком, а не отдельные точки контакта.［1］ Карта сервиса добавляет операционные слои, которые создают эти точки контакта: видимых сотрудников или интерфейсы, внутренние действия, поддерживающие процессы, системы, правила, доказательства, ответственность и передачи.

Вопрос	Карта пути клиента	Карта сервиса
Фокус	Цель и опыт пользователя	Механизм доставки сервиса
Источники	Интервью, наблюдения, поведение	Доказательства пути плюс процессные, системные, политические и операционные записи
Слои	Этапы, действия, точки контакта	Клиент, видимые и внутренние действия, поддержка, системы, сбои
Граница	Целостная проблема пользователя	Определённый объём предоставления сервиса
Владельцы решений	Исследовательская и продуктовая команды	Владельцы сервиса, операций, технологий, политики и поддержки

Не заменяйте карту пути клиента внутренней блок-схемой. Используйте путь клиента как один из входов с доказательствами, а карту сервиса — чтобы связать его с предоставлением услуги.

Как определить границы и доказательства?

Шаг 1. Ограничьте сервис

Определите один сценарий, актёра, набор каналов, триггер, результат и временную границу. «Клиентская поддержка» слишком широка. «Существующий владелец аккаунта сообщает о незнакомом списании через веб-чат, получает решение по обращению и видит обновление аккаунта» — проверяемая формулировка.

Запишите:

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

Руководство GOV.UK о решении проблемы целиком предлагает командам понимать, чего в итоге добивается пользователь, включая взаимодействия за пределами сервиса одной организации.［2］ Используйте этот широкий взгляд, чтобы найти зависимости, но не расширяйте одну карту незаметно до всех возможных путей.

Шаг 2. Создайте реестр доказательств

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

Разделяйте четыре состояния:

Observed — напрямую подтверждено пользовательскими или операционными доказательствами.
Confirmed — проверено ответственным владельцем процесса.
Assumption — правдоподобно, но ждёт подтверждения.
Conflict — источники расходятся или практики различаются.

ИИ не должен повышать статус предположения только потому, что его повторяют несколько человек: повторение может отражать распространённое убеждение, а не фактическое поведение системы. Прежде чем передавать материал модели, минимизируйте персональные и конфиденциальные данные: NIST отмечает риски приватности, конфабуляции, целостности информации и взаимодействия человека с ИИ.［4］

Как отразить действия клиента и видимую часть сервиса?

Шаг 3. Постройте ось действий клиента

Начните с действий клиента, подтверждённых доказательствами о пути. В каждую колонку поместите одно наблюдаемое действие или значимое ожидание. Используйте глаголы «отправляет», «ждёт», «получает», «проверяет» или «повторяет», а не широкие фазы вроде «вовлечения».

Для каждой колонки запишите триггер, действие, канал, ожидаемый результат, ID доказательства, неопределённость и следующее событие. Если исследование их показывает, включайте отказы от задачи, повторные попытки, смену канала и ожидание: такие моменты часто раскрывают операционные проблемы, скрытые схемой счастливого пути.

Если карты пути клиента нет, не просите ИИ придумать её как каркас. Проведите или найдите подходящее исследование и создайте прослеживаемую карту пути. Предварительная карта сервиса может перечислять явные пробелы исследования, но не должна выдавать воображаемое поведение за факт.

Шаг 4. Добавьте видимые действия над линией видимости

Видимые действия — то, что клиент может воспринять: разговор с сотрудником, сообщение, форма, статус, физический объект, уведомление или видимый отклик интерфейса. Располагайте их под шагом клиента, который они поддерживают.

Для каждой клетки видимой части запишите:

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

Проведите линию взаимодействия между действиями клиента и видимыми действиями, а линию видимости — под слоем видимых действий. Всё ниже этой линии клиент прямо не видит, хотя результат может проявиться позже.

Не выводите действие сотрудника из сообщения для клиента. Уведомление «одобрено» не доказывает, какая команда, правило, система или проверка его создали. Оставляйте это неизвестным, пока операционные доказательства не подтвердят механизм.

Как отразить внутреннюю работу и поддержку?

Шаг 5. Не выдумывайте внутреннюю работу

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

Запрос к ИИ может надёжно удерживать эту границу:

Расположи только предоставленные доказательства в отдельных слоях клиента,
видимых взаимодействий, внутренней работы, поддержки, систем, доказательств
и отказов. Не додумывай скрытые действия, владельцев, системы, правила,
порядок, время и причинность. Неподтверждённое пометь Assumption, конфликт
источников — Conflict. Верни несвязанные доказательства и пропущенные передачи.

Пример Министерства образования Великобритании показывает, как карта сервиса делает межкомандную работу видимой.［3］Используйте примеры, чтобы освоить метод, а не как доказательство, что в вашей организации те же слои и роли.

Шаг 6. Добавьте поддержку, системы и правила

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

В системном слое храните приложения, записи, сообщения, документы, физические объекты и контрольные доказательства. Авторитетную систему называйте только после проверки. Канал не равен системе-источнику: письмо может сообщать об изменении, тогда как состояние хранит платформа обращений.

Для политики укажите владельца, версию, применимость и точное местоположение; старый текст процедуры не становится действующим автоматически. Карта заинтересованных сторон помогает найти участников, а матрица RACI — закрепить ответственность, когда конкретное решение или результат требует явной подотчётности.

Как показать передачи и пути восстановления?

Шаг 7. Сделайте передачи явными

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

Запишите:

Поле передачи	Вопрос для проверки
Отправитель и получатель	Названы обе ответственные стороны?
Триггер	Какое наблюдаемое событие запускает передачу?
Содержимое	Какие данные, объект или состояние переходят?
Приёмка	Как получатель проверяет полноту и корректность?
Очередь и время	Где работа ждёт, истекает или приходит вне порядка?
Сигнал ошибки	Как обнаруживают потерю, отказ, дублирование?
Владелец восстановления	Кто повторяет, исправляет, эскалирует, уведомляет клиента?
Доказательство	Какая запись подтверждает событие?

Ищите потерянные выходы, нескольких владельцев, скрытые очереди, ручное копирование, смену канала и отсутствие приёмки. Это находки карты, а не доказательство первопричины.

Шаг 8. Покажите отказ и восстановление

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

Записывайте видимый клиенту симптом отдельно от гипотезы о внутреннем сбое. Затем зафиксируйте обнаружение, сдерживание, восстановление, коммуникацию, эскалацию, владельца и доказательства. Не называйте первопричину, пока её не подтвердит расследование.

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

Как проверить и улучшить карту сервиса?

Шаг 9. Проведите межфункциональный разбор

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

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

Шаг 10. Управляйте улучшениями

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

Контрольный список

Итоги

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

Часто задаваемые вопросы (FAQ)

Можно ли начать без карты пути клиента?

Можно начать с предварительной структуры, но действия клиента всё равно требуют доказательств из исследований. Записывайте пробелы и не превращайте предполагаемое поведение в готовую карту пути.

Сколько слоёв нужно?

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

Где проходит линия видимости?

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

Может ли ИИ вывести внутреннюю работу из карты пути клиента?

Он может предложить вопросы, но факты подтверждают исполнители, записи, системы и владельцы политики.

Карта сервиса — это оргсхема?

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

Насколько подробной должна быть клетка?

До уровня, где видны вход, выход, передача, ожидание, ошибка и владелец. Разделите клетку, если иначе скрываются разные исполнители или правила приёмки.

Каждая точка отказа становится проектом?

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

Когда обновлять карту сервиса?

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

Источники

GOV.UK Service Manual — Creating an experience map — https://www.gov.uk/service-manual/user-research/creating-an-experience-map/
GOV.UK Service Manual — Map and understand a user's whole problem — https://www.gov.uk/service-manual/design/map-a-users-whole-problem
Department for Education — Building a service blueprint — https://design-histories.education.gov.uk/communicating-funding-beta/building-a-service-blueprint
NIST — Artificial Intelligence Risk Management Framework: Generative AI Profile — https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence

Sources checked 6 сентября 2026 г.

Как построить карту сервиса с ИИ, а не карту пути клиента