5.9 سروس ڈیزائن

جائزہ اور محرکات

سروس ڈیزائن اس پوری سروس کو شکل دینے کا عمل ہے جو شخص ہر چینل میں اور وقت کے پورے دورانیے میں تجربہ کرتا ہے، نہ کہ ایک اسکرین یا ایپ۔ جب کوئی پاسپورٹ کی تجدید کرتا ہے، بینک اکاؤنٹ کھولتا ہے، یا ٹوٹی ہوئی اسٹریٹ لائٹ کی رپورٹ کرتا ہے تو وہ آپ کی پروڈکٹ کا تجربہ نہیں کرتا۔ وہ سروس کا تجربہ کرتا ہے: فون کال، ویب سائٹ، ڈاک میں خط، قطار، ای میل جو کبھی نہیں آتی، کیس ورکر جسے اپنی تفصیلات اس نظام میں دوبارہ ٹائپ کرنی پڑتی ہیں جو وہ نہیں دیکھ سکتا جو ویب سائٹ پہلے سے جانتی ہے۔ باب 5.1 انفرادی انٹرفیس ڈیزائن کرنے کا ہنر ڈھکتا ہے۔ سروس ڈیزائن پورے سفر کی طرف اور اس سب کی طرف زوم آؤٹ کرتا ہے جو کاؤنٹر کے پیچھے ہے اور کاؤنٹر کے سامنے کو کام کرنے دیتا ہے۔

“کاؤنٹر کے پیچھے” کا یہ فرق اس کا دل ہے۔ سروس ڈیزائن دنیا کو سامنے کے مرحلے میں بانٹتا ہے، یعنی جو کچھ صارف دیکھتا اور چھوتا ہے، اور پیچھے کے مرحلے میں، یعنی وہ لوگ، نظام، اور عمل جو سروس پہنچاتے ہیں مگر صارف کو نظر نہیں آتے۔ اچھے سامنے کے تجربے ہر وقت ناکام ہوتے ہیں کیونکہ پیچھے کا مرحلہ انہیں سہارا نہیں دے سکتا۔ ایک چمکدار بکنگ فارم جو ایسی اسپریڈ شیٹ میں گرتا ہے جسے کلرک دن میں دو بار دیکھتا ہے وہ سست پیچھے کے مرحلے سے جڑا تیز سامنے کا مرحلہ ہے، اور صارف اس بے میل کو تین دن کی خاموشی کے طور پر محسوس کرتا ہے۔ پوری سروس ڈیزائن کرنے کا مطلب دونوں نصف اور ان کے بیچ کے جوڑ ساتھ ڈیزائن کرنا ہے۔

بڑی ٹیموں کے لیے یہ ناگزیر طور پر تنظیمی مسئلہ ہے۔ سروسز تقریباً ہمیشہ کئی ٹیموں، محکموں، اور نظاموں پر پھیلی ہوتی ہیں، اور ان مالکان کے درمیان کی حدیں ٹھیک وہ جگہ ہیں جہاں صارف کا تجربہ بکھرتا ہے۔ انٹرپرائز ترتیبوں میں ایک گاہک کا سفر فروخت، provisioning، بلنگ، اور معاونت کو پار کر سکتا ہے، ہر ایک کے اپنے ٹولز اور اہداف کے ساتھ اور کوئی پورے کا جوابدہ نہیں۔ حکومت میں داؤ اور اونچے ہیں: زندگی کے واقعے جیسے سوگ یا نئے بچے کا سامنا کرنے والے شخص کو درجن علیحدہ ایجنسیوں سے گزرنا پڑتا ہے، ہر ایک وہی ثبوت مانگتی ہے، کیونکہ سروسز شخص کی ضرورت کی بجائے حکومت کی ساخت کے گرد منظم ہیں۔ سروس ڈیزائن وہ طریقہ ہے جس سے آپ پورے کو اس انسان کے لیے جڑا ہوا بناتے ہیں جو اس کے مرکز میں ہے۔

بنیادی اصول

پوری سروس چینلز اور وقت میں ڈیزائن کریں، ایک اسکرین نہیں۔ صارف کو پروا نہیں کہ آپ کی ٹیم کی حدیں کہاں ہیں۔
سامنے اور پیچھے کا مرحلہ ایک نظام ہے۔ تجربہ اتنا ہی اچھا ہے جتنا اس کے پیچھے کے آپریشنز سہارا دے سکیں۔
ادارہ جاتی چارٹ سروس میں ظاہر ہوتا ہے۔ اگر ٹیمیں الگ تھلگ ہیں تو سروس الگ تھلگ محسوس ہوگی، اس لیے ٹیم کا ڈیزائن اور سروس کا ڈیزائن ساتھ چلیں۔
چینلز اور ٹیموں کے بیچ حوالگیاں وہ جگہ ہیں جہاں سروسز ٹوٹتی ہیں۔ جوڑوں کو اتنے ہی دانستہ ڈیزائن کریں جتنے قدموں کو۔
عملے کے سامنے والے ٹولز سروس کا حصہ ہیں۔ بری کنسول والا مایوس ایجنٹ مایوس گاہک پیدا کرتا ہے۔
سروس کو سرے سے سرے تک ناپیں، صارف کے پہلے ارادے سے ان کے حقیقی نتیجے تک، ایک چینل کی مقامی میٹرک سے نہیں۔
اپنے اندرونی محکموں کی بجائے صارف کے مقصد یا زندگی کے واقعے کے گرد منظم کریں۔

سفارشات

ہر چینل میں گاہک کے سفر کا نقشہ بنائیں

