5.9 सेवा डिज़ाइन

अवलोकन और प्रेरणा

सेवा डिज़ाइन उस पूरी सेवा को आकार देने का अभ्यास है जिसे कोई व्यक्ति अनुभव करता है, हर चैनल में और पूरे समय-विस्तार में, न कि केवल एक स्क्रीन या ऐप। जब कोई पासपोर्ट का नवीनीकरण करता है, बैंक खाता खोलता है, या टूटी हुई स्ट्रीटलाइट की रिपोर्ट करता है, तो वह आपके उत्पाद का अनुभव नहीं करता। वह एक सेवा का अनुभव करता है: एक फ़ोन कॉल, एक वेबसाइट, डाक में आया एक पत्र, एक कतार, एक ईमेल जो कभी नहीं पहुँचता, एक केसवर्कर जिसे उनके विवरण को उस सिस्टम में फिर से टाइप करना पड़ता है जो यह नहीं देख सकता कि वेबसाइट पहले से क्या जानती है। अध्याय 5.1 अलग-अलग इंटरफ़ेस डिज़ाइन करने के शिल्प को कवर करता है। सेवा डिज़ाइन पूरी यात्रा पर और काउंटर के पीछे की हर उस चीज़ पर ज़ूम आउट करता है जो काउंटर के सामने को काम करने लायक बनाती है।

वह “काउंटर के पीछे” वाला भेद इसका मूल है। सेवा डिज़ाइन दुनिया को फ्रंट-स्टेज में बाँटता है, यानी वह सब कुछ जो उपयोगकर्ता देखता और छूता है, और बैक-स्टेज में, यानी वे लोग, सिस्टम, और प्रक्रियाएँ जो सेवा प्रदान करती हैं लेकिन उपयोगकर्ता के लिए अदृश्य रहती हैं। अच्छे फ्रंट-स्टेज अनुभव हमेशा विफल होते हैं क्योंकि बैक-स्टेज उन्हें सहारा नहीं दे पाता। एक चिकनी बुकिंग फ़ॉर्म जो एक स्प्रेडशीट में गिर जाती है जिसे एक क्लर्क दिन में दो बार जाँचता है, वह एक धीमे बैक-स्टेज पर लगा एक तेज़ फ्रंट-स्टेज है, और उपयोगकर्ता इस बेमेल को तीन दिन की खामोशी के रूप में महसूस करता है। पूरी सेवा को डिज़ाइन करने का मतलब है दोनों हिस्सों को एक साथ डिज़ाइन करना, और उनके बीच के जोड़ों को भी।

बड़ी टीमों के लिए यह अनिवार्य रूप से एक संगठनात्मक समस्या है। सेवाएँ लगभग हमेशा कई टीमों, विभागों, और सिस्टमों तक फैली होती हैं, और उन स्वामियों के बीच की सीमाएँ ठीक वही जगह हैं जहाँ उपयोगकर्ता का अनुभव बिखर जाता है। एंटरप्राइज़ परिवेश में एक ही ग्राहक यात्रा बिक्री, प्रावधान, बिलिंग, और सहायता से होकर गुज़र सकती है, प्रत्येक के अपने-अपने टूल और लक्ष्य होते हैं और कोई भी पूरे के लिए जवाबदेह नहीं होता। सरकार में दांव और भी ऊँचे हैं: शोक या नए बच्चे जैसी जीवन-घटना का सामना कर रहे किसी व्यक्ति को दर्जन भर अलग-अलग एजेंसियों से गुज़रना पड़ता है, प्रत्येक वही सबूत माँगती है, क्योंकि सेवाएँ व्यक्ति की ज़रूरत के बजाय सरकार की संरचना के आस-पास संगठित हैं। सेवा डिज़ाइन वह तरीका है जिससे आप उस केंद्र में मौजूद इंसान के लिए पूरी चीज़ को एक साथ जोड़े रखते हैं।

मुख्य सिद्धांत

पूरी सेवा को चैनलों और समय में डिज़ाइन करें, एक स्क्रीन को नहीं। उपयोगकर्ता को इससे कोई फ़र्क़ नहीं पड़ता कि आपकी टीम की सीमाएँ कहाँ हैं।
फ्रंट-स्टेज और बैक-स्टेज एक ही सिस्टम हैं। कोई अनुभव तभी तक अच्छा है जब तक उसके पीछे का संचालन उसे टिकाए रख सकता है।
संगठन चार्ट सेवा में दिखाई देता है। यदि टीमें सिलोबद्ध हैं, तो सेवा सिलोबद्ध महसूस होगी, इसलिए टीम डिज़ाइन और सेवा डिज़ाइन को साथ-साथ चलना चाहिए।
चैनलों और टीमों के बीच की हैंड-ऑफ़ वे जगहें हैं जहाँ सेवाएँ टूटती हैं। जोड़ों को उतनी ही जानबूझकर डिज़ाइन करें जितना कि चरणों को।
स्टाफ़-मुखी टूल सेवा का हिस्सा हैं। एक ख़राब कंसोल से निराश एजेंट एक निराश ग्राहक पैदा करता है।
सेवा को शुरू से अंत तक मापें, उपयोगकर्ता के पहले इरादे से उसके वास्तविक परिणाम तक, न कि किसी एक चैनल के स्थानीय मीट्रिक से।
उपयोगकर्ता के लक्ष्य या जीवन-घटना के आस-पास संगठित करें, अपने आंतरिक विभागों के आस-पास नहीं।

सिफ़ारिशें

हर चैनल में ग्राहक यात्रा को मैप करें

