गाइड · सर्विस बिज़नेस का कामकाज
पूछताछ से सौंपे गए काम और जाँचे हुए जवाब तक का मैप बनाएँ
एक सर्विस पूछताछ को आने से लेकर ज़िम्मेदार व्यक्ति, जाँचे हुए जवाब और साफ़ अगले काम तक मैप करें। वर्कशीट इस्तेमाल करें और चार काल्पनिक सैंपल रास्ते आज़माएँ।
लेखक: Fireflax · 9 मिनट में पढ़ें
समीक्षक: Codex — source and implementation review ·
रिक्वेस्ट खो जाने से पहले उसे एक ज़िम्मेदार व्यक्ति दें।
एक ग्राहक किसी प्लंबिंग बिज़नेस से टपकते किचन नल के बारे में पूछता है। रिक्वेस्ट एक शेयर्ड इनबॉक्स में पहुँचती है। एक व्यक्ति मान लेता है कि कोई साथी जवाब देगा; साथी मान लेता है कि कोई उपलब्धता देख रहा है। जो कदम छूट गया, वह है एक साफ़ ज़िम्मेदार व्यक्ति और अगला काम।
सॉफ़्टवेयर ख़रीदने से पहले आप इस हैंडऑफ़ का मैप किसी नोटबुक या शेयर्ड डॉक्यूमेंट में बना सकते हैं। नीचे दी गई वर्कशीट से लिखें कि पूछताछ कहाँ आती है, क्या चाहिए, उसे कौन जाँचता है और हैंडऑफ़ फ़ेल हो तो क्या होता है।
उदाहरण के बारे में
Northstar Plumbing और उसके संपर्क काल्पनिक हैं। Fireflax सैंपल लोकल रूटिंग नियम और जवाब के टेम्पलेट इस्तेमाल करता है। कोई लाइव AI मॉडल या CRM नहीं जुड़ा है, और कुछ भी भेजा नहीं जाता। आज़माते समय काल्पनिक जानकारी इस्तेमाल करें। ये सैंपल के नतीजे हैं, ग्राहकों के नतीजे नहीं।
जब कोई उपलब्ध न हो तो क्या होता है?
पूछताछ मिलने का मतलब यह नहीं कि काम स्वीकार हो गया या कोई अभी जवाब दे रहा है। अपने असली मैप में काम के घंटे, अगली बार कब कोई देखेगा, एक मुख्य और एक बैकअप भूमिका, और इंतज़ार के दौरान ग्राहक को क्या बताया जाता है, दर्ज करें। इलाके से बाहर की, अर्जेंट और अस्पष्ट रिक्वेस्ट को एक नाम वाली अपवाद कतार में रखें। इमरजेंसी या चौबीसों घंटे की सुविधा का वादा तब तक न करें जब तक वह सर्विस सच में मौजूद न हो।
सैंपल कोई असली ड्यूटी रोस्टर, कैलेंडर, फ़ोन लाइन या सर्विस एरिया नहीं जाँचता। इसका प्राथमिकता वाला लेबल एक काल्पनिक रूटिंग नतीजा है, इमरजेंसी में जवाब का वादा नहीं। अगर असली हैंडऑफ़ फ़ेल हो जाए, तो रिक्वेस्ट को दिखता रहने दें और तय मैनुअल कतार इस्तेमाल करें, जब तक कोई व्यक्ति अगला कदम कन्फ़र्म न करे।
पाँच स्टेप और उनके अपवादों का मैप बनाएँ।
रिक्वेस्ट मिली → जानकारी जाँची → ज़िम्मेदार व्यक्ति → रिव्यू → अगला काम
- 01
पाएँ
रिक्वेस्ट और जवाब देने का तरीका एक साथ रखें।
- 02
जानकारी जाँचें
कोई वादा करने से पहले जो छूटा है, वह पूछें।
- 03
सौंपें
अगला काम एक व्यक्ति को दें।
- 04
रिव्यू
सुझाया गया जवाब पढ़ें और बदलें।
- 05
दर्ज करें
नतीजा और आगे कौन काम करेगा, लिखें।
छूटी जानकारी → जाँचा हुआ स्पष्टीकरण → जवाब का इंतज़ार।
दोहराई गई रिक्वेस्ट → उसके मौजूदा रिकॉर्ड पर वापस।
सैंपल हैंडऑफ़ फ़ेल → रोकें → रीस्टोर → फिर से रिव्यू।
इस सैंपल में आम प्लंबिंग और सामान्य रिक्वेस्ट सर्विस कोऑर्डिनेटर के पास जाती हैं। कोटेशन की रिक्वेस्ट कोटेशन टीम के पास जाती है। “burst” या “urgent” जैसा प्राथमिकता वाला शब्द होने पर रिक्वेस्ट रिव्यू के लिए ड्यूटी मैनेजर के पास जाती है, अर्जेंट कोटेशन भी। ये आसान नियम हर हालात को नहीं समझते, मदद नहीं भेजते और उपलब्धता कन्फ़र्म नहीं करते।
रिक्वेस्ट, ज़िम्मेदार व्यक्ति और फ़ैसला एक साथ रखें।
यह मैपिंग सैंपल के नया काम उदाहरण पर आधारित है। अपने प्रोसेस में इन लेबल की जगह अपने इनबॉक्स, फ़ॉर्म या जॉब सिस्टम के फ़ील्ड लिखें। यह न मानें कि दो टूल्स में मिलते-जुलते नाम वाले फ़ील्ड का मतलब एक ही है।
| कहाँ से → कहाँ | काल्पनिक वैल्यू | इसका इस्तेमाल कैसे होता है |
|---|---|---|
| रिक्वेस्ट पर लिखा नाम → ग्राहक का नाम | Alex Morgan | ड्राफ़्ट के अभिवादन में इस्तेमाल होता है। सिर्फ़ नाम मिलने से यह साबित नहीं होता कि दो रिक्वेस्ट एक ही हैं। |
| जवाब का पता → उदाहरण ईमेल | alex@example.com | ईमेल जैसी सही वैल्यू होनी चाहिए। एक जैसी सैंपल रिक्वेस्ट पहचानने के लिए इलाके और मैसेज के साथ इस्तेमाल होता है। |
| काम की जगह → इलाका या पोस्टकोड | Bristol BS1 | ख़ाली इलाका रिव्यू में ले लिया जाता है, लेकिन ड्राफ़्ट उसे माँगता है। इससे सर्विस कवरेज साबित नहीं होता। |
| रिक्वेस्ट का टेक्स्ट → ग्राहक का मैसेज | रसोई का नल एक हफ़्ते से टपक रहा है… | मूल रिक्वेस्ट दिखती रहती है। आसान शब्द-नियम कैटेगरी चुनते हैं; छोटा मैसेज होने पर और जानकारी माँगी जाती है। |
| रूटिंग नियम → ज़िम्मेदार व्यक्ति | प्लंबिंग की पूछताछ → सर्विस कोऑर्डिनेटर | सैंपल एक भूमिका सौंपता है। अपनी वर्कशीट में उस भूमिका को संभालने वाले असली व्यक्ति और उनके बैकअप का नाम लिखें। |
| व्यक्ति का रिव्यू → जवाब और नतीजा | आपकी मंज़ूरी चाहिए → डेमो पूरा हुआ | मंज़ूरी जाँचा हुआ टेक्स्ट और एक नकली नतीजा दर्ज करती है। इससे न मैसेज जाता है, न काम बुक होता है, न CRM अपडेट होता है। |
रिक्वेस्ट पर लिखा नाम → ग्राहक का नाम
Alex Morgan
ड्राफ़्ट के अभिवादन में इस्तेमाल होता है। सिर्फ़ नाम मिलने से यह साबित नहीं होता कि दो रिक्वेस्ट एक ही हैं।
जवाब का पता → उदाहरण ईमेल
alex@example.com
ईमेल जैसी सही वैल्यू होनी चाहिए। एक जैसी सैंपल रिक्वेस्ट पहचानने के लिए इलाके और मैसेज के साथ इस्तेमाल होता है।
काम की जगह → इलाका या पोस्टकोड
Bristol BS1
ख़ाली इलाका रिव्यू में ले लिया जाता है, लेकिन ड्राफ़्ट उसे माँगता है। इससे सर्विस कवरेज साबित नहीं होता।
रिक्वेस्ट का टेक्स्ट → ग्राहक का मैसेज
रसोई का नल एक हफ़्ते से टपक रहा है…
मूल रिक्वेस्ट दिखती रहती है। आसान शब्द-नियम कैटेगरी चुनते हैं; छोटा मैसेज होने पर और जानकारी माँगी जाती है।
रूटिंग नियम → ज़िम्मेदार व्यक्ति
प्लंबिंग की पूछताछ → सर्विस कोऑर्डिनेटर
सैंपल एक भूमिका सौंपता है। अपनी वर्कशीट में उस भूमिका को संभालने वाले असली व्यक्ति और उनके बैकअप का नाम लिखें।
व्यक्ति का रिव्यू → जवाब और नतीजा
आपकी मंज़ूरी चाहिए → डेमो पूरा हुआ
मंज़ूरी जाँचा हुआ टेक्स्ट और एक नकली नतीजा दर्ज करती है। इससे न मैसेज जाता है, न काम बुक होता है, न CRM अपडेट होता है।
डेमो को एक नाम, एक सही उदाहरण ईमेल और ख़ाली न हो ऐसा मैसेज चाहिए। ख़ाली इलाका या 20 अक्षरों से छोटा मैसेज होने पर स्पष्टीकरण माँगने वाला ड्राफ़्ट बनता है। ये समझाने वाली जाँचें हैं, इस बात का पूरा आकलन नहीं कि काम बुक हो सकता है या नहीं।
चार रास्ते आज़माएँ, मुश्किल वाले भी।
पूछताछ सैंपल खोलें और ये स्टेप फ़ॉलो करें। हर अलग टेस्ट डेमो रीसेट करें से शुरू होता है। डुप्लिकेट टेस्ट के लिए वही कतार रखें। ये नतीजे 8 अक्टूबर 2026 को सैंपल पर जाँचे गए।
1. काम की एक पूरी नई रिक्वेस्ट
डेमो रीसेट करें चुनें, फिर नया काम और पूछताछ चलाएँ। Alex Morgan की टपकते नल वाली रिक्वेस्ट DEMO-001 बनती है, एक प्लंबिंग की पूछताछ जिसका ज़िम्मेदार सर्विस कोऑर्डिनेटर है। ड्राफ़्ट पढ़ें या बदलें, फिर डेमो जवाब को मंज़ूरी दें चुनें।
देखा गया नतीजा: कतार में एक रिकॉर्ड रहता है। मंज़ूरी जाँचा हुआ जवाब दर्ज करती है और उसका लेबल डेमो पूरा हुआ कर देती है। कोई ईमेल नहीं जाता, और कोई बुकिंग या कोटेशन कन्फ़र्म नहीं होता।
आपके हैंडऑफ़ के लिए: आपके असली प्रोसेस में कोऑर्डिनेटर उपलब्धता देखेगा और उस सिस्टम में अगला काम चुनेगा जो आपकी टीम पहले से इस्तेमाल करती है।
2. छूटी जानकारी वाली रिक्वेस्ट
रीसेट करें, अधूरी जानकारी और पूछताछ चलाएँ चुनें। Sam Taylor के “मदद कर सकते हैं?” में कोई इलाका नहीं है। सैंपल सामान्य पूछताछ को सर्विस कोऑर्डिनेटर को सौंपता है और रिव्यू के लिए स्पष्टीकरण तैयार करता है। सैंपल का नतीजा दर्ज करने के लिए इसे मंज़ूर करें।
देखा गया नतीजा: रिकॉर्ड इलाका या पोस्टकोड और काम के बारे में और जानकारी माँगता है। मंज़ूरी के बाद भी यह अनसुलझा रहता है, जानकारी का इंतज़ार लेबल के साथ। सैंपल ग्राहक का जवाब नहीं पाता और न ही आपके लिए वो जानकारी भरता है।
आपके हैंडऑफ़ के लिए: उस व्यक्ति का नाम तय करें जो जवाब पर नज़र रखेगा और असली पूछताछ अपडेट करेगा। छूटी जानकारी को माना हुआ अपॉइंटमेंट नहीं बनना चाहिए।
3. वही रिक्वेस्ट दो बार आती है
रीसेट करें, नया काम और पूछताछ चलाएँ चुनें। बिना रीसेट किए वही पूछताछ फिर से चलाएँ। नोटिस में लिखा आता है “DEMO-001 के रूप में पहले ही मिल चुका है। कोई डुप्लिकेट काम नहीं बना।”
देखा गया नतीजा: मौजूदा रिकॉर्ड और इतिहास बने रहते हैं। यह नियम छोटे-बड़े अक्षर और फ़ालतू स्पेस को छोड़कर ईमेल, इलाके और मैसेज की तुलना करता है। ग्राहक का नाम इस तुलना में शामिल नहीं है। मैसेज या इलाका बदलने से अलग रिकॉर्ड बन सकता है।
आपके हैंडऑफ़ के लिए: असली हैंडऑफ़ के लिए तय करें कि दोहराई गई डिलीवरी और दूसरे काम में फ़र्क कैसे करेंगे। यह लोकल तुलना कई इनबॉक्स या CRM में डुप्लिकेट पहचानने वाली सर्विस नहीं है।
4. कनेक्शन फ़ेल होने की नकल
रीसेट करें और नया काम चलाएँ। इस मंज़ूरी पर फ़ेल कनेक्शन आज़माएँ चुनें, फिर डेमो जवाब को मंज़ूरी दें। उदाहरण कनेक्शन वापस चालू करें चुनें, ड्राफ़्ट फिर से पढ़ें और उसे एक बार और मंज़ूर करें।
देखा गया नतीजा: कनेक्शन रुका हुआ है रिकॉर्ड और मंज़ूर टेक्स्ट बनाए रखता है। रीस्टोर इसे आपकी मंज़ूरी चाहिए पर लौटाता है और पिछली मंज़ूरी हटा देता है; यह अपने-आप आगे नहीं बढ़ता। नई मंज़ूरी से उदाहरण पूरा होता है। किसी भी समय कुछ भी भेजा नहीं गया।
आपके हैंडऑफ़ के लिए: असली रिकवरी के ज़िम्मेदार को पहले हर जुड़े सिस्टम में देखना होगा कि क्या हुआ। रीस्टोर बटन रिकवरी की नकल करता है; यह कोई सर्विस दोबारा नहीं जोड़ता और न यह साबित करता है कि असली दोबारा कोशिश सुरक्षित है।
रीसेट, रीलोड या वर्कफ़्लो बदलने पर सैंपल मिट जाता है। इसकी कतार में ज़्यादा से ज़्यादा 20 पूछताछ रहती हैं; यह टिकाऊ जॉब रिकॉर्ड नहीं है। फ़ेलियर का उदाहरण एक नियंत्रित नकल है, किसी बंद पड़े ग्राहक सिस्टम पर टेस्ट नहीं।
पूछताछ सैंपल आज़माएँयह वर्कशीट अपने प्रोसेस में कॉपी करें।
साइन अप की ज़रूरत नहीं है। टेक्स्ट अपने नोट्स में कॉपी करें और ब्रैकेट वाली जगहें भरें। ज़िम्मेदार और बैकअप लोगों के असली नाम लिखें। एक इनबॉक्स और एक तरह की रिक्वेस्ट से शुरू करें; जो पता नहीं, उसे “पता नहीं” लिखकर छोड़ दें ताकि प्रोसेस का ज़िम्मेदार उसे हल करे।
आपकी पूछताछ हैंडऑफ़ वर्कशीट
पूछताछ हैंडऑफ़ वर्कशीट बिज़नेस या टीम: [नाम] प्रोसेस का ज़िम्मेदार और बैकअप: [व्यक्ति / व्यक्ति] समीक्षा की तारीख़: [तारीख़] 1. पाएँ रिक्वेस्ट कहाँ आती हैं: [इनबॉक्स / फ़ॉर्म / फ़ोन नोट्स] मूल रिक्वेस्ट कहाँ रखी जाती है: [रिकॉर्ड या फ़ोल्डर] एक पूछताछ को कैसे पहचानते हैं: [रेफ़रेंस] नई रिक्वेस्ट जाँचने वाला व्यक्ति: [नाम] 2. जानकारी जाँचें अगले काम के लिए ज़रूरी जानकारी: [लिस्ट] ग्राहक की संपर्क पसंद कहाँ दर्ज है: [जगह] छूटी जानकारी का ज़िम्मेदार और अगली जाँच का समय: [नाम / समय] 3. सौंपें आम रिक्वेस्ट किसके पास जाती हैं: [नाम] कोटेशन की रिक्वेस्ट किसके पास जाती हैं: [नाम] प्राथमिकता वाली रिक्वेस्ट किसके पास जाती हैं: [नाम] अगर वह व्यक्ति उपलब्ध न हो: [बैकअप और हैंडऑफ़] 4. रिव्यू ड्राफ़्ट कहाँ तैयार होता है: [जगह] मंज़ूरी देने की इजाज़त किसे है: [नाम] मंज़ूरी से पहले जाँचें: [पाने वाला / आख़िरी बातचीत / जानकारी / वादे / संपर्क की पसंद] 5. अगला काम दर्ज करें नतीजा कहाँ दर्ज होता है: [जगह] अगला काम, ज़िम्मेदार और रिव्यू की तारीख़: [काम / नाम / तारीख़] हैंडऑफ़ सफल हुआ, यह कैसे पता चलता है: [सबूत] अपवाद — हर एक के लिए एक व्यक्ति का नाम लिखें छूटी जानकारी: [नाम / काम / अगली जाँच] संभावित डुप्लिकेट: [नाम / तुलना / रखें या जोड़ें] अर्जेंट या अस्पष्ट रिक्वेस्ट: [नाम / एस्केलेशन] कनेक्शन फ़ेल या अनिश्चित नतीजा: [नाम / रोकें / मंज़िल जाँचें / रिकवरी मंज़ूर करें] जवाब, ऑप्ट-आउट या बदली हुई रिक्वेस्ट: [नाम / रिकॉर्ड अपडेट करें / अगला काम रोकें या बदलें] किसी भी लाइव कनेक्शन से पहले एक छोटा अभ्यास एक पूरी रिक्वेस्ट: [उम्मीद / देखा गया] एक अधूरी रिक्वेस्ट: [उम्मीद / देखा गया] वही रिक्वेस्ट दोबारा: [उम्मीद / देखा गया] एक बीच में रुका हैंडऑफ़: [उम्मीद / देखा गया] अनसुलझे फ़र्क और ज़िम्मेदार: [नोट्स / नाम] किसने और कब स्वीकार किया: [नाम / तारीख़]
ज़िम्मेदार लोगों के साथ एक काल्पनिक रिक्वेस्ट को मैप पर शुरू से आख़िर तक चलाकर देखें। जाँचें कि हर व्यक्ति को पता है कि उसे कहाँ ढूँढना है, वे क्या तय कर सकते हैं और उसे आगे कैसे देना है। अपवाद का ख़ाली ज़िम्मेदार एक काम की खोज है: ऑटोमेटेड हैंडऑफ़ पर निर्भर होने से पहले उसे हल करें।
असली CRM कनेक्शन को अब भी क्या चाहिए
ब्राउज़र कतार फ़ैसलों को दिखाती है। अपना इनबॉक्स या CRM जोड़ना अलग इम्प्लीमेंटेशन का काम है। पहले देखें कि क्या आपके मौजूदा टूल्स यह हैंडऑफ़ कर सकते हैं। फिर ख़ास सिस्टम और अकाउंट के लिए ये बातें तय करें:
- 1
एक्सेस और परमिशन
कन्फ़र्म करें कि कनेक्शन किस अकाउंट का है, वह कौन-से रिकॉर्ड पढ़ या बदल सकता है, और वह एक्सेस कौन वापस ले सकता है। असली कनेक्टर की उपलब्धता और टूल्स की कोई भी लागत जाँचें।
- 2
सटीक फ़ील्ड मैपिंग
असली सोर्स और मंज़िल के फ़ील्ड ID, ज़रूरी वैल्यू और मान्य स्थितियाँ दर्ज करें। कन्फ़र्म करें कि आप संपर्क बना रहे हैं, पूछताछ या टास्क, और मूल रिक्वेस्ट का लिंक रखें।
- 3
डुप्लिकेट और अपडेट के नियम
चुनें कि दोहराई गई डिलीवरी कैसे पहचानी जाएगी, उसी व्यक्ति का दूसरा काम कैसे संभाला जाएगा, और मौजूदा रिक्वेस्ट बदलने पर क्या करना है। डेमो की ईमेल/इलाका/मैसेज वाली तुलना सिर्फ़ एक लोकल उदाहरण है।
- 4
लोग और रिव्यू की सीमाएँ
आम काम और हर अपवाद के ज़िम्मेदार का नाम तय करें। तय करें कि किन कामों को मंज़ूरी चाहिए और अगले काम से पहले ताज़ा जवाब या संपर्क की पसंद कहाँ जाँची जाती है।
- 5
स्वीकृति और रिकवरी
तय एनवायरनमेंट में पूरे, अधूरे, दोहराए गए और बीच में रुके हैंडऑफ़ टेस्ट करें। असली मंज़िल का रिकॉर्ड और किसी भी मैसेज का नतीजा जाँचें। दर्ज करें कि कैसे रोकना है, कौन जाँच करता है, और नतीजा अनिश्चित होने पर दोबारा कोशिश कौन मंज़ूर करता है।
जब जवाब दी गई पूछताछ पर चुप्पी छा जाए
पूछताछ दर्ज करने का काम एक साफ़ अगले कदम पर ख़त्म होता है। अगर आपकी टीम जवाब दे चुकी है और बाद में ग्राहक चुप हो जाता है, तो एक और मैसेज भेजने से पहले आख़िरी बातचीत, समय और रुकने की शर्तें जाँचने के लिए अलग फ़ॉलो-अप चेकलिस्ट इस्तेमाल करें।
फ़ॉलो-अप गाइड पढ़ेंस्रोत और समीक्षा नोट्स
Codex के साथ लिखी गई और समीक्षा की तारीख़ पर दिए गए स्रोतों से जाँची गई। उदाहरण काल्पनिक हैं; ग्राहकों के नतीजों या लाइव इंटीग्रेशन का कोई दावा नहीं है।
- पूछताछ सैंपल आज़माएँ
पूछताछ दर्ज करने और जाँचने के चार काल्पनिक उदाहरण।
- पूछताछ इम्प्लीमेंटेशन का दायरा
दायरा और लाइव कनेक्शन की सीमाएँ।