اس حقیقی سفر کا خاکہ بنا کر شروع کریں جو شخص نتیجے تک پہنچنے کے لیے طے کرتا ہے، وسیع تر گاہک کے تجربے کے حصے کے طور پر۔ سفر کا نقشہ وہ مراحل بچھاتا ہے جن سے صارف گزرتا ہے، ضرورت کا پہلی بار احساس ہونے سے اپنے مقصد تک پہنچنے اور اس کے بعد تک، اور ہر مرحلے پر ریکارڈ کرتا ہے کہ وہ کیا کرنے کی کوشش کر رہے ہیں، کیا سوچتے اور محسوس کرتے ہیں، اور کون سے چینل میں ہیں۔ قدر چینلز کو پھیلانے سے آتی ہے: زیادہ تر حقیقی سفر ویب سائٹ، فون لائن، ای میل، ایپ، اور جسمانی مقام کے بیچ چھلانگ لگاتے ہیں، اور بدترین تکلیف ان چینلز کے بیچ خلا میں رہتی ہے، جہاں سیاق کھو جاتا ہے اور صارف کو دوبارہ شروع کرنا پڑتا ہے۔ نقشے کو اپنے مفروضوں کی بجائے تحقیق (باب 5.8) میں جڑیں، کیونکہ جو سفر آپ تصور کرتے ہیں اور جو لوگ واقعی طے کرتے ہیں وہ شاذ ایک ہوتے ہیں۔ “اہم لمحوں” کو نشان زد کریں، وہ چند نقطے جہاں تجربہ فیصلہ کن طور پر کامیاب یا ناکام ہوتا ہے، اور کوشش یکساں پھیلانے کی بجائے وہیں مرکوز کریں۔ ایک چینل پر ہموار نظر آنے والا سفر پھر بھی سرے سے سرے تک تکلیف دہ ہو سکتا ہے، اور صرف کثیر چینل نظارہ اسے ظاہر کرتا ہے۔

سروس blueprint بنائیں جو سامنے کو پیچھے سے جوڑے

اس نظم و ضبط کا بنیادی آرٹیفیکٹ سروس blueprint ہے۔ جہاں سفر کا نقشہ صارف کا نقطہ نظر لیتا ہے، blueprint نیچے کی تہیں جوڑتا ہے۔ عام blueprint افقی swimlanes میں چلتا ہے: اوپر گاہک کے اعمال، پھر سامنے کے touchpoints جن سے وہ تعامل کرتے ہیں، پھر “نظر آنے کی لکیر” جس کے نیچے پیچھے کے مرحلے کے وہ اعمال ہیں جو عملہ کرتا ہے، اور آخر میں معاون نظام اور عمل جو اوپر کی ہر چیز ممکن بناتے ہیں۔ کالم اوپر سے نیچے پڑھیں اور آپ بالکل دیکھ سکتے ہیں کہ سامنے کے ایک لمحے کے کام کرنے کے لیے پردے کے پیچھے کیا ہونا ضروری ہے، اور وہ کہاں ٹوٹے گا اگر نظام سست ہو یا حوالگی دھندلی ہو۔ Blueprints وہ جگہ ہیں جہاں آپ خاموش ناکامیاں ڈھونڈتے ہیں: دستی دوبارہ ٹائپنگ، رات بھر کا batch job، وہ ٹیم جو نہیں جانتی کہ وہ dependency ہے۔ انہیں ان آپریشنل عملے کے ساتھ بنائیں جو واقعی پیچھے کا مرحلہ چلاتے ہیں، صرف ڈیزائنرز کے ساتھ نہیں، کیونکہ وہ عملہ جانتا ہے کہ حقیقی کام کہاں ہوتا ہے۔ Blueprint جو صرف خوشگوار راستہ دکھائے سجاوٹ ہے؛ ناکامی اور بحالی کے راستوں کا بھی blueprint بنائیں۔

پیچھے کے مرحلے اور عملے کے سامنے والے ٹولز کو اولین درجے کا ڈیزائن کریں

جو ٹولز آپ کا عملہ استعمال کرتا ہے انہیں پروڈکٹ کا حصہ سمجھیں، کیونکہ گاہک کے لیے وہ ہیں۔ جب کال سینٹر کا ایجنٹ، کیس ورکر، یا گودام کا picker سست، بدصورت، آدھی ٹوٹی اندرونی کنسول سے لڑتا ہے تو وہ رگڑ سیدھی اس شخص کو پہنچتی ہے جس کی وہ خدمت کر رہے ہیں، لمبے انتظار، غلط جوابات، اور نظر آنے والی مایوسی کے طور پر۔ اندرونی ٹولز دائمی طور پر کم فنڈ ہیں ٹھیک اس لیے کہ ان کے صارفین پابند ہیں اور چھوڑ نہیں سکتے، جو بالکل وجہ ہے کہ باب 5.1 خبردار کرتا ہے کہ پابند صارفین کا سافٹ ویئر چھوڑنے کی بجائے غلطیوں اور کھوئی پیداواریت میں ادا ہوتا ہے۔ عملے کے سامنے والے نظاموں کو وہی تحقیق، ڈیزائن، اور معیار کا درجہ دیں جو گاہک کے سامنے والوں کو دیتے ہیں۔ حوالگیوں پر خاص توجہ دیں، وہ لمحے جب کیس ایک ٹیم، نظام، یا چینل سے دوسرے کو جاتا ہے، کیونکہ گری ہوئی حوالگی انتظار کرتے صارف کے سوا ہر ایک کو نظر نہیں آتی۔ ڈیزائن کریں کہ وصول کرنے والا کیا دیکھتا ہے، کیس کے ساتھ کون سا سیاق سفر کرتا ہے، اور حوالگی ناکام ہونے پر کیا ہوتا ہے۔

ٹیم کے ڈیزائن کو سروس کے ڈیزائن سے ہم آہنگ کریں

توقع رکھیں کہ ادارہ جاتی چارٹ سروس میں ظاہر ہوگا۔ یہ Conway کا قانون ہے، یہ مشاہدہ کہ نظام ان اداروں کے رابطے کی ساخت کی عکاسی کرنے لگتے ہیں جو انہیں بناتے ہیں، جو باب 1.2 میں گہرائی میں ڈھکا گیا ہے۔ اگر چار ٹیمیں سفر کے چار قدموں کی مالک ہوں اور شاذ بات کریں تو صارف دراڑوں کے ساتھ چار بے ربط قدم محسوس کرے گا۔ اس لیے سروس کا ڈیزائن اور ٹیم کا ڈیزائن دو زاویوں سے دیکھا گیا ایک ہی مسئلہ ہیں، اور آپ بکھرے تجربے کو محض بہتر اسکرینوں سے ٹھیک نہیں کر سکتے اگر بنیادی ملکیت بکھری ہو۔ اپنے سروس blueprints اور سفر کے نقشے استعمال کر کے پوچھیں کہ آیا آپ کی ٹیمیں صارف کے سفر کے گرد کھینچی ہیں یا اندرونی سہولت کے گرد، اور ٹیموں کی تشکیل نو، یا ایسا کردار بنانے کو تیار رہیں جو واضح طور پر سرے سے سرے تک سفر کا مالک ہو، تاکہ کوئی پورے کا جوابدہ ہو، صرف اپنے حصے کا نہیں۔ جب آپ ٹیمیں دوبارہ نہ کھینچ سکیں تو کم از کم ان کے بیچ حوالگیوں کو متفقہ سیاق اور service levels کے ساتھ واضح معاہدے بنائیں۔

