سرویس بلوپرینت یا Service Blueprint نقشه‌ای است که اقدام مشتری را به کارهای قابل مشاهده، کار پشت صحنه و فرایندهای پشتیبان وصل می‌کند. وقتی مشتری پاسخ «در حال بررسی است» می‌شنود، این نقشه نشان می‌دهد پشت آن جمله چه واحد، داده و تصمیمی لازم است تا خدمت واقعاً جلو برود.
نقشه سفر مشتری بیشتر بر تجربه و مسیر مشتری تمرکز می‌کند؛ بلوپرینت رابطه آن تجربه با سازوکار ارائه خدمت را هم نمایش می‌دهد. تعریف Nielsen Norman Group اقدام مشتری، فعالیت جلوی صحنه، پشت صحنه و فرایندهای پشتیبان را از اجزای مهم این نقشه می‌داند. طرح زیر مثال اصیل آموزشی است، نه تصویر عملیات واقعی اپرا.
دامنه را به یک نتیجه قابل مشاهده محدود کنید
موضوع «کل تجربه مشتری» برای شروع خیلی بزرگ است. به جای آن، یک مسیر دارای ابتدا و انتها انتخاب کنید؛ مثلاً درخواست تغییر نشانی سفارش تا دریافت پاسخ قطعی درباره امکان تغییر. موفقیت این سناریو، گفتن «ثبت شد» نیست؛ مشتری باید بداند تغییر واقعاً انجام شده یا به چه علت ممکن نیست.
نماینده پاسخ‌گویی، عملیات و مالک سامانه را در رسم نقشه مشارکت دهید. آنچه امروز واقعاً اتفاق می‌افتد را از نسخه مطلوب جدا کنید. اگر مرحله‌ای را نمی‌دانید، روی نقشه علامت سؤال بگذارید؛ خانه خالی را با یک گردش کار ایده‌آل پر نکنید.
مثال چهار لایه برای تغییر نشانی
| لایه | دریافت درخواست | بررسی امکان | اعلام نتیجه |
|---|---|---|---|
| اقدام مشتری | گفتن شناسه و نشانی تازه از مسیر مجاز | انتظار برای پاسخ | دریافت تأیید یا دلیل عدم امکان |
| جلوی صحنه | بازخوانی درخواست، بدون قول تغییر قطعی | خبر وضعیت در موعد توافقی | بیان نتیجه ثبت‌شده |
| پشت صحنه | یافتن سفارش مجاز | کنترل مرحله ارسال و اختیار تغییر | ثبت تغییر یا تصمیم رد با علت |
| پشتیبان | ثبت درخواست با شناسه | دسترسی به وضعیت معتبر انبار و ارسال | رسید ثبت و مسیر اطلاع‌رسانی |
بین جلوی صحنه و پشت صحنه، مرز دید مشتری را مشخص کنید. مشتری لازم نیست اصطلاحات داخلی یا تمام رفت‌وبرگشت‌ها را ببیند، ولی نتیجه‌ای که می‌شنود باید به یک عمل واقعی تکیه کند. اگر سامانه فقط درخواست را ثبت کرده و هنوز تغییر نداده، متن پاسخ هم باید همان را بگوید.
وابستگی را به مسئول و شاهد وصل کنید
کنار هر پیکان بنویسید چه چیزی تحویل می‌شود: شناسه، وضعیت، اجازه یا تصمیم. «ارسال به انبار» کافی نیست؛ چه سؤال دقیقی از انبار پرسیده شده و چه کسی جواب را برمی‌گرداند؟ اگر انتقال مسئولیت روشن نیست، از الگوی مالک رسیدگی میان واحدها کمک بگیرید.
روی مرحله بررسی، یک حالت شکست بگذارید: وضعیت ارسال فعلاً در دسترس نیست. در این حالت پاسخ‌گو نباید حدس بزند تغییر ممکن است. مسیر جایگزین می‌تواند ارجاع ثبت‌شده و اعلام وضعیت بعدی در محدوده توان واقعی شرکت باشد. فرم اطلاعات پیش از ارجاع برای کامل‌کردن داده ورودی مفید است، ولی جای مالک تصمیم را نمی‌گیرد.
با نقشه چه چیزی را بهبود دهیم؟
نخست نقاط تکرار داده، انتظار بی‌مالک و وعده بدون شاهد را علامت بزنید. یک مورد را انتخاب کنید: برای نمونه، رسید ثبت نتیجه به پاسخ‌گو نمی‌رسد. اصلاح ارتباط همین مرحله می‌تواند مشخص‌تر از تعویض کل کانال باشد. پس از تغییر، چند پرونده مجاز را از ابتدا تا نتیجه دنبال کنید؛ کامل‌بودن نقشه روی کاغذ، اجرای واقعی آن را ثابت نمی‌کند.
برای سناریوی پاسخ‌گویی تلفنی، مسیر پشتیبانی مشتری اپرا را ببینید. نقشه موجود و نقاطی را که قرار است پاسخ‌گو انجام دهد به تیم نشان دهید؛ دسترسی به وضعیت، اختیار تغییر و ثبت رسید باید برای پروژه بررسی شوند. افزودن هوش مصنوعی به جلوی صحنه، وابستگی‌های حل‌نشده پشت صحنه را خودکار برطرف نمی‌کند.