व्यापक ग्राहक अनुभव के हिस्से के रूप में, किसी परिणाम तक पहुँचने के लिए व्यक्ति जो वास्तविक यात्रा करता है उसे चार्ट करके शुरू करें। एक यात्रा मैप उन चरणों को दर्शाता है जिनसे उपयोगकर्ता गुज़रता है, पहली बार ज़रूरत का एहसास होने से लेकर अपने लक्ष्य तक पहुँचने और उसके आगे तक, और प्रत्येक चरण पर दर्ज करता है कि वे क्या करने की कोशिश कर रहे हैं, वे क्या सोचते और महसूस करते हैं, और वे किस चैनल में हैं। मूल्य चैनलों में फैलने से आता है: अधिकांश वास्तविक यात्राएँ एक वेबसाइट, एक फ़ोन लाइन, एक ईमेल, एक ऐप, और एक भौतिक स्थान के बीच कूदती हैं, और सबसे बुरी पीड़ा उन चैनलों के बीच के अंतराल में रहती है, जहाँ संदर्भ खो जाता है और उपयोगकर्ता को फिर से शुरू करना पड़ता है। मैप को अपनी धारणाओं के बजाय शोध (अध्याय 5.8) में आधारित करें, क्योंकि जो यात्रा आप कल्पना करते हैं और जो यात्रा लोग वास्तव में करते हैं वे शायद ही कभी एक समान होते हैं। “महत्वपूर्ण क्षणों” को चिह्नित करें, उन कुछ बिंदुओं को जहाँ अनुभव निर्णायक रूप से सफल या विफल होता है, और अपने प्रयास को समान रूप से फैलाने के बजाय वहाँ केंद्रित करें। कोई यात्रा जो किसी एक चैनल पर सहज दिखती है, फिर भी शुरू से अंत तक दयनीय हो सकती है, और केवल क्रॉस-चैनल दृष्टिकोण ही इसे उजागर करता है।

एक ऐसा सेवा ब्लूप्रिंट बनाएँ जो फ्रंट-स्टेज को बैक-स्टेज से जोड़े

इस अनुशासन की मूल कलाकृति है सेवा ब्लूप्रिंट। जहाँ एक यात्रा मैप उपयोगकर्ता का दृष्टिकोण लेता है, वहीं एक ब्लूप्रिंट नीचे की परतें जोड़ता है। एक विशिष्ट ब्लूप्रिंट क्षैतिज स्विमलेन में चलता है: ऊपर ग्राहक की क्रियाएँ, फिर वे फ्रंट-स्टेज टचपॉइंट जिनसे वे बातचीत करते हैं, फिर एक “दृश्यता की रेखा” जिसके नीचे स्टाफ़ द्वारा की जाने वाली बैक-स्टेज क्रियाएँ बैठती हैं, और अंत में वे सहायक सिस्टम और प्रक्रियाएँ जो ऊपर की हर चीज़ को सक्षम बनाती हैं। किसी कॉलम को ऊपर से नीचे पढ़ें और आप ठीक-ठीक देख सकते हैं कि एक फ्रंट-स्टेज क्षण के काम करने के लिए पर्दे के पीछे क्या होना चाहिए, और यह कहाँ टूटेगा यदि कोई सिस्टम धीमा है या कोई हैंड-ऑफ़ धुंधला है। ब्लूप्रिंट वे जगहें हैं जहाँ आपको मूक विफलताएँ मिलती हैं: मैनुअल पुनः-टाइपिंग, रात भर चलने वाली बैच नौकरी, वह टीम जिसे पता ही नहीं कि वह एक निर्भरता है। इन्हें उन ऑपरेशनल स्टाफ़ के साथ बनाएँ जो वास्तव में बैक-स्टेज चलाते हैं, केवल डिज़ाइनरों के साथ नहीं, क्योंकि उन स्टाफ़ को पता होता है कि असली काम कहाँ होता है। एक ब्लूप्रिंट जो केवल हैप्पी पाथ दिखाता है वह सजावट है; विफलता और पुनर्प्राप्ति के रास्तों को भी ब्लूप्रिंट करें।

बैक-स्टेज और स्टाफ़-मुखी टूल को प्रथम-श्रेणी के रूप में डिज़ाइन करें

अपने स्टाफ़ द्वारा उपयोग किए जाने वाले टूल को उत्पाद के हिस्से के रूप में मानें, क्योंकि ग्राहक के लिए वे यही हैं। जब कोई कॉल-सेंटर एजेंट, केसवर्कर, या वेयरहाउस पिकर धीमे, बदसूरत, आधे-टूटे आंतरिक कंसोल से जूझता है, तो वह घर्षण सीधे उस व्यक्ति तक पहुँचता है जिसकी वे सेवा कर रहे हैं, लंबे इंतज़ार, ग़लत जवाबों, और दृश्य निराशा के रूप में। आंतरिक टूल दीर्घकालिक रूप से कम वित्तपोषित होते हैं ठीक इसलिए क्योंकि उनके उपयोगकर्ता बंधे हुए हैं और चले नहीं जा सकते, और यही कारण है कि अध्याय 5.1 चेतावनी देता है कि बंधे-उपयोगकर्ता सॉफ़्टवेयर की कीमत मंथन के बजाय त्रुटियों और खोई हुई उत्पादकता में चुकाई जाती है। स्टाफ़-मुखी सिस्टम को वही शोध, डिज़ाइन, और गुणवत्ता मानक दें जो आप ग्राहक-मुखी सिस्टम को देते हैं। हैंड-ऑफ़ पर विशेष ध्यान दें, वे क्षण जब कोई केस एक टीम, सिस्टम, या चैनल से दूसरे में जाता है, क्योंकि एक छूटी हुई हैंड-ऑफ़ उपयोगकर्ता को छोड़कर जो इंतज़ार करता रह जाता है, बाकी सबके लिए अदृश्य होती है। यह डिज़ाइन करें कि प्राप्तकर्ता पक्ष क्या देखता है, केस के साथ कौन सा संदर्भ यात्रा करता है, और जब हैंड-ऑफ़ विफल होती है तो क्या होता है।

टीम डिज़ाइन को सेवा डिज़ाइन के साथ संरेखित करें

उम्मीद करें कि संगठन चार्ट सेवा में दिखाई देगा। यह कॉनवे का नियम है, यह अवलोकन कि सिस्टम उन संगठनों की संचार संरचनाओं को प्रतिबिंबित करने लगते हैं जो उन्हें बनाते हैं, जिसे अध्याय 1.2 में गहराई से कवर किया गया है। यदि चार टीमें किसी यात्रा के चार चरणों की मालिक हैं और शायद ही कभी बात करती हैं, तो उपयोगकर्ता चार खंडित चरणों को उनके बीच की दरारों के साथ महसूस करेगा। इसलिए सेवा डिज़ाइन और टीम डिज़ाइन एक ही समस्या है जिसे दो कोणों से देखा जा रहा है, और यदि अंतर्निहित स्वामित्व खंडित है तो आप केवल बेहतर स्क्रीन से एक खंडित अनुभव को ठीक नहीं कर सकते। यह पूछने के लिए अपने सेवा ब्लूप्रिंट और यात्रा मैप का उपयोग करें कि क्या आपकी टीमें उपयोगकर्ता की यात्रा के आस-पास बनाई गई हैं या आंतरिक सुविधा के आस-पास, और टीमों को नया आकार देने के लिए, या एक ऐसी भूमिका बनाने के लिए तैयार रहें जो स्पष्ट रूप से एक शुरू-से-अंत यात्रा की मालिक हो, ताकि कोई पूरे के लिए जवाबदेह हो, न कि केवल अपने हिस्से के लिए। जब आप टीमों को फिर से आकार नहीं दे सकते, तो कम से कम उनके बीच की हैंड-ऑफ़ को सहमत संदर्भ और सेवा स्तरों वाले स्पष्ट अनुबंध बनाएँ।