سروس کا معیار سرے سے سرے تک ناپیں

ایسی میٹرکس چنیں جو صارف کی پیروی پہلے ارادے سے حقیقی نتیجے تک کریں، وہ نہیں جو ایک چینل کی تنہائی میں خوشامد کرے۔ ویب سائٹ کی ٹیم 98 فیصد فارم کی تکمیل کی شرح حاصل کر سکتی ہے جبکہ ان تکمیلات کا ایک تہائی پیچھے کی قطار میں خاموشی سے ناکام ہو، اور مقامی میٹرک اسے کبھی نہیں دکھائے گی۔ سرے سے سرے تک تکمیل ناپیں (کیا شخص کو واقعی وہ ملا جس کے لیے آیا تھا)، سرے سے سرے تک وقت (ارادے سے نتیجے تک کتنی دیر، پیچھے کے نظر نہ آنے والے انتظار سمیت)، اور محنت (انہیں جن چینلز کو استعمال کرنا پڑا ان میں یہ کتنا مشکل تھا)۔ آپریشنل ڈیٹا کو اس کے براہ راست مطالعے سے ملائیں کہ یہ کیسا محسوس ہوا، چاہے لین دین کے سروے، Net Promoter Score طرز کے سوال، یا جاری تحقیق سے۔ خاص طور پر چینل سے چینل کے drop-offs دیکھیں، کیونکہ وہ جوڑ وہ ہیں جہاں ناپا ہوا معیار اور محسوس ہوا معیار سب سے زیادہ مختلف ہوتے ہیں۔ ان سروس کی میٹرکس کو پروڈکٹ مینجمنٹ کے نتیجے کی ٹریکنگ (باب 10.14) سے جوڑیں تاکہ اعداد ایسے ڈیش بورڈ میں بیٹھنے کی بجائے ترجیح بندی چلائیں جس پر کوئی عمل نہیں کرتا۔

سمجھوتے: فوائد اور نقصانات

طریقہ	فوائد	نقصانات
سرے سے سرے تک سروس کی ملکیت (ایک ٹیم سفر کی مالک)	واضح جوابدہی، مربوط تجربہ، جوڑ ڈیزائن ہوتے ہیں	موجودہ تنظیمی ساخت کو کاٹتا ہے، عملہ اور فنڈ دینا مشکل، رکاوٹ بن سکتا ہے
فی چینل یا فی قدم ملکیت	موجودہ ٹیموں کو موزوں، واضح مقامی دائرہ، عملہ دینا آسان	کوئی پورے کا مالک نہیں؛ چینلز کے بیچ خلا؛ مقامی اصلاح
پہلے سے مکمل سروس blueprinting	بھیجنے سے پہلے پیچھے کی ناکامیاں ظاہر کرتی ہے، مشترک سمجھ	وقت طلب، باسی ہو سکتا ہے، عمل سے پہلے تجزیے کا خطرہ
صرف ہلکی سفر کی نقشہ بندی	تیز، سستی، بدترین خلا دیکھنے کو کافی	وہ پیچھے کی اور نظام کی ناکامیاں چوک جاتی ہے جو blueprint پکڑتا
Omnichannel مستقل مزاجی (چینلز میں متحد)	بے جوڑ حوالگیاں، سیاق چینلز میں ساتھ جاتا ہے	مہنگا انضمام، مشترک ڈیٹا اور ہم آہنگ ٹیمیں مانگتا ہے

مرکزی کھنچاؤ اس سروس کے درمیان ہے جو صارف کو چاہیے، جو آپ کی حدوں کے پار بہتی ہے، اور اس ادارے کے درمیان جو آپ کے پاس واقعی ہے، جو ان کے ساتھ کھینچا گیا ہے۔ اسے جزوی طور پر حل کریں، ضدی طور پر نہیں۔ ایک سروس اچھی طرح ڈیزائن کرنے کو آپ کو پوری کمپنی کی تنظیم نو کی ضرورت نہیں، لیکن آپ کو کم از کم ایک شخص یا ٹیم چاہیے جو سرے سے سرے تک نتیجے کی جوابدہ ہو، blueprint سے لیس جو پیچھے کا مرحلہ نظر آنے والا بنائے اور جوڑ ٹھیک کرنے کا مینڈیٹ ہو۔ اپنی سب سے بھاری blueprinting ان سفروں پر خرچ کریں جو زیادہ حجم، زیادہ داؤ، یا زیادہ ناکامی کے ہیں، اور باقی کے لیے ہلکے سفر کے نقشے استعمال کریں۔ ہدف کامل آرٹیفیکٹ نہیں؛ یہ ایسی سروس ہے جو اس شخص کے لیے کام کرے جو اس کے مرکز میں ہے۔

اپنی ٹیم کے ساتھ بحث کے سوالات

