Спроектируйте целую систему сервиса, а не только интерфейс: покажите, как клиентские действия, сотрудники, партнёры, правила и технологии создают каждое взаимодействие.
За одну минуту
Service Blueprint отображает один ограниченный сценарий по связанным слоям:
- действия клиента и его outcome;
- frontstage — видимые люди и интерфейсы;
- backstage — скрытая, но необходимая работа;
- support processes и systems — команды, партнёры, правила, данные и технологии;
- physical/digital evidence — то, что клиент видит, получает или сохраняет.
Line of interaction отделяет клиента от контакта с провайдером, line of visibility — видимое обслуживание от backstage. Blueprint связывает experience и delivery mechanisms, но не доказывает, что нарисованный шаг реально выполняется.
Лучше всего: для redesign конкретного end-to-end service scenario.
Не подходит: когда нужно исследовать только experience, измерить только process flow или ещё не определены клиент и границы.
Какую проблему решает
Хороший интерфейс может скрывать broken hand-offs, спорную политику, невидимый ручной труд и потерю клиентского контекста. Customer Journey Map описывает опыт; внутренний process map часто не показывает обещание клиенту. Blueprint соединяет эти стороны там, где сервис производится.
Когда использовать метод
- сервис проходит через клиента, канал, сотрудника и систему;
- видимый сбой начинается в backstage;
- автоматизация меняет обещание или recovery;
- нужен общий current-state перед redesign;
- важны ожидание, hand-offs, evidence и исключения;
- один сценарий и сегмент можно проверить наблюдениями и logs.
Когда не использовать
- как карту всей организации;
- вместо customer research и Customer Journey Mapping;
- вместо SIPOC, если спорны границы процесса;
- вместо Value Stream Mapping, если решение о time, inventory и queues;
- для выдачи ideal state за наблюдаемую реальность;
- для удаления контроля только потому, что клиент его не видит.
Входные данные
- customer segment, trigger, normal completion и exceptions;
- наблюдаемые действия клиента и желаемый outcome;
- channels, artefacts и frontstage interactions;
- backstage roles, systems, partners, policies и data;
- evidence по waiting, failures, demand и recovery;
- service measures и owners.
Пошаговый процесс
1. Ограничьте сценарий
Назовите клиента, потребность, trigger, completion и exclusions. «Записаться и прийти на приём» подходит; «опыт здравоохранения» — нет.
2. Разложите действия клиента по времени
Используйте наблюдаемое поведение. Включите поиск, ожидание, передачу evidence, изменение решения и recovery.
3. Добавьте physical и digital evidence
Покажите экраны, сообщения, документы, среду и подтверждения, через которые клиент понимает статус и обещание.
4. Отобразите frontstage
Под каждым customer action разместите видимый ответ сотрудника, партнёра, устройства или интерфейса. Различайте human и automated contact.
5. Проведите line of visibility
Ниже находится скрытая работа. Решите, какой backstage event должен стать видимым статусом, объяснением, consent или recovery information.
6. Отобразите backstage
Добавьте решения, validation, preparation, hand-offs, rework и exception work. Не скрывайте ожидание.
7. Свяжите support layer
Привяжите policies, data, integrations, suppliers, workforce и controls к конкретному backstage action.
8. Отметьте failure points
Зафиксируйте probable failures, необратимые моменты, capacity constraints, control gates и common dependencies. Отделите факт от design hypothesis.
9. Спроектируйте future state
Одновременно меняйте service promise и delivery system. Опишите действия, evidence, видимость для клиента и recovery. Проверьте accessibility и non-digital path.
10. Проведите pilot
Пройдите normal и exception scenarios. Измеряйте end-to-end outcome, waiting, rework, abandonment и recovery, а не только frontstage speed.
AI и автоматизация
AI может кластеризовать evidence, черновиком собирать blueprint из разрешённых logs, сравнивать current/future state и находить разрывы. Он не должен выдавать сгенерированное поведение за research, угадывать emotions или protected traits, раскрывать конфиденциальный backstage, удалять gate или переносить риск из frontstage в невидимую работу.
Визуальная модель
Практический пример
AI-помощник клиники быстро предлагает слот, но referral ещё не проверен, accessibility request теряется в integration, а rescheduling удаляет исходный контекст. Customer lane: поиск → запрос → referral/accessibility → выбор → usable confirmation. Frontstage: assistant и booking interface. Backstage: validation, eligibility, schedule release и routing. Support: clinical system, identity, referral rules и staffing.
Recovery сохраняет запрос, объясняет сбой, передаёт authorised coordinator, даёт срок ответа и non-AI contact path. Скорость не является успехом, если записью нельзя воспользоваться.
Ожидаемый результат
- bounded current-state blueprint;
- связанные customer, frontstage, backstage и support lanes;
- physical/digital evidence по service moments;
- failure points, waits, dependencies и controls;
- future-state hypothesis и recovery design;
- pilot measures, owners и review triggers.
Ошибки
- Journey map с дополнительными строками, но без delivery mechanisms.
- Внутренняя процедура выдана за customer actions.
- Показан только happy path.
- Systems перечислены без связи с действиями.
- Future state выдан за факт.
- Frontstage ускорен ценой backstage overload.
Чек-лист качества
- Scenario, segment, trigger и completion явны.
- Customer lane основан на evidence.
- Interaction и visibility lines понятны.
- Frontstage, backstage и support связаны.
- Waiting, evidence, controls и recovery видимы.
- Current и future state различаются.
- Есть owners, pilot и review triggers.
Шаблон
| Момент | Действие клиента | Evidence | Frontstage | Backstage | Support | Failure / owner |
|---|---|---|---|---|---|---|
| Этап | Наблюдаемое действие | Что клиент видит | Видимый контакт | Скрытая работа | Policy/system/partner | Риск, recovery и measure |
Проверка понимания
Вопрос: ответ клиенту занимает секунды, но затем работа девять дней ждёт backstage review. Что должен показать blueprint?
Ответ: blueprint обязан показать оба участка, line of visibility, причину ожидания и end-to-end outcome. Скорость интерфейса не равна скорости сервиса.
Связанные методы
- Customer Journey Mapping — experience evidence.
- SIPOC — граница процесса.
- Value Stream Mapping — flow и waiting.
- FMEA — детальный анализ failure modes.
Источники
- Shostack, G. Lynn. “Designing Services That Deliver.” Harvard Business Review, 1984. Статья (откроется в новой вкладке).
- Bitner, Mary Jo, Amy L. Ostrom, Felicia N. Morgan. “Service Blueprinting.” California Management Review, 2008. DOI (откроется в новой вкладке).
- Stickdorn, Marc et al. This Is Service Design Doing. O’Reilly, 2018.