सेवा की गुणवत्ता को शुरू से अंत तक मापें

ऐसे मीट्रिक चुनें जो उपयोगकर्ता का पहले इरादे से वास्तविक परिणाम तक अनुसरण करें, न कि ऐसे मीट्रिक जो अलगाव में किसी एक चैनल की चापलूसी करें। एक वेबसाइट टीम 98 प्रतिशत फ़ॉर्म-पूर्णता दर हासिल कर सकती है जबकि उन पूर्णताओं में से एक तिहाई बैक-स्टेज कतार में चुपचाप विफल हो जाती हैं, और स्थानीय मीट्रिक इसे कभी नहीं दिखाएगा। शुरू-से-अंत पूर्णता (क्या व्यक्ति को वास्तव में वह मिला जिसके लिए वह आया था), शुरू-से-अंत समय (इरादे से परिणाम तक कितना समय, जिसमें अदृश्य बैक-स्टेज प्रतीक्षा भी शामिल है), और प्रयास (उन्हें उपयोग करने पड़े सभी चैनलों में यह कितना कठिन था) मापें। ऑपरेशनल डेटा को इस बात के प्रत्यक्ष पठन के साथ जोड़ें कि यह कैसा महसूस हुआ, चाहे किसी लेन-देन सर्वेक्षण के माध्यम से हो, नेट प्रमोटर स्कोर शैली के प्रश्न के माध्यम से हो, या चल रहे शोध के माध्यम से। चैनल-से-चैनल ड्रॉप-ऑफ़ पर विशेष रूप से नज़र रखें, क्योंकि ये जोड़ ही वे जगहें हैं जहाँ मापी गई गुणवत्ता और महसूस की गई गुणवत्ता सबसे अधिक अलग होती हैं। इन सेवा मीट्रिक को उत्पाद प्रबंधन की परिणाम ट्रैकिंग (अध्याय 10.14) से जोड़ें ताकि संख्याएँ प्राथमिकता तय करें, बजाय इसके कि वे किसी डैशबोर्ड में पड़ी रहें जिस पर कोई कार्रवाई नहीं करता।

समझौते: फ़ायदे और नुकसान

दृष्टिकोण	फ़ायदे	नुकसान
शुरू-से-अंत सेवा स्वामित्व (एक टीम एक यात्रा की मालिक)	स्पष्ट जवाबदेही, सुसंगत अनुभव, जोड़ डिज़ाइन किए जाते हैं	मौजूदा संगठनात्मक संरचना को काटता है, स्टाफ़िंग और वित्तपोषण कठिन, बाधा बन सकता है
प्रति-चैनल या प्रति-चरण स्वामित्व	मौजूदा टीमों में फिट बैठता है, स्पष्ट स्थानीय दायरा, स्टाफ़िंग आसान	पूरे का कोई मालिक नहीं; चैनलों के बीच अंतराल; स्थानीय अनुकूलन
पूरी सेवा ब्लूप्रिंटिंग पहले से	बैक-स्टेज विफलताओं को जारी होने से पहले सामने लाती है, साझा समझ	समय लेने वाली, पुरानी पड़ सकती है, कार्रवाई से पहले विश्लेषण का जोखिम
केवल हल्की यात्रा मैपिंग	तेज़, सस्ती, सबसे बुरे अंतराल को पहचानने के लिए पर्याप्त अच्छी	बैक-स्टेज और सिस्टम विफलताओं को चूक जाती है जिन्हें ब्लूप्रिंट पकड़ लेता
ऑम्नीचैनल निरंतरता (चैनलों में एकीकृत)	निर्बाध हैंड-ऑफ़, संदर्भ चैनलों में साथ चलता है	महंगा एकीकरण, साझा डेटा और संरेखित टीमों की मांग

केंद्रीय तनाव उस सेवा के बीच है जिसकी उपयोगकर्ता को ज़रूरत है, जो आपकी सीमाओं के आर-पार बहती है, और उस संगठन के बीच जो आपके पास वास्तव में है, जो उन्हीं सीमाओं के साथ खींचा गया है। इसे सैद्धांतिक रूप से नहीं, बल्कि आनुपातिक रूप से सुलझाएँ। एक सेवा को अच्छी तरह डिज़ाइन करने के लिए आपको पूरी कंपनी को फिर से संगठित करने की ज़रूरत नहीं है, लेकिन आपको कम से कम एक व्यक्ति या टीम को शुरू-से-अंत परिणाम के लिए जवाबदेह बनाना होगा, जिसके पास एक ऐसा ब्लूप्रिंट हो जो बैक-स्टेज को दृश्यमान बनाए और जोड़ों को ठीक करने का अधिकार हो। अपनी सबसे भारी ब्लूप्रिंटिंग उन यात्राओं पर खर्च करें जो उच्च-मात्रा, उच्च-दांव, या उच्च-विफलता वाली हैं, और बाकी के लिए हल्के यात्रा मैप का उपयोग करें। लक्ष्य कोई सटीक कलाकृति नहीं है; यह एक ऐसी सेवा है जो उसके केंद्र में मौजूद व्यक्ति के लिए काम करती है।

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