پوری سروس کا سرے سے سرے تک، صارف کے پہلے ارادے سے ان کے حقیقی نتیجے تک، مالک کون ہے، اور اس کے پاس واقعی کیا طاقت ہے؟ زیادہ تر بڑے اداروں میں ایماندار جواب “کوئی نہیں” ہے، کیونکہ ملکیت چینل اور محکمے سے بٹی ہے، اور ہر مالک اپنے حصے پر ناپا جاتا ہے۔ وہ خلا وہ جگہ ہے جہاں سروسز ناکام ہوتی ہیں، کیونکہ مالکان کے بیچ کے جوڑ کسی کے نہیں اور انہیں توجہ نہیں ملتی۔ طے کریں کہ آیا آپ واضح سرے سے سرے تک مالک بنائیں گے، سروس کا مالک یا سفر کا مالک، اور واضح رہیں کہ آیا وہ شخص پیچھے کے نظام اور ٹیم کی حدیں واقعی بدل سکتا ہے یا محض اس میٹرک کا ذمہ دار ہے جسے وہ ہلا نہیں سکتا۔ اپنا موجودہ ادارہ جاتی چارٹ اور اپنے اعلیٰ سفر کا blueprint لائیں اور انہیں ساتھ رکھیں کہ دیکھیں سفر کو کون چھوتا ہے اور اس کا جوابدہ کون ہے۔ اگر دونوں نہیں ملتے تو آپ نے اپنی بدترین حوالگی کی ناکامیوں کا ماخذ پا لیا۔ جواب کو بدلنا چاہیے کہ آپ کام کو فنڈ اور عملہ کیسے دیتے ہیں، نہ کہ صرف standup میں کون شریک ہوتا ہے۔
کیا ہماری ٹیمیں صارف کے سفر کے گرد کھینچی ہیں یا ہماری اندرونی سہولت کے گرد، اور کیا ہم اسے بدلنے کو تیار ہیں؟ Conway کا قانون (باب 1.2) کا مطلب ہے کہ آپ کی سروس آپ کے رابطے کی ساخت کی عکاسی کرے گی چاہے آپ ارادہ رکھیں یا نہیں، اس لیے چار غیر رابطہ ٹیموں میں بٹا سفر چار بے ربط قدم محسوس ہوگا۔ آرام دہ اقدام اسکرینیں ٹھیک کرنا اور ادارہ جاتی چارٹ کو چھوڑ دینا ہے، لیکن یہ علامت کا علاج کرتا ہے جبکہ وجہ اسے بار بار پیدا کرتی رہتی ہے۔ ایمانداری سے دیکھیں کہ آیا آپ کی ٹیم کی حدیں وہی حوالگی کے خلا بناتی ہیں جن کی آپ کے صارفین شکایت کرتے ہیں، اور ٹیموں کی تشکیل نو کی حقیقی لاگت کو بکھرے تجربے کی جاری لاگت کے مقابل تولیں۔ اپنے سفر کے نقشے سے تکلیف کے نقطے لائیں اور جانچیں ان میں سے کتنے ٹھیک ٹیم کی حد پر ہیں۔ اگر زیادہ تر ہیں تو بہتر UI آپ کو نہیں بچائے گی، اور بات چیت ٹیم کے ڈیزائن کے بارے میں ہونی چاہیے۔ جو آپ یہاں طے کریں وہ طے کرتا ہے کہ آپ کی سروس کی بہتریاں ٹھہرتی ہیں یا خاموشی سے گھلتی ہیں۔
ہمارے عملے کے سامنے والے ٹولز انہیں استعمال کرنے والے لوگوں کی کتنی خدمت کرتے ہیں، اور یہ گاہک کے لیے کیسے ظاہر ہوتا ہے؟ اندرونی ٹولز کسی بھی بڑے ادارے کا سب سے قابل بھروسہ نظر انداز کردہ سافٹ ویئر ہیں، کیونکہ ان کے صارفین پابند ہیں اور بجٹ بعد کا خیال، پھر بھی ٹوٹی کنسول سے لڑتا کیس ورکر یا ایجنٹ وہ رگڑ سیدھی گاہک کو تاخیر اور غلطیوں کے طور پر پہنچاتا ہے۔ پوچھیں آپ نے آخری بار اپنے عملے کے سامنے والے نظاموں پر تحقیق کب کی، یا آپ یہ فرض کرتے ہیں کہ چونکہ عملے کو نمٹنے کی تنخواہ ملتی ہے، ٹولز ٹھیک ہیں۔ غور کریں کہ پیچھے کا مرحلہ وہ جگہ ہے جہاں زیادہ تر خاموش سروس کی ناکامیاں واقعی ہوتی ہیں، دستی دوبارہ ٹائپنگ اور حوالگیوں پر کھوئے سیاق میں، جن میں سے کوئی سامنے کی میٹرکس نہیں دیکھ سکتیں۔ حقیقی عملے کا فرد کمرے میں لائیں اور انہیں عام کام مکمل کرتے دیکھیں، پھر سراغ لگائیں کہ ان کی جدوجہد گاہک تک کیسے پہنچتی ہے۔ اگر آپ نے کبھی اندرونی ٹولز کو پروڈکٹ کی طرح فنڈ نہیں کیا تو یہ غالباً سرے سے سرے تک سروس کے معیار میں آپ کی سب سے سستی بڑی بہتری ہے۔
کون سی واحد سرے سے سرے تک میٹرک ہمیں بتائے گی کہ پوری سروس واقعی کام کرتی ہے، اور ہم آج اسے ٹریک کیوں نہیں کر رہے؟ بڑی ٹیم کے لیے یہ سوال تکلیف دہ ہے کیونکہ ایماندار جواب عموماً یہ ہے کہ ہر چینل اور محکمے کی مقامی میٹرک سبز ہے جبکہ کوئی نہیں ناپتا کہ آیا شخص کو وہ ملا جس کے لیے آیا تھا۔ فارم کی تکمیل کی شرحیں، کال سنبھالنے کے اوقات، اور ٹکٹ بند کرنے کی گنتیاں سب اس مالک کی خوشامد کرتی ہیں جو رپورٹ کرتا ہے، اور ہر ایک صحت مند رہ سکتی ہے جبکہ جڑا ہوا نتیجہ پیچھے کی قطار میں ناکام ہو۔ سرے سے سرے تک تکمیل یا سرے سے سرے تک وقت کی پیمائش طے کریں جو صارف کی پہلے ارادے سے حقیقی نتیجے تک پیروی کرے، اور واضح رہیں کہ ان نظاموں میں اسے آلہ دار کون بنائے گا جو ڈیٹا بانٹنے کے لیے کبھی نہیں بنے۔ موجودہ فی چینل ڈیش بورڈز، ایک زیادہ حجم والے سفر کا blueprint، اور چینلز کے بیچ خاموش drop-off کا اندازہ لائیں تاکہ مقامی سبز اور سرے سے سرے تک سرخ کا خلا نظر آئے۔ انٹرپرائز اور حکومت کی ترتیبوں میں طے کریں پورے سفر کے عدد کا جوابدہ کون ہے اور اس پر عمل کا اختیار کس کے پاس ہے، کیونکہ جس میٹرک کو کوئی ایک مالک ہلا نہ سکے وہ کچھ نہیں بدلتی۔
ہماری سروس صارف کو کہاں خود کو دہرانے پر مجبور کرتی ہے، اور “ہمیں ایک بار بتائیں” ورژن بنانے کی کیا لاگت ہوگی؟ دہرایا ڈیٹا گرفت اس بات کا واضح ترین اشارہ ہے کہ سروس صارف کی ضرورت کی بجائے آپ کی اندرونی حدوں کے گرد منظم ہے، اور یہ دونوں طرف مہنگی ہے: صارف ہر حوالگی پر وہی ثبوت دوبارہ داخل کرتا ہے، اور ہر محکمہ اسے دوبارہ جمع اور تصدیق کرنے کی ادائیگی کرتا ہے۔ متصادم غور یہ ہے کہ مشترک ریکارڈ جو “ہمیں ایک بار بتائیں” کو ممکن بناتا ہے، ان نظاموں اور ٹیموں میں انضمام کا مطالبہ کرتا ہے جن کی ایک دوسرے کے ڈیٹا پر بھروسے کی کوئی تاریخ نہیں، اس لیے تعمیر کی لاگت اور ڈیٹا کے نظم و نسق کا کام حقیقی ہیں۔ ہر اس نقطے کے ساتھ سفر کا نقشہ لائیں جہاں صارف وہ معلومات دیتا ہے جو آپ کے پاس پہلے سے ہے، اور موٹی گنتی کہ کتنے الگ ریکارڈ وہی فیلڈ رکھتے ہیں۔ کئی ایجنسیوں پر پھیلی سرکاری سروس کے لیے ان کے بیچ اس ڈیٹا کے اشتراک کی قانونی بنیاد جوڑیں، کیونکہ رضامندی، رازداری کا قانون، اور معلومات کے نظم و نسق کے قواعد طے کرتے ہیں کہ “ہمیں ایک بار بتائیں” کی اجازت ہے بھی یا نہیں، اس سے پہلے کہ آپ پوچھیں کہ آیا یہ قابل برداشت ہے۔
جب سیاق ٹیم، نظام، یا چینل کے بیچ حوالے ہوتا ہے تو کیس کے ساتھ دراصل کیا سفر کرتا ہے، اور حوالگی ناکام ہونے پر کیا ہوتا ہے؟ حوالگیاں وہ جگہ ہیں جہاں سروسز خاموشی سے ٹوٹتی ہیں، کیونکہ ناکامی انتظار کرتے صارف کے سوا ہر ایک کو نظر نہیں آتی، اور بڑے ادارے میں ہر حوالگی ایسی حد پار کرتی ہے جہاں کوئی ایک مالک اس کا ذمہ دار محسوس نہیں کرتا جو گر جائے۔ دانستہ طے کریں کہ کون سا ڈیٹا، تاریخ، اور حالت کیس کے ساتھ جانی چاہیے، آیا وصول کرنے والا اسے دیکھ سکتا ہے، اور جب منتقلی رک جائے یا ادھوری پہنچے تو بحالی کا راستہ کیا ہے۔ کسی حقیقی سفر کا اپنا سروس blueprint لائیں اور ہر لکیر کا سراغ لگائیں جہاں کیس ہاتھ بدلتا ہے، نشان زد کریں کون سا سیاق محفوظ رہا اور کون سا دوبارہ ٹائپ ہوا یا کھو گیا۔ service-level agreements یا قانونی جواب کی مدتوں کے پابند انٹرپرائز اور سرکاری شعبے کی خدمات میں ہر حوالگی کو متفقہ سیاق اور متعین متبادل کے ساتھ واضح معاہدہ سمجھیں، کیونکہ غیر دستاویزی حوالگی خلاف ورزی ہے جو ہونے کی منتظر ہے اور جس کی کوئی ڈیش بورڈ تنبیہ نہیں کرے گا۔

