Сервисный план (Service Blueprint) — это карта сервиса изнутри: мы описываем видимые клиенту точки контакта и невидимые внутренние процессы, которые их обеспечивают. Заказчик получает полную схему сервиса с выявленными разрывами между обещанием и реализацией и рекомендациями по их устранению.
Кому нужна услуга
Компании, где клиенты жалуются, а причина не находится на уровне фронт-офиса: проблема скрыта во внутренних процессах.
Руководители сервисных подразделений, у которых нет единой картины: каждый отдел видит только свой участок.
Продуктовые команды, запускающие или перерабатывающие сервис и не понимающие, какие внутренние процессы его поддерживают.
Операционные директора, которые хотят найти узкие места на стыке подразделений и систем.
Компании после реорганизации или внедрения новой ИТ-системы, где клиентский опыт просел, но причины неочевидны.
Заказчики, готовящиеся к автоматизации или цифровизации сервиса и нуждающиеся в честной схеме «как есть».
Что нужно от вас на входе
Описание сервиса и его границ: что именно картируется. Без чётких границ blueprint расползётся и потеряет практическую ценность
Доступ к сотрудникам фронт-офиса и бэк-офиса для интервью. Внутренние процессы редко описаны документально — их нужно собирать из практики
Существующие регламенты, инструкции, схемы процессов (если есть). Позволяют сопоставить заявленное «как должно быть» с реальным «как есть»
Данные о точках контакта с клиентом: каналы, обращения, жалобы. Дают объективную картину, где клиент сталкивается с сервисом
Список вовлечённых подразделений и ИТ-систем. Нужны для картирования зон поддержки и выявления системных разрывов
Согласованный ответственный за проект со стороны заказчика. Обеспечивает доступ к людям и валидацию результатов на каждом этапе
Комплект документов, который вы получаете
Описание услуги — наш стандарт качества: заранее видно, какие документы вы получите и зачем нужен каждый.
Документ | Формат | Для чего нужен |
|---|---|---|
Карта сервисного плана (Service Blueprint) | Схема в BPMN/табличном виде с дорожками: физические доказательства, действия клиента, фронт-офис, бэк-офис, процессы поддержки | Единая картина сервиса, понятная и бизнесу, и операционке |
Реестр точек контакта | Таблица: канал, этап, действие клиента, ответственное подразделение | Быстрый обзор клиентского пути и зон ответственности |
Карта разрывов (gaps) | Таблица: разрыв, где проявляется, на что влияет, приоритет | Ранжированный список проблем, который можно брать в работу |
Рекомендации по устранению разрывов | Описания с привязкой к конкретным этапам сервисного плана | Перевод диагностики в конкретные управленческие решения |
Схема процессов поддержки | BPMN-диаграмма или ментальная карта | Показать, какие внутренние процессы обеспечивают клиентский опыт |
Презентация результатов | Слайды с ключевыми выводами и визуализацией карты | Материал для защиты результатов перед руководством |
План внедрения рекомендаций (черновик) | Список инициатив с ответственными и приоритетами | Стартовая точка для перевода разрывов в проектную работу |
План выполнения услуги
Этап | Что делаем | Результат этапа |
|---|---|---|
1. Бриф и согласование границ | Уточняем, какой сервис картируется, какие каналы и подразделения входят, кто заказчик результата | Согласованный скоуп, план работ, список интервьюируемых |
2. Сбор данных | Интервью с фронт-офисом и бэк-офисом, изучение регламентов, обращений и жалоб | Сырой материал: описания действий, проблем, обходных путей |
3. Картирование действий клиента и точек контакта | Описываем путь клиента этап за этапом, фиксируем каналы и физические доказательства | Видимая часть сервисного плана |
4. Картирование фронт-офиса | Описываем действия сотрудников, с которыми клиент взаимодействует напрямую | Линия видимости: что делают люди на переднем крае |
5. Картирование бэк-офиса и процессов поддержки | Описываем внутренние процессы, системы и подразделения, обеспечивающие фронт-офис | Полная схема «за кулисами» сервиса |
6. Выявление разрывов | Сопоставляем обещание (что видит клиент) и реализацию (что реально происходит внутри) | Ранжированный реестр разрывов с указанием причин |
7. Разработка рекомендаций | Формулируем, что и где нужно изменить: процесс, регламент, систему, роль | Список рекомендаций с привязкой к этапам плана |
8. Валидация с заказчиком | Презентуем карту и разрывы, собираем обратную связь и уточняем приоритеты | Согласованная финальная версия сервисного плана |
9. Передача результата | Передаём карту, реестр разрывов, рекомендации и черновик плана внедрения | Пакет документов, готовый к использованию внутри компании |
Чек-лист качества
Перед сдачей исполнитель проверяет результат по этому списку:
Все этапы клиентского пути покрыты, ни один не пропущен
Каждая точка контакта привязана к конкретному подразделению и роли
Внутренние процессы описаны на уровне, достаточном для принятия решений
Разрывы сформулированы как конкретные расхождения, а не общие жалобы
У каждого разрыва указано, на каком этапе он проявляется
Рекомендации привязаны к разрывам и этапам плана, а не висят в воздухе
Схема читается человеком, не участвовавшим в проекте
Терминология согласована с заказчиком (названия подразделений, систем, ролей)
Все интервьюируемые стороны были услышаны, конфликтующие версии отражены
Финальная версия прошла валидацию с ответственным со стороны заказчика
Критерии приёмки работ
Работа считается выполненной, когда выполнены все пункты. Критерии фиксируем вместе с расчётом — до начала работ.
Полнота карты. Заказчик проверяет, что все заявленные каналы и этапы сервиса отражены и нет пропущенных участков
Читаемость схемы. Сотрудник, не участвовавший в проекте, может объяснить по карте путь клиента и внутренние процессы
Практичность реестра разрывов. Каждый разрыв можно взять в работу: есть этап, причина, зона ответственности
Согласованность рекомендаций. Рекомендации привязаны к разрывам и не противоречат друг другу
Согласование с ответственными. Руководители подразделений подтверждают, что карта отражает реальность
Готовность к использованию. Пакет документов можно передать в работу без дополнительной переработки
На проверку результата — 3 рабочих дня. Замечания в рамках согласованного объёма устраняются без доплаты.
После сдачи: результат остаётся рабочим инструментом
Все материалы остаются в вашем пространстве OrgDevTools — их можно дорабатывать без исполнителя:
Процессы (BPMN). Сервисный план переносится в BPMN-модели: внутренние процессы поддержки описываются формально и становятся основой для регламентации
База знаний и регламенты. Реестр разрывов и рекомендации оформляются как регламенты и рабочие инструкции, доступные сотрудникам
Проекты и задачи. Рекомендации по устранению разрывов превращаются в задачи с ответственными и сроками
Цифровой двойник. Карта сервиса поддерживается в актуальном состоянии: изменения в процессах отражаются в цифровом двойнике компании
AI-советник OrgDevTools. AI-советник OrgDevTools помогает команде после сдачи: отвечает на вопросы по регламентам и базе знаний, подсказывает, как действовать в спорных ситуациях на конкретном этапе сервиса, и напоминает о зафиксированных договорённостях.
Чем эта услуга не является
Внедрение рекомендаций и управление изменениями — это отдельная услуга
Автоматизация процессов и настройка ИТ-систем
Обучение сотрудников фронт-офиса и бэк-офиса
Юридическая экспертиза регламентов и договоров
Стоимость и сроки
Стоимость рассчитывается после брифа: зависит от масштаба компании, числа подразделений и глубины проработки. Расчёт и состав работ фиксируем до начала — без сюрпризов в конце.
Частые вопросы об услуге «Разработка сервисного плана (Service Blueprint)»
Чем сервисный план отличается от карты клиентского пути (CJM)?
CJM показывает, что делает и чувствует клиент. Сервисный план идёт дальше: он раскрывает, какие внутренние процессы, подразделения и системы обеспечивают каждую точку контакта, и где между ними возникают разрывы.
Сколько времени занимает разработка?
Ориентировочно зависит от масштаба сервиса, числа подразделений и доступности сотрудников для интервью. Точная оценка даётся после брифа.
Сколько стоит услуга?
Стоимость рассчитывается после брифа: она зависит от границ сервиса, количества интервью и глубины проработки. Фиксированной цены до брифа нет.
Нужно ли нам самим описывать процессы до начала работ?
Нет. Мы собираем информацию через интервью и изучение существующих материалов. Если регламенты есть — используем их; если нет — это не блокирует работу.
Кто должен участвовать с нашей стороны?
Ответственный за проект и представители подразделений, вовлечённых в сервис: фронт-офис, бэк-офис, ИТ. Без доступа к ним карта будет неполной.
Что мы получим в итоге?
Полную карту сервиса с видимыми и невидимыми процессами, реестр разрывов между обещанием и реализацией, рекомендации по устранению и черновик плана внедрения.
Заказать услугу
Опишите задачу в заявке ниже — уточним детали, пришлём расчёт и план работ.