पूरी सेवा का शुरू से अंत तक, उपयोगकर्ता के पहले इरादे से उसके वास्तविक परिणाम तक, मालिक कौन है, और उनके पास वास्तव में कितनी शक्ति है? अधिकांश बड़े संगठनों में ईमानदार जवाब है “कोई नहीं,” क्योंकि स्वामित्व चैनल और विभाग के अनुसार बंटा हुआ है, और प्रत्येक मालिक को उसके अपने हिस्से पर मापा जाता है। यही वह अंतराल है जहाँ सेवाएँ विफल होती हैं, क्योंकि मालिकों के बीच के जोड़ किसी के भी नहीं होते और उन्हें कोई ध्यान नहीं मिलता। तय करें कि क्या आप एक स्पष्ट शुरू-से-अंत मालिक बनाएँगे, एक सेवा मालिक या यात्रा मालिक, और स्पष्ट रहें कि क्या यह व्यक्ति वास्तव में बैक-स्टेज सिस्टम और टीम सीमाओं को बदल सकता है या केवल एक ऐसे मीट्रिक के लिए ज़िम्मेदार है जिसे वह हिला नहीं सकता। अपना वर्तमान संगठन चार्ट और अपनी शीर्ष यात्रा का ब्लूप्रिंट लाएँ और उन्हें साथ-साथ रखकर देखें कि यात्रा को कौन छूता है और उसके लिए कौन जवाबदेह है। यदि दोनों मेल नहीं खाते, तो आपको अपनी सबसे बुरी हैंड-ऑफ़ विफलताओं का स्रोत मिल गया है। उत्तर से यह बदलना चाहिए कि आप काम को कैसे वित्तपोषित और स्टाफ़ करते हैं, न कि केवल स्टैंडअप में कौन शामिल होता है।
क्या हमारी टीमें उपयोगकर्ता की यात्रा के आस-पास बनाई गई हैं या हमारी आंतरिक सुविधा के आस-पास, और क्या हम इसे बदलने के लिए तैयार हैं? कॉनवे का नियम (अध्याय 1.2) का मतलब है कि आपकी सेवा आपकी संचार संरचना को प्रतिबिंबित करेगी चाहे आप ऐसा चाहें या न चाहें, इसलिए चार असंवादी टीमों में बंटी एक यात्रा चार खंडित चरणों जैसी महसूस होगी। आरामदायक कदम है स्क्रीन ठीक करना और संगठन चार्ट को छोड़ देना, लेकिन यह एक लक्षण का इलाज करता है जबकि कारण उसे बार-बार पुनर्जीवित करता रहता है। ईमानदारी से देखें कि क्या आपकी टीम सीमाएँ ठीक वही हैंड-ऑफ़ अंतराल बनाती हैं जिनकी आपके उपयोगकर्ता शिकायत करते हैं, और टीमों को फिर से आकार देने की वास्तविक लागत को खंडित अनुभव की चल रही लागत के मुकाबले तौलें। अपने यात्रा मैप से दर्द बिंदु लाएँ और जाँचें कि उनमें से कितने ठीक किसी टीम सीमा पर बैठते हैं। यदि अधिकांश ऐसा करते हैं, तो बेहतर UI आपको नहीं बचाएगा, और बातचीत को टीम डिज़ाइन के बारे में होना चाहिए। आप यहाँ जो तय करते हैं वह निर्धारित करता है कि आपके सेवा सुधार टिकते हैं या चुपचाप घिस जाते हैं।
हमारे स्टाफ़-मुखी टूल उन लोगों की कितनी अच्छी सेवा करते हैं जो उनका उपयोग करते हैं, और यह ग्राहक के लिए कैसे दिखाई देता है? आंतरिक टूल किसी भी बड़े संगठन में सबसे भरोसेमंद रूप से उपेक्षित सॉफ़्टवेयर हैं, क्योंकि उनके उपयोगकर्ता बंधे हुए हैं और उनके बजट बाद की सोच हैं, फिर भी एक टूटे हुए कंसोल से जूझता केसवर्कर या एजेंट उस घर्षण को सीधे ग्राहक तक देरी और त्रुटियों के रूप में पहुँचाता है। पूछें कि आपने आख़िरी बार अपने ही स्टाफ़-मुखी सिस्टम पर शोध कब किया था, या क्या आप यह मान लेते हैं कि क्योंकि स्टाफ़ को निपटने के लिए भुगतान किया जाता है, टूल ठीक हैं। विचार करें कि बैक-स्टेज वह जगह है जहाँ अधिकांश मूक सेवा विफलताएँ वास्तव में होती हैं, मैनुअल पुनः-टाइपिंग और हैंड-ऑफ़ पर खोए हुए संदर्भ में, जिनमें से किसी को भी फ्रंट-स्टेज मीट्रिक नहीं देख सकते। किसी असली स्टाफ़ सदस्य को कमरे में लाएँ और उन्हें एक सामान्य काम पूरा करते देखें, फिर पता लगाएँ कि उनका संघर्ष ग्राहक तक कैसे पहुँचता है। यदि आपने कभी आंतरिक टूल को किसी उत्पाद की तरह वित्तपोषित नहीं किया है, तो यह शुरू-से-अंत सेवा गुणवत्ता में आपका सबसे सस्ता बड़ा सुधार होने की संभावना है।
कौन सा एकल शुरू-से-अंत मीट्रिक हमें बताएगा कि क्या पूरी सेवा वास्तव में काम करती है, और हम इसे आज क्यों नहीं ट्रैक कर रहे? एक बड़ी टीम के लिए यह प्रश्न असहज है क्योंकि ईमानदार जवाब आमतौर पर यह होता है कि हर चैनल और विभाग के पास एक हरा स्थानीय मीट्रिक है जबकि कोई यह नहीं मापता कि व्यक्ति को वह मिला जिसके लिए वह आया था। फ़ॉर्म-पूर्णता दरें, कॉल-हैंडलिंग समय, और टिकट-समापन गिनती सभी उस मालिक की चापलूसी करती हैं जो उनकी रिपोर्ट करता है, और प्रत्येक स्वस्थ रह सकती है जबकि जुड़ा हुआ परिणाम बैक-स्टेज कतार में विफल होता रहता है। एक शुरू-से-अंत पूर्णता या शुरू-से-अंत समय माप तय करें जो उपयोगकर्ता का पहले इरादे से वास्तविक परिणाम तक अनुसरण करे, और स्पष्ट रहें कि उन सिस्टमों में इसे कौन इंस्ट्रूमेंट करेगा जो कभी डेटा साझा करने के लिए नहीं बनाए गए थे। वर्तमान प्रति-चैनल डैशबोर्ड, किसी उच्च-मात्रा यात्रा का ब्लूप्रिंट, और चैनलों के बीच मूक ड्रॉप-ऑफ़ का अनुमान लाएँ ताकि स्थानीय हरे और शुरू-से-अंत लाल के बीच का अंतराल दिखाई दे। एंटरप्राइज़ और सरकारी परिवेश में, सहमत हों कि पूरी-यात्रा संख्या के लिए कौन जवाबदेह है और उस पर कार्रवाई करने का अधिकार किसके पास है, क्योंकि एक ऐसा मीट्रिक जिसे कोई एक मालिक हिला नहीं सकता, ऐसा मीट्रिक है जो कुछ नहीं बदलता।
हमारी सेवा उपयोगकर्ता को खुद को कहाँ दोहराने पर मजबूर करती है, और एक “हमें एक बार बताएँ” संस्करण बनाने में क्या लागत आएगी? डुप्लिकेट डेटा कैप्चर सबसे स्पष्ट संकेत है कि कोई सेवा उपयोगकर्ता की ज़रूरत के बजाय आपकी आंतरिक सीमाओं के आस-पास संगठित है, और यह दोनों पक्षों पर महंगा है: उपयोगकर्ता हर हैंड-ऑफ़ पर वही सबूत फिर से दर्ज करता है, और प्रत्येक विभाग इसे फिर से इकट्ठा करने और सत्यापित करने के लिए भुगतान करता है। प्रतिस्पर्धी विचार यह है कि साझा रिकॉर्ड जो “हमें एक बार बताएँ” को संभव बनाता है, उन सिस्टमों और टीमों में एकीकरण की मांग करता है जिनके पास एक-दूसरे के डेटा पर भरोसा करने का कोई इतिहास नहीं हो सकता, इसलिए निर्माण लागत और डेटा-गवर्नेंस काम वास्तविक हैं। हर उस बिंदु से एनोटेट किया गया एक यात्रा मैप लाएँ जहाँ उपयोगकर्ता वह जानकारी देता है जो आपके पास पहले से है, और एक मोटा अनुमान कि कितने अलग-अलग रिकॉर्ड एक ही फ़ील्ड संग्रहीत करते हैं। कई एजेंसियों तक फैली किसी सरकारी सेवा के लिए, उनके बीच वह डेटा साझा करने का कानूनी आधार जोड़ें, क्योंकि सहमति, गोपनीयता कानून, और सूचना-गवर्नेंस नियम तय करते हैं कि क्या “हमें एक बार बताएँ” इसकी सामर्थ्य पूछने से पहले भी अनुमति है।
जब किसी टीम, सिस्टम, या चैनल के बीच संदर्भ हैंड-ऑफ़ किया जाता है, तो केस के साथ वास्तव में क्या यात्रा करता है, और जब हैंड-ऑफ़ विफल होती है तो क्या होता है? हैंड-ऑफ़ वे जगहें हैं जहाँ सेवाएँ चुपचाप टूटती हैं, क्योंकि यह विफलता उस उपयोगकर्ता को छोड़कर बाकी सबके लिए अदृश्य होती है जो इंतज़ार करता रह जाता है, और एक बड़े संगठन में हर हैंड-ऑफ़ एक ऐसी सीमा को पार करती है जहाँ कोई एक मालिक यह महसूस नहीं करता कि जो छूट गया उसके लिए वह ज़िम्मेदार है। जानबूझकर तय करें कि किस डेटा, इतिहास, और स्थिति को केस के साथ चलना चाहिए, क्या प्राप्तकर्ता पक्ष इसे देख सकता है, और जब कोई स्थानांतरण अटक जाता है या अधूरा पहुँचता है तो पुनर्प्राप्ति मार्ग क्या है। किसी वास्तविक यात्रा के लिए अपना सेवा ब्लूप्रिंट लाएँ और हर उस रेखा का पता लगाएँ जहाँ केस हाथ बदलता है, यह चिह्नित करते हुए कि कौन सा संदर्भ संरक्षित है और क्या फिर से टाइप किया गया या खो गया है। सेवा-स्तर समझौतों या वैधानिक प्रतिक्रिया समय से बंधी एंटरप्राइज़ और सार्वजनिक-क्षेत्र की सेवाओं में, प्रत्येक हैंड-ऑफ़ को सहमत संदर्भ और एक परिभाषित बैकअप योजना वाला एक स्पष्ट अनुबंध मानें, क्योंकि एक अदस्तावेज़ीकृत हैंड-ऑफ़ एक ऐसा उल्लंघन है जो होने की प्रतीक्षा कर रहा है जिसकी कोई डैशबोर्ड आपको चेतावनी नहीं देगा।