شعبہ جاتی نقطۂ نظر

اسٹارٹ اپ۔ مٹھی بھر لوگوں اور تفصیلی آرٹیفیکٹس کے لیے وقت کے بغیر، صرف اس ایک سفر کا blueprint بنائیں جو آپ کی بنیادی قدر لے جاتا ہے، اور اتنا ہی بنائیں کہ دیکھ سکیں سامنے کا مرحلہ کہاں سست یا دستی پیچھے کے مرحلے کو حوالے ہوتا ہے۔ یہ دوپہر میں وائٹ بورڈ پر کریں، چھ ہفتے کے مطالعے کے طور پر نہیں۔ آپ کا فائدہ یہ ہے کہ پوری سروس چند ذہنوں میں رہتی ہے، اس لیے ٹوٹی حوالگی ٹھیک کرنا محکموں کے بیچ مذاکرات کی بجائے گفتگو ہے۔ وہ فائدہ اس سے پہلے استعمال کریں کہ آپ ان حدوں کو بڑھائیں جو حوالگیوں کو مہنگا بناتی ہیں۔

چھوٹا کاروبار۔ آپ کے پاس سروس ڈیزائنر نہیں اور اس کے لیے بجٹ نہیں، اس لیے عملی اقدام یہ ہے کہ اپنا سفر گاہک کی طرح طے کریں، ہر اس نقطے کو نوٹ کریں جہاں آپ کسی کو خود کو دہرانے یا دستی قدم پر انتظار کرنے پر مجبور کرتے ہیں، اور بدترین کو ٹھیک کریں۔ ایسے ٹولز کو ترجیح دیں جو پہلے سے آپ کے چینلز کو جوڑتے ہیں (مشترک inbox، بکنگ سسٹم جو عملے کو مطلع کرے) بجائے ایسا انضمام بنانے کے جسے آپ برقرار نہیں رکھ سکتے۔ جب آپ سسٹم خریدیں تو تولیں کہ وہ اگلے قدم کو سیاق کتنی اچھی طرح دیتا ہے، کیونکہ سستا ٹول جو فروخت اور تکمیل کے بیچ گاہک کی تفصیلات گرائے وہ آپ کو جتنا بچاتا ہے اس سے زیادہ دوبارہ کاروبار کھونے میں لاگت دیتا ہے۔

بڑا ادارہ۔ بنیادی مسئلہ یہ ہے کہ ایک ہی سفر فروخت، provisioning، بلنگ، اور معاونت کو پار کرتا ہے، ہر ایک کی مقامی میٹرکس سبز اور کوئی پورے کا جوابدہ نہیں۔ اپنے زیادہ حجم، زیادہ داؤ کے سفروں کے لیے مکمل سروس blueprints میں سرمایہ لگائیں، جوڑوں پر اختیار کے ساتھ نام زد سرے سے سرے تک مالک مقرر کریں، اور سرے سے سرے تک ایسی میٹرک معیاری کریں جو آڈٹ سے بچے اور ٹیموں میں ترجیح بندی چلائے۔ مشترک کیس ریکارڈ اور عملے کے سامنے والی کنسولز کو فنڈ شدہ پروڈکٹس سمجھیں، اور ہر ٹیموں کے پار حوالگی کو متفقہ سیاق اور service levels کے ساتھ واضح معاہدہ بنائیں۔

حکومت۔ سروسز کو ایجنسی کی ساخت کی بجائے شہری کے زندگی کے واقعے کے گرد منظم ہونا چاہیے، اور شفافیت اور عوامی جوابدہی کے ساتھ شائع شدہ سروس کے معیاروں پر رکھا جانا چاہیے۔ خریداری کے قواعد آپ کے بنانے کو شکل دیتے ہیں، اس لیے جہاں ڈیٹا کے اشتراک کی قانونی بنیاد موجود ہو وہاں مشترک ریکارڈ اور “ہمیں ایک بار بتائیں” کے نمونوں کو ترجیح دیں، اور بہاؤ ڈیزائن کرنے سے پہلے وہ بنیاد دستاویزی کریں۔ حقیقی صارفین کے ساتھ تحقیق کریں، سب سے کمزور سمیت، کثیر ایجنسی پیچھے کے مرحلے کا blueprint بنائیں، اور ہر ایجنسی کے حصے کی بجائے پورے سفر کو ناپیں، کیونکہ عوام سروس کو اس سے پرکھتی ہے کہ انہیں نتیجہ ملا، اس سے نہیں کہ کون سا محکمہ کامیاب ہوا۔

مثالیں

اسٹارٹ اپ۔ گھر کے بیمے کی پروڈکٹ بیچنے والا دس افراد کا اسٹارٹ اپ خود کو ایپ کمپنی سمجھتا تھا، اور اس کی ایپ واقعی اچھی تھی۔ مگر چھوڑنے کی شرح زیادہ تھی اور معاونت ڈوب رہی تھی، اس لیے بانیوں نے حقیقی دعووں کے سفر کا blueprint بنایا۔ انہوں نے پایا کہ حقیقی سروس آدھی رات کو پھٹی ہوئی پائپ والے گاہک کا لمحہ تھی: ایپ نے ای میل کی قطار کو حوالہ کیا، جس نے تیسری پارٹی کے assessor کو حوالہ کیا جسے گاہک نہیں دیکھ سکتا تھا، جس نے کام کے اوقات میں نامعلوم نمبر سے واپس کال کی جو voicemail میں گئی۔ چمکدار سامنے کا مرحلہ سست، مبہم پیچھے کے مرحلے پر بیٹھا تھا، اور “اہم لمحہ”، دباؤ والا دعویٰ، بالکل وہیں ناکام ہوا۔ حوالگیاں ٹھیک کرنا، گاہک کو assessor کے قدم کی نمائش دینا، اور دعووں کے ورک فلو کو پروڈکٹ کا حصہ سمجھنا برقراری کے لیے کسی بھی نئے ایپ فیچر سے زیادہ مفید ثابت ہوا۔

بڑا ادارہ۔ ٹیلی کمیونیکیشن کمپنی نے کاروبار کا انٹرنیٹ دو منٹ کے آن لائن آرڈر اور دو ہفتے کے ترسیل کے ڈراؤنے خواب کے ساتھ بیچا۔ فروخت، provisioning، فیلڈ انجینئرنگ، اور بلنگ ہر ایک سفر کے ایک حصے کی مالک تھی اور ہر ایک اپنے اہداف پورے کرتی تھی، جبکہ گاہک نے وہی معلومات بار بار مانگی جانا، چھوٹی ہوئی ملاقات کی کھڑکیاں، اور پہلا بل جو اقتباس سے نہ ملتا ہو جھیلا۔ چاروں محکموں میں سروس blueprinting نے جوڑ ظاہر کیے: ہر حوالگی پر سیاق مر جاتا تھا کیونکہ آرڈر کا کوئی مشترک ریکارڈ گاہک کے ساتھ نہیں چلتا تھا۔ کمپنی نے سرے سے سرے تک آرڈر سے activation کا مالک مقرر کیا، آرڈر کے ساتھ سفر کرنے والا مشترک کیس ریکارڈ بنایا، اور ٹیموں کی ترغیبات کو جڑے نتیجے کے گرد دوبارہ ترتیب دیا۔ مقامی میٹرکس مشکل سے بدلیں؛ سرے سے سرے تک activation کا وقت اور شکایت کی شرح دونوں تیزی سے گریں۔

حکومت۔ قومی حکومت نے اپنی “خاندان کے رکن کی وفات” کی سروس دوبارہ ڈیزائن کی، جو شہری کے سامنے آنے والے مشکل ترین زندگی کے واقعات میں سے ایک ہے۔ پہلے سوگوار کو ٹیکس اتھارٹی، پنشن سروس، گاڑی کی ایجنسی، پاسپورٹ آفس، اور مقامی حکومت کو الگ سے مطلع کرنا پڑتا تھا، ہر ایک کا اپنا فارم اور ہر ایک وہی وفات کا سرٹیفکیٹ مانگتی۔ سروس کو ایجنسیوں کی بجائے زندگی کے واقعے کے گرد منظم کر کے ٹیم نے واحد “ہمیں ایک بار بتائیں” سفر بنایا جو شخص کی داخل کی معلومات لے کر نظر آنے کی لکیر کے پیچھے ہر متعلقہ محکمے کو تقسیم کرتا تھا۔ عوامی شعبے کے سروس کے معیار سے ہم آہنگ ہو کر انہوں نے حال ہی میں سوگوار لوگوں کے ساتھ تحقیق کی، کثیر ایجنسی پیچھے کے مرحلے کا blueprint بنایا، اور ہر ایجنسی کے حصے کی بجائے پورے سفر کو ناپا۔ تکمیل بڑھی، دہرائے رابطے گرے، اور شہریوں کو اب ایک سوگ کو درجن بار دوبارہ جینا نہیں پڑتا۔