क्षेत्र लेंस

स्टार्टअप। मुट्ठी भर लोगों और विस्तृत कलाकृतियों के लिए समय न होने के कारण, केवल उस एक यात्रा को ब्लूप्रिंट करें जो आपके मूल मूल्य को वहन करती है, और उसे केवल इतना ब्लूप्रिंट करें कि यह देखा जा सके कि फ्रंट-स्टेज कहाँ किसी धीमे या मैनुअल बैक-स्टेज को हैंड-ऑफ़ करता है। इसे एक दोपहर में व्हाइटबोर्ड पर करें, छह-हफ़्ते के अध्ययन के रूप में नहीं। आपका फ़ायदा यह है कि पूरी सेवा कुछ ही दिमागों में रहती है, इसलिए एक टूटी हुई हैंड-ऑफ़ को ठीक करना एक क्रॉस-डिपार्टमेंट बातचीत के बजाय एक बातचीत है। उस फ़ायदे को उन सीमाओं के बढ़ने से पहले खर्च कर लें जो हैंड-ऑफ़ को महंगा बनाती हैं।

छोटा व्यवसाय। आपके पास कोई सेवा डिज़ाइनर नहीं है और उसके लिए कोई बजट नहीं है, इसलिए व्यावहारिक कदम है अपनी खुद की यात्रा को एक ग्राहक के रूप में चलना, हर उस बिंदु को नोट करना जहाँ आप किसी को खुद को दोहराने या किसी मैनुअल चरण पर इंतज़ार करने पर मजबूर करते हैं, और सबसे बुरे को ठीक करना। उन टूल को प्राथमिकता दें जो पहले से ही आपके चैनलों को जोड़ते हैं (एक साझा इनबॉक्स, एक बुकिंग सिस्टम जो स्टाफ़ को सूचित करता है) बजाय ऐसे एकीकरण बनाने के जिसे आप बनाए नहीं रख सकते। जब आप कोई सिस्टम ख़रीदें, तो तौलें कि वह अगले चरण को संदर्भ कितनी अच्छी तरह सौंपता है, क्योंकि एक सस्ता टूल जो बिक्री और पूर्ति के बीच ग्राहक के विवरण को गिरा देता है, वह आपको खोए हुए दोबारा-व्यवसाय में बचाई गई राशि से अधिक की लागत देता है।

एंटरप्राइज़। मूल समस्या यह है कि एक ही यात्रा बिक्री, प्रावधान, बिलिंग, और सहायता से होकर गुज़रती है, प्रत्येक के पास हरे स्थानीय मीट्रिक हैं और कोई भी पूरे के लिए जवाबदेह नहीं है। अपनी उच्च-मात्रा, उच्च-दांव यात्राओं के लिए पूर्ण सेवा ब्लूप्रिंट में निवेश करें, जोड़ों पर अधिकार रखने वाला एक नामित शुरू-से-अंत मालिक नियुक्त करें, और एक शुरू-से-अंत मीट्रिक मानकीकृत करें जो ऑडिट से बचे और टीमों में प्राथमिकता तय करे। साझा केस रिकॉर्ड और स्टाफ़-मुखी कंसोल को वित्तपोषित उत्पाद मानें, और हर क्रॉस-टीम हैंड-ऑफ़ को सहमत संदर्भ और सेवा स्तरों वाला एक स्पष्ट अनुबंध बनाएँ।

सरकार। सेवाओं को नागरिक की जीवन-घटना के आस-पास संगठित होना चाहिए, एजेंसी की संरचना के आस-पास नहीं, और पारदर्शिता व सार्वजनिक जवाबदेही के साथ प्रकाशित सेवा मानकों के अनुरूप रखा जाना चाहिए। खरीद नियम यह आकार देते हैं कि आप क्या बना सकते हैं, इसलिए साझा रिकॉर्ड और “हमें एक बार बताएँ” पैटर्न को वहाँ प्राथमिकता दें जहाँ डेटा साझाकरण का कानूनी आधार मौजूद है, और प्रवाह डिज़ाइन करने से पहले उस आधार का दस्तावेज़ीकरण करें। वास्तविक उपयोगकर्ताओं के साथ शोध करें, सबसे संवेदनशील लोगों सहित, क्रॉस-एजेंसी बैक-स्टेज को ब्लूप्रिंट करें, और हर एजेंसी के हिस्से के बजाय पूरी यात्रा को मापें, क्योंकि जनता सेवा का आकलन इससे करती है कि उन्हें परिणाम मिला या नहीं, इससे नहीं कि कौन सा विभाग सफल हुआ।

उदाहरण

स्टार्टअप। होम-इंश्योरेंस उत्पाद बेचने वाले दस लोगों के एक स्टार्टअप ने खुद को एक ऐप कंपनी माना, और उसका ऐप वास्तव में अच्छा था। लेकिन मंथन अधिक था और सहायता डूब रही थी, इसलिए संस्थापकों ने वास्तविक दावा यात्रा को ब्लूप्रिंट किया। उन्होंने पाया कि असली सेवा वह क्षण था जब किसी ग्राहक के घर में आधी रात को पाइप फट जाता था: ऐप एक ईमेल कतार को हैंड-ऑफ़ करता था, जो एक तीसरे-पक्ष के आकलनकर्ता को हैंड-ऑफ़ करता था जिसे ग्राहक देख नहीं सकता था, जो काम के घंटों के दौरान एक अज्ञात नंबर से वापस कॉल करता था जो वॉइसमेल पर चला जाता था। चमकाया हुआ फ्रंट-स्टेज एक धीमे, अपारदर्शी बैक-स्टेज के ऊपर बैठा था, और “महत्वपूर्ण क्षण,” एक तनावपूर्ण दावा, ठीक वहीं था जहाँ यह विफल हुआ। हैंड-ऑफ़ को ठीक करने, ग्राहक को आकलनकर्ता चरण में दृश्यता देने, और दावा वर्कफ़्लो को उत्पाद के हिस्से के रूप में मानने ने किसी भी नई ऐप सुविधा से अधिक रिटेंशन के लिए किया।

एंटरप्राइज़। एक दूरसंचार कंपनी दो-मिनट के ऑनलाइन ऑर्डर और दो-हफ़्ते की डिलीवरी दुःस्वप्न के साथ व्यावसायिक इंटरनेट बेचती थी। बिक्री, प्रावधान, फ़ील्ड इंजीनियरिंग, और बिलिंग में से प्रत्येक यात्रा के एक हिस्से का मालिक था और प्रत्येक अपने खुद के लक्ष्य हासिल करता था, जबकि ग्राहक वही जानकारी बार-बार माँगे जाने, छूटी हुई अपॉइंटमेंट विंडो, और एक पहला बिल जो उद्धरण से मेल नहीं खाता था, का अनुभव करता था। सभी चार विभागों में सेवा ब्लूप्रिंटिंग ने जोड़ों को उजागर किया: हर हैंड-ऑफ़ पर संदर्भ मर जाता था क्योंकि ऑर्डर का कोई साझा रिकॉर्ड ग्राहक के साथ नहीं चलता था। कंपनी ने एक शुरू-से-अंत ऑर्डर-से-सक्रियण मालिक नियुक्त किया, एक साझा केस रिकॉर्ड बनाया जो ऑर्डर के साथ यात्रा करता था, और जुड़े हुए परिणाम के आस-पास टीम प्रोत्साहनों को फिर से जोड़ा। स्थानीय मीट्रिक शायद ही बदले; शुरू-से-अंत सक्रियण समय और शिकायत दर दोनों तेज़ी से गिरे।

सरकार। एक राष्ट्रीय सरकार ने अपनी “परिवार के सदस्य की मृत्यु” सेवा को फिर से डिज़ाइन किया, जो किसी नागरिक के सामने आने वाली सबसे कठिन जीवन-घटनाओं में से एक है। पहले शोक-संतप्त व्यक्ति को कर प्राधिकरण, पेंशन सेवा, वाहन एजेंसी, पासपोर्ट कार्यालय, और स्थानीय सरकार को अलग-अलग सूचित करना पड़ता था, प्रत्येक के अपने फ़ॉर्म के साथ और प्रत्येक वही मृत्यु प्रमाण पत्र माँगता था। एजेंसियों के बजाय जीवन-घटना के आस-पास सेवा को संगठित करते हुए, टीम ने एक एकल “हमें एक बार बताएँ” यात्रा बनाई जो किसी व्यक्ति द्वारा दर्ज की गई जानकारी लेती थी और उसे दृश्यता की रेखा के पीछे हर प्रासंगिक विभाग को वितरित करती थी। सार्वजनिक क्षेत्र के सेवा मानक के अनुरूप, उन्होंने हाल ही में शोक-संतप्त लोगों के साथ शोध किया, क्रॉस-एजेंसी बैक-स्टेज को ब्लूप्रिंट किया, और हर एजेंसी के हिस्से के बजाय पूरी यात्रा को मापा। पूर्णता बढ़ी, डुप्लिकेट संपर्क घटा, और नागरिकों को अब एक शोक को दर्जन भर बार फिर से जीने की ज़रूरत नहीं थी।