کاروباری جواز: محرکات، ROI اور TCO

سروس ڈیزائن پر واپسی چینلز اور ٹیموں کے بیچ خلا بند کرنے سے آتی ہے، کیونکہ وہیں سے قدر رستی ہے۔ سرے سے سرے تک ناکامیاں ان طریقوں سے مہنگی ہیں جو فی چینل ڈیش بورڈز چھپاتے ہیں: وہ سفر جو آن لائن مکمل ہوتا ہے مگر پیچھے کے مرحلے میں ناکام ہو معاونت کا رابطہ، دوبارہ کام، اور اکثر کھویا گاہک پیدا کرتا ہے، اور ان میں سے کوئی لاگت اس چینل پر نہیں پڑتی جو کامیاب نظر آتا ہے۔ جب آپ پوری سروس ناپتے اور ٹھیک کرتے ہیں تو آپ دہرائی کوشش (وہی ڈیٹا پانچ بار گرفت میں لیا جانا)، ناکامی کی طلب (وہ رابطے جو صرف اس لیے ہوئے کہ سروس پہلی بار ناکام ہوئی)، اور ان تجربات سے چھوڑنے کی شرح کم کرتے ہیں جو ٹوٹے ہوئے محسوس ہوئے چاہے ہر حصہ تکنیکی طور پر کام کرتا تھا۔ انٹرپرائز میں فائدہ مختصر order-to-cash چکروں اور کم escalations کے طور پر نظر آتا ہے؛ حکومت میں یہ فی خدمت کم لاگت اور ان خدمات کی زیادہ کامیاب تکمیل کے طور پر جو لوگ کہیں اور نہیں پا سکتے۔

ملکیت کی کل لاگت میں سروس ڈیزائن کرنے کی لاگت کو اس بکھراؤ کی کہیں بڑی لاگت کے مقابل تولنا ہوگا جو آپ پہلے سے اٹھا رہے ہیں۔ نظر آنے والی لاگتیں تحقیق، blueprinting، ٹیموں میں ہم آہنگی، اور کبھی مشترک نظاموں اور عملے کے ٹولز میں سرمایہ کاری ہیں۔ نہ کرنے کی چھپی لاگتیں معاونت کے بجٹ، آپریشنز، اور ساکھ کے نقصان میں پھیلی ہیں، جو بالکل وجہ ہے کہ قیادت انہیں کم اندازہ کرتی ہے: کسی ایک ٹیم کا بجٹ ٹوٹی حوالگی کی پوری قیمت نہیں دکھاتا۔ دلیل رکھنے کو ایک زیادہ حجم والے سفر میں ناکامی کی طلب اور دہرائے کام کا عدد نکالیں، اس کا blueprint بنائیں، اور قیادت کو دکھائیں کہ لاگت کا کتنا حصہ ان کی موجودہ ٹیموں کے بیچ کے جوڑوں میں بیٹھا ہے۔ پھر اس سفر پر محدود pilot چلائیں، سرے سے سرے تک پہلے اور بعد ناپیں، اور نتیجہ مشکل ساختی تبدیلیوں کے لیے دلیل میں استعمال کریں۔ سروس ڈیزائن کو ان لاگتوں کے ہٹانے کے طور پر پیش کرنا جو پہلے سے ادا ہو رہی ہیں، بس نظر نہ آنے والے طور پر، مالیات اور نظم و نسق کے فریقوں کو خوبصورتی کی کسی اپیل سے زیادہ ہلاتا ہے۔

ضد نمونے اور خامیاں

چینل کے جزیرے۔ ہر چینل الگ ڈیزائن اور ناپا جاتا ہے، اس لیے سفر ہر جگہ ٹھیک دکھتا ہے اور سرے سے سرے تک کہیں کام نہیں کرتا۔
سامنے کی لپ اسٹک۔ سست یا دستی پیچھے کے مرحلے سے جڑا چمکدار UI، اس لیے تجربہ تب ٹوٹتا ہے جب صارف کو پیچھے کے مرحلے سے جواب چاہیے۔
ادارہ جاتی چارٹ بطور سروس۔ سروسز صارف کے مقصد کی بجائے آپ کے محکموں کے گرد ڈھانچہ شدہ، صارف کو آپ کی اندرونی حدوں میں چلنے پر مجبور کرتی ہوئی۔
Blueprint کا تھیٹر۔ مفصل blueprints ایک بار بنے، سراہے گئے، اور سروس کے چلنے کا طریقہ بدلنے میں کبھی استعمال نہ ہوئے۔
صرف خوشگوار راستے کی نقشہ بندی۔ سفر اور blueprints جو ناکامی اور بحالی کو نظر انداز کرتے ہیں، جہاں حقیقی سروسز کو اصل تکلیف ہوتی ہے۔
نظر انداز عملے کے ٹولز۔ اندرونی، عملے کے سامنے والے نظاموں کو دوسرے درجے کا سمجھنا، اس لیے ان کی رگڑ سیدھی گاہک تک رستی ہے۔
حوالگی کی بھول۔ ٹیم، نظام، یا چینل کے ہر انتقال پر سیاق کھوتا ہے، اس لیے صارف بار بار اپنی صورتحال سمجھاتا ہے۔
خوشامدی میٹرکس۔ مقامی، فی چینل اہداف جو سبز رہتے ہیں جبکہ سرے سے سرے تک نتیجہ خاموشی سے ناکام ہوتا ہے۔

پختگی کا ماڈل

سطح 1، آغاز: ہر چینل اور ٹیم الگ تھلگ اور ردعملی طور پر ڈیزائن اور چلائی جاتی ہے۔ سرے سے سرے تک سروس کا کوئی مالک نہیں، کوئی سفر کا نقشہ یا blueprint نہیں، اور پیچھے کی ناکامیاں شکایات کے طور پر ابھرنے تک نظر نہیں آتیں۔ صارفین معمول سے چینلز میں خود کو دہراتے ہیں کیونکہ کسی نے پورے کو نہیں دیکھا۔
سطح 2، ترقی: کچھ سفر نقشہ بند ہیں اور بدترین کثیر چینل خلا معلوم ہیں، مگر عمل ادھورا ہے اور انفرادی جوش پر منحصر۔ سفر کے نقشے ہیں مگر شاذ پیچھے کے مرحلے تک پہنچتے ہیں، ملکیت اب بھی فی چینل ہے، عملے کے ٹولز بعد کا خیال ہیں، اور جہاں blueprinting ہوتی بھی ہے ٹیم سے ٹیم مختلف ہے۔
سطح 3، معیار بندی: اہم سفر آپریشنل عملے کے ساتھ سامنے سے پیچھے کے مرحلے تک blueprint ہوتے ہیں، ادارے بھر میں مستقل طور پر لاگو دستاویزی طریقے سے۔ نام زد سروس کے مالک سرے سے سرے تک جوابدہ ہیں، حوالگیاں متفقہ سیاق کے ساتھ واضح معاہدے ہیں، عملے کے ٹولز دانستہ ڈیزائن ہوتے ہیں، اور طریقہ اختیاری کی بجائے نافذ ہے۔
سطح 4، انتظام: سروس ڈیٹا سے ناپی اور کنٹرول کی جاتی ہے۔ سرے سے سرے تک تکمیل، سرے سے سرے تک وقت (پیچھے کے نظر نہ آنے والے انتظار سمیت)، صارف کی محنت، ناکامی کی طلب، اور چینل سے چینل کا drop-off بنیادی خطوط کے مقابل ٹریک ہوتے ہیں، اور حوالگی کی ناکامیاں اور دہرایا ڈیٹا گرفت فرض کرنے کی بجائے مقداری ہیں۔ Blueprints موجودہ رکھے جاتے ہیں، سروس کے مالکان سرے سے سرے تک اہداف کے پابند ہیں، اور تبدیلیوں پر آگے بڑھنے یا نہ بڑھنے کے فیصلے مقامی چینل کی میٹرکس کی بجائے اس شہادت پر ٹکتے ہیں۔
سطح 5، ہم آہنگی: ٹیم کا ڈیزائن اور سروس کا ڈیزائن ہم آہنگ ہیں تاکہ ملکیت سفر کی پیروی کرے، اور ادارہ محکموں کی بجائے صارف کے مقاصد اور زندگی کے واقعات کے گرد منظم ہے۔ سرے سے سرے تک میٹرکس ترجیح بندی چلاتی ہیں، ادارہ تجربے اور آپریشنز دونوں کا ساتھ مسلسل blueprint، پیمائش، اور از سر نو تشکیل کرتا ہے، اور صارف کی ضروریات، چینلز، اور کثیر ٹیم حدود کے بدلنے پر پوری سروس کو ڈھالتا ہے۔

بحث کے لیے خیالات

جب سفر کئی ٹیموں کو پار کرے تو کیا ایک سرے سے سرے تک مالک مقرر کرنا بہتر ہے یا ٹیموں کو سفر کے گرد دوبارہ کھینچنا، اور انتخاب کس بات سے طے ہوتا ہے؟
آپ کی سروس کے معیار کا کتنا حصہ بہتر سامنے کے ڈیزائن سے ٹھیک ہو سکتا ہے، اور کتنے کو پیچھے کا مرحلہ یا ادارہ جاتی چارٹ بدلنا چاہیے؟
آپ کی سروس میں صارفین کو خود کو دہرانا سب سے زیادہ کہاں پڑتا ہے، اور “ہمیں ایک بار بتائیں” ورژن بنانے کی کیا لاگت ہوگی؟
جب عملے کے ٹولز کے صارفین پابند ہوں اور ووٹ سے نہ چھوڑ سکیں تو آپ انہیں کیسے فنڈ اور ترجیح دیتے ہیں؟
کیا سروسز کو زندگی کے واقعات یا صارف کے مقاصد کے گرد منظم ہونا چاہیے چاہے یہ آپ کی فنڈنگ اور رپورٹنگ کی لائنوں کے سیدھا خلاف ہو؟
کون سی واحد سرے سے سرے تک میٹرک آپ کو بہترین بتائے گی کہ آپ کی پوری سروس کام کر رہی ہے، اور آپ اسے آج ٹریک کیوں نہیں کرتے؟

اہم نکات

پوری سروس چینلز اور وقت میں ڈیزائن کریں، ایک اسکرین نہیں، اور یاد رکھیں کہ صارف کو پروا نہیں کہ آپ کی ٹیم کی حدیں کہاں گرتی ہیں۔
سامنے اور پیچھے کا مرحلہ ایک نظام ہے؛ بہترین تجربہ اتنا ہی اچھا ہے جتنا اس کے پیچھے کے آپریشنز سہارا دے سکیں۔
سروس blueprint آپ کا بنیادی آرٹیفیکٹ ہے: یہ سامنے کے touchpoints کو انہیں پہنچانے والے پیچھے کے لوگوں، نظاموں، اور حوالگیوں سے جوڑتا ہے۔
ادارہ جاتی چارٹ سروس میں ظاہر ہوتا ہے (Conway کا قانون)، اس لیے سروس کا ڈیزائن اور ٹیم کا ڈیزائن ساتھ چلنے چاہئیں۔
عملے کے سامنے والے ٹولز اور ٹیموں کے بیچ حوالگیوں کو سروس کے اولین درجے کے حصے سمجھیں، کیونکہ ان کی رگڑ گاہک تک پہنچتی ہے۔
سروس کو سرے سے سرے تک ناپیں، پہلے ارادے سے حقیقی نتیجے تک، اور اپنے محکموں کی بجائے صارف کے مقصد یا زندگی کے واقعے کے گرد منظم کریں۔

حوالہ جات اور مزید مطالعہ

Marc Stickdorn and Jakob Schneider, This Is Service Design Thinking
Marc Stickdorn, Markus Edgar Hormess, Adam Lawrence, and Jakob Schneider, This Is Service Design Doing
Andy Polaine, Lavrans Lovlie, and Ben Reason, Service Design: From Insight to Implementation
Lynn Shostack, “Designing Services That Deliver,” Harvard Business Review
Matthew Skelton and Manuel Pais, Team Topologies
Melvin Conway, “How Do Committees Invent?“, Datamation
UK Government Digital Service, Service Manual and the Service Standard
U.S. General Services Administration, 18F Methods and the U.S. Digital Service Playbook
Nielsen Norman Group, articles on service blueprinting and customer journey mapping