व्यावसायिक मामला: प्रेरणाएँ, ROI, और TCO

सेवा डिज़ाइन पर प्रतिफल चैनलों और टीमों के बीच के अंतराल को बंद करने से आता है, क्योंकि यही वह जगह है जहाँ मूल्य रिसता है। शुरू-से-अंत विफलताएँ ऐसे तरीकों से महंगी होती हैं जिन्हें प्रति-चैनल डैशबोर्ड छुपाते हैं: एक यात्रा जो ऑनलाइन पूरी होती है लेकिन बैक-स्टेज में विफल हो जाती है, एक सहायता संपर्क, एक दोबारा-प्रयास, और अक्सर एक खोया हुआ ग्राहक पैदा करती है, और इनमें से कोई भी लागत उस चैनल पर नहीं गिरती जो सफल दिखता है। जब आप पूरी सेवा को मापते और ठीक करते हैं, तो आप दोहराए गए प्रयास (वही डेटा पाँच बार कैप्चर किया गया), विफलता मांग (सिर्फ इसलिए होने वाले संपर्क कि सेवा पहली बार में विफल हो गई), और ऐसे अनुभवों से मंथन को कम करते हैं जो टूटे हुए महसूस हुए भले ही हर हिस्सा तकनीकी रूप से काम कर रहा था। एंटरप्राइज़ में यह भुगतान छोटे ऑर्डर-से-नकदी चक्रों और कम आगे बढ़ोतरियों के रूप में दिखाई देता है; सरकार में यह सेवा करने की कम लागत और उन सेवाओं की उच्च सफल पूर्णता के रूप में दिखाई देता है जो लोगों को कहीं और नहीं मिल सकतीं।

कुल स्वामित्व लागत को सेवा डिज़ाइन करने की लागत को उस बहुत बड़ी लागत के मुकाबले तौलना होगा जो आप पहले से खंडन के रूप में वहन कर रहे हैं। दृश्यमान लागतें हैं शोध, ब्लूप्रिंटिंग, टीमों में समन्वय, और कभी-कभी साझा सिस्टम और स्टाफ़ टूल में निवेश। इसे न करने की छुपी हुई लागतें सहायता बजट, संचालन, और प्रतिष्ठा को होने वाले नुकसान में फैली होती हैं, और यही ठीक कारण है कि नेतृत्व उन्हें कम आंकता है: किसी एक टीम का बजट टूटी हुई हैंड-ऑफ़ की पूरी कीमत नहीं दिखाता। मामला बनाने के लिए, किसी एक उच्च-मात्रा यात्रा में विफलता मांग और दोहराए गए काम पर एक संख्या डालें, उसे ब्लूप्रिंट करें, और नेतृत्व को दिखाएँ कि कितनी लागत उनकी मौजूदा टीमों के बीच के जोड़ों में बैठी है। फिर उस यात्रा पर एक सीमित पायलट चलाएँ, पहले और बाद में शुरू से अंत तक मापें, और परिणाम का उपयोग कठिन संरचनात्मक बदलावों के लिए तर्क देने में करें। सेवा डिज़ाइन को उस लागत को हटाने के रूप में प्रस्तुत करना जो पहले से ही चुकाई जा रही है, बस अदृश्य रूप से, सुरुचिपूर्णता की किसी भी अपील की तुलना में वित्त और गवर्नेंस हितधारकों को अधिक हिलाता है।

विरोधी पैटर्न और नुकसान

चैनल द्वीप। प्रत्येक चैनल को अपने आप में डिज़ाइन और मापा जाता है, इसलिए यात्रा हर जगह ठीक दिखती है लेकिन शुरू से अंत तक कहीं काम नहीं करती।
फ्रंट-स्टेज लिपस्टिक। एक चमकाया हुआ UI जो किसी धीमे या मैनुअल बैक-स्टेज पर लगा है, इसलिए अनुभव उसी क्षण टूट जाता है जब उपयोगकर्ता को बैक-स्टेज की प्रतिक्रिया की ज़रूरत होती है।
सेवा के रूप में संगठन चार्ट। उपयोगकर्ता के लक्ष्य के बजाय आपके विभागों के आस-पास संरचित सेवाएँ, उपयोगकर्ता को आपकी आंतरिक सीमाओं में नेविगेट करने पर मजबूर करती हैं।
ब्लूप्रिंट तमाशा। विस्तृत ब्लूप्रिंट एक बार बनाए गए, सराहे गए, और कभी यह बदलने के लिए उपयोग नहीं किए गए कि सेवा वास्तव में कैसे चलती है।
केवल-हैप्पी-पाथ मैपिंग। यात्राएँ और ब्लूप्रिंट जो विफलता और पुनर्प्राप्ति को नज़रअंदाज़ करते हैं, जो कि वह जगह है जहाँ वास्तविक सेवाओं को असली चोट लगती है।
उपेक्षित स्टाफ़ टूल। आंतरिक, स्टाफ़-मुखी सिस्टम को दूसरे दर्जे का मानना, ताकि उनका घर्षण सीधे ग्राहक तक रिसता रहे।
हैंड-ऑफ़ भूलने की बीमारी। टीम, सिस्टम, या चैनल के बीच हर स्थानांतरण पर संदर्भ खो जाना, ताकि उपयोगकर्ता बार-बार अपनी स्थिति फिर से समझाए।
चापलूसी करने वाले मीट्रिक। स्थानीय, प्रति-चैनल लक्ष्य जो हरे बने रहते हैं जबकि शुरू-से-अंत परिणाम चुपचाप विफल होता है।

परिपक्वता मॉडल

स्तर 1, आरंभ करें: प्रत्येक चैनल और टीम को अलगाव में, प्रतिक्रियाशील रूप से डिज़ाइन और चलाया जाता है। कोई शुरू-से-अंत सेवा का मालिक नहीं है, कोई यात्रा मैप या ब्लूप्रिंट नहीं है, और बैक-स्टेज विफलताएँ शिकायतों के रूप में सामने आने तक अदृश्य रहती हैं। उपयोगकर्ता नियमित रूप से चैनलों में खुद को दोहराते हैं क्योंकि किसी ने पूरे को नहीं देखा है।
स्तर 2, विकसित करें: कुछ यात्राओं को मैप किया गया है और सबसे बुरे क्रॉस-चैनल अंतराल ज्ञात हैं, लेकिन अभ्यास असंगत है और व्यक्तिगत उत्साह पर निर्भर करता है। यात्रा मैप मौजूद हैं फिर भी शायद ही कभी बैक-स्टेज तक पहुँचते हैं, स्वामित्व अभी भी प्रति-चैनल है, स्टाफ़-मुखी टूल बाद की सोच हैं, और जहाँ ब्लूप्रिंटिंग होती भी है वह टीम-दर-टीम अलग होती है।
स्तर 3, मानकीकृत करें: प्रमुख यात्राओं को ऑपरेशनल स्टाफ़ के साथ फ्रंट-स्टेज से बैक-स्टेज तक ब्लूप्रिंट किया जाता है, एक दस्तावेज़ीकृत तरीके का उपयोग करके जो पूरे संगठन में लगातार लागू होता है। नामित सेवा मालिक शुरू से अंत तक जवाबदेह हैं, हैंड-ऑफ़ सहमत संदर्भ वाले स्पष्ट अनुबंध हैं, स्टाफ़ टूल जानबूझकर डिज़ाइन किए जाते हैं, और यह दृष्टिकोण वैकल्पिक के बजाय लागू किया जाता है।
स्तर 4, प्रबंधित करें: सेवा को डेटा के साथ मापा और नियंत्रित किया जाता है। शुरू-से-अंत पूर्णता, शुरू-से-अंत समय (अदृश्य बैक-स्टेज प्रतीक्षा सहित), उपयोगकर्ता प्रयास, विफलता मांग, और चैनल-से-चैनल ड्रॉप-ऑफ़ को आधाररेखाओं के मुकाबले ट्रैक किया जाता है, और हैंड-ऑफ़ विफलताओं और डुप्लिकेट डेटा कैप्चर को मान लेने के बजाय मात्रात्मक रूप से मापा जाता है। ब्लूप्रिंट को वर्तमान रखा जाता है, सेवा मालिकों को शुरू-से-अंत लक्ष्यों पर रखा जाता है, और बदलावों पर जाने-या-न-जाने के निर्णय स्थानीय चैनल मीट्रिक के बजाय उस सबूत पर टिके होते हैं।
स्तर 5, समन्वित करें: टीम डिज़ाइन और सेवा डिज़ाइन संरेखित हैं ताकि स्वामित्व यात्रा का अनुसरण करे, और संगठन विभागों के बजाय उपयोगकर्ता लक्ष्यों और जीवन-घटनाओं के आस-पास संरचित है। शुरू-से-अंत मीट्रिक प्राथमिकता तय करते हैं, संगठन लगातार अनुभव और संचालन दोनों को एक साथ ब्लूप्रिंट, माप, और पुनर्आकार देता है, और जैसे-जैसे उपयोगकर्ता की ज़रूरतें, चैनल, और क्रॉस-टीम सीमाएँ बदलती हैं, यह पूरी सेवा को अनुकूलित करता है।

चर्चा के लिए विचार

जब कोई यात्रा कई टीमों को पार करती है, तो क्या एक शुरू-से-अंत मालिक नियुक्त करना बेहतर है या टीमों को यात्रा के आस-पास फिर से खींचना, और चुनाव क्या तय करता है?
आपकी सेवा गुणवत्ता का कितना हिस्सा बेहतर फ्रंट-स्टेज डिज़ाइन से ठीक किया जा सकता है, और कितने के लिए बैक-स्टेज या संगठन चार्ट को बदलना ज़रूरी है?
आपकी सेवा में उपयोगकर्ताओं को सबसे अधिक बार कहाँ खुद को दोहराना पड़ता है, और एक “हमें एक बार बताएँ” संस्करण बनाने में क्या लागत आएगी?
जब स्टाफ़-मुखी टूल के उपयोगकर्ता बंधे हुए हों और अपने पैरों से वोट नहीं कर सकते, तो आप उन्हें कैसे वित्तपोषित और प्राथमिकता देते हैं?
क्या सेवाओं को जीवन-घटनाओं या उपयोगकर्ता लक्ष्यों के आस-पास संगठित होना चाहिए भले ही यह सीधे आपकी वित्तपोषण और रिपोर्टिंग रेखाओं के ख़िलाफ़ जाता हो?
कौन सा एकल शुरू-से-अंत मीट्रिक आपको सबसे अच्छी तरह बताएगा कि आपकी पूरी सेवा काम कर रही है, और आप इसे आज क्यों नहीं ट्रैक करते?

मुख्य निष्कर्ष

पूरी सेवा को चैनलों में और समय के साथ डिज़ाइन करें, एक स्क्रीन को नहीं, और याद रखें कि उपयोगकर्ता को इससे कोई फ़र्क़ नहीं पड़ता कि आपकी टीम की सीमाएँ कहाँ गिरती हैं।
फ्रंट-स्टेज और बैक-स्टेज एक ही सिस्टम हैं; कोई शानदार अनुभव तभी तक अच्छा है जब तक उसके पीछे का संचालन उसे टिकाए रख सकता है।
सेवा ब्लूप्रिंट आपकी मूल कलाकृति है: यह फ्रंट-स्टेज टचपॉइंट को बैक-स्टेज लोगों, सिस्टमों, और उन्हें प्रदान करने वाली हैंड-ऑफ़ से जोड़ता है।
संगठन चार्ट सेवा में दिखाई देता है (कॉनवे का नियम), इसलिए सेवा डिज़ाइन और टीम डिज़ाइन को साथ-साथ चलना चाहिए।
स्टाफ़-मुखी टूल और टीमों के बीच की हैंड-ऑफ़ को सेवा के प्रथम-श्रेणी हिस्सों के रूप में मानें, क्योंकि उनका घर्षण ग्राहक तक पहुँचता है।
सेवा को शुरू से अंत तक मापें, पहले इरादे से वास्तविक परिणाम तक, और अपने विभागों के बजाय उपयोगकर्ता के लक्ष्य या जीवन-घटना के आस-पास संगठित करें।

संदर्भ और आगे पढ़ने के लिए

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, सेवा ब्लूप्रिंटिंग और ग्राहक यात्रा मैपिंग पर लेख