टिकट केंद्र · सहायता का कंसोल

टिकट केंद्र वह कंसोल है जहाँ आपकी टीम टिकट पर काम करती है: बाईं ओर सहेजे हुए दृश्यों वाली कतार, बीच में ग्राहक से बातचीत, और दाईं ओर SLA की घड़ियों तथा AI के साथ संदर्भ। यहीं आने वाला ईमेल, मैक्रो, रूटिंग, ऑटोमेशन, इंसिडेंट, नॉलेज बेस और टीम की मेट्रिक्स भी रहती हैं।

टिकट केंद्र SellioCRM का सहायता कंसोल है: एक ही जगह जहाँ टिकट कतार में संभाले जाते हैं, ग्राहक के पहले ईमेल से लेकर संतुष्टि सर्वेक्षण तक। यह CRM के उसी टिकट ऑब्जेक्ट का उपयोग करता है, इसलिए जो कुछ आप पहले से दर्ज करते हैं (विषय, कंपनी, संपर्क, श्रेणी, चैनल) वह वैसा ही रहता है और ग्राहक के 360º दृश्य में दिखता है।

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

तीन पैनल का लेआउट

कंसोल तीन पैनल में खुलता है, उन लोगों के लिए बनाया गया जो दिन भर सहायता देते हैं: बाईं ओर गिनती के साथ दृश्य और कतारें, बीच में ग्राहक से बातचीत, दाईं ओर टिकट का संदर्भ। मोबाइल पर दृश्यों वाला पैनल सूची के ऊपर एक चयनकर्ता बन जाता है, ताकि जगह न घेरे।

कतार और सहेजे हुए दृश्य

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

एजेंट का कंसोल

टिकट खोलते ही बातचीत बीच में कालक्रम में दिखती है और गुण दाईं ओर रहते हैं: अनुरोधकर्ता, आने का चैनल, टैग, स्थिति, प्राथमिकता, श्रेणी, सौंपा गया व्यक्ति और समूह। कोई भी गुण बदलते ही वह तुरंत सेव हो जाता है।

1. लिखने वाले बॉक्स में ग्राहक को उत्तर दें चुनें अगर आप ऐसा कुछ लिख रहे हैं जो ग्राहक देखेगा, या आंतरिक नोट चुनें अगर वह केवल टीम को दिखना चाहिए।
2. आंतरिक नोट अलग रंग में उभरा हुआ दिखता है, ताकि वह ग्राहक से कही गई बात से न मिल जाए।
3. संदेश के साथ फ़ाइल भेजने के लिए संलग्न करें दबाएँ (हर फ़ाइल 25 MB तक)। सार्वजनिक उत्तर में अटैचमेंट के लिंक ग्राहक को भेजे गए ईमेल के मुख्य भाग में भी जाते हैं।
4. लिखें और भेजें दबाएँ (या नोट जोड़ें)।

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

मैक्रो और चर

1. शीर्षक और मुख्य भाग के साथ तैयार उत्तर बनाने के लिए मैक्रो प्रबंधित करें दबाएँ।
2. चाहें तो मैक्रो यह भी तय कर सकता है कि उपयोग होने पर कौन सी स्थिति और प्राथमिकता लगे।
3. लिखने वाले बॉक्स में मैक्रो लागू करें से मैक्रो चुनें: उसका मुख्य भाग उत्तर के फ़ील्ड में आ जाता है और, अगर तय हो, तो स्थिति तथा प्राथमिकता भी लग जाती हैं।

मैक्रो और उत्तर दोहरे कोष्ठकों में चर स्वीकार करते हैं, जो भेजते समय भर जाते हैं: {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} और {{org_name}} आदि। चैनल और रूटिंग में आप सहायता का हस्ताक्षर तय करते हैं, जो सार्वजनिक उत्तरों के साथ जुड़ता है; एजेंट का अपना व्यक्तिगत हस्ताक्षर, अगर हो, तो उसे प्राथमिकता मिलती है।

SLA: समय-सीमा, रोक, कार्य समय और अवकाश

SLA की हालत कतार में और टिकट में दिखती है: खुले रहने तक ट्रैक पर या SLA उल्लंघन, और हल होने के बाद समय पर हल हुआ या देर से हल किया गया। दाईं ओर पहले उत्तर, अगले उत्तर और समाधान की घड़ियाँ उलटी गिनती करती हैं और रंग बदलती हैं: हरा, समय-सीमा के पास पीला, और बीत जाने पर लाल। स्थिति को हल किया गया या बंद करते ही समाधान की तारीख़ अपने आप दर्ज हो जाती है।

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

आने वाला ईमेल: ईमेल टिकट बन जाता है

1. टिकट केंद्र खोलें और चैनल और रूटिंग टैब में जाएँ।
2. सहायता का पता बनाएँ पर क्लिक करें। CRM support+aapka-code@domain के रूप में एक पता दिखाता है।
3. अपने ईमेल प्रदाता में सहायता वाले मेलबॉक्स को इस पते पर अग्रेषित करें।
4. बस: नए ईमेल टिकट खोल देते हैं और ग्राहक के उत्तर उसी बातचीत में आ जाते हैं।

भेजने वाले को ईमेल से किसी संपर्क से जोड़ा जाता है; पहली बार में संपर्क बन जाता है, और टिकट का चैनल ईमेल रहता है। ग्राहक को भेजे गए हर उत्तर के विषय में टिकट का कोड [#XXXXXXXX] के रूप में जाता है। जब ग्राहक वह कोड बनाए रखते हुए जवाब देता है, तो संदेश नया टिकट खोलने के बजाय उसी बातचीत में आ जाता है; और अगर टिकट हल या बंद हो चुका था, तो वह दोबारा खुल जाता है।

प्राप्ति की स्वचालित पुष्टि: चैनल और रूटिंग में प्राप्ति की पुष्टि चालू करें और चर के साथ टेक्स्ट लिखें। जब कोई ईमेल नया टिकट खोलता है, तो अनुरोधकर्ता को उसी क्षण प्रोटोकॉल संख्या के साथ पुष्टि मिल जाती है। यह बंद अवस्था में शुरू होती है।

टिकट मर्ज करना और समानांतर बातचीत

जब एक ही विषय दो टिकट बन गया हो, तो जिसे मुख्य रखना है उसे खोलें और मर्ज करें दबाएँ। दूसरे के संदेश मुख्य में चले जाते हैं और वह एक सूचना के साथ बंद हो जाता है जो बताती है कि वह कहाँ गया।

किसी सप्लायर या दूसरी टीम से ऐसे बात करनी है कि ग्राहक न देखे? मुख्य बातचीत के ठीक नीचे समानांतर बातचीत का उपयोग करें: विषय और ईमेल से प्रतिभागी बताएँ, संदेश लिखें, और CRM उसे भेज देता है। सब कुछ टिकट में दर्ज रहता है, ग्राहक वाली बातचीत से अलग।

स्वचालित असाइनमेंट और ऑटोमेशन

चैनल और रूटिंग में हर टीम के लिए तय करें कि समूह में आते ही टिकट कैसे बँटें: बारी-बारी (एजेंट के बीच बदलता है) या भार के अनुसार (जिसके पास सबसे कम खुले टिकट हैं उसे पहले)। हमेशा हाथ से सौंपने के लिए इसे बंद रहने दें।

ऑटोमेशन टैब में आप जब कुछ बदले, तो कार्य करें ढंग के नियम बनाते हैं। हर नियम में एक इवेंट होता है (टिकट बनाया जाता है, या कोई गुण बदलता है), स्थिति, प्राथमिकता, श्रेणी, समूह और ज़िम्मेदार व्यक्ति की वैकल्पिक शर्तें होती हैं, और एक या ज़्यादा कार्रवाइयाँ होती हैं।

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

टिकट पर आर्टिफिशियल इंटेलिजेंस

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

नॉलेज बेस और हेल्प सेंटर

आपकी नॉलेज बेस एक सार्वजनिक स्वयं-सहायता पोर्टल को सामग्री देती है, जिसमें शीर्षक, सामग्री और टैग से खोज होती है। पेज के अंत में मुझे अब भी मदद चाहिए वाला फ़ॉर्म व्यक्ति के लिखते समय ही जुड़े हुए लेख सुझाता है (ताकि टिकट टल जाए) और फिर भी ज़रूरत हो तो सीधे आपके CRM में टिकट खोल देता है।

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

इंसिडेंट और स्थिति पेज

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

संतुष्टि और मेट्रिक्स

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

मेट्रिक्स टैब में आप 7, 30 या 90 दिन की अवधि देखते हैं: बने, हल हुए और खुले टिकट, पहले उत्तर का औसत समय, समाधान का औसत समय, SLA के भीतर रहने का प्रतिशत, उत्तर दर के साथ औसत संतुष्टि, बैकलॉग, पहले ही संपर्क में समाधान, दोबारा खुलने की दर और टीम के अनुसार भार, चैनल तथा श्रेणी के अनुसार बँटवारे और एजेंट के अनुसार एक तालिका के साथ। संकेतक पिछली अवधि की तुलना में बदलाव और एक छोटा दैनिक चार्ट दिखाते हैं, और रिपोर्ट PDF या XLSX में निर्यात की जा सकती हैं।

आम सवाल

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

मूल और उप-टिकट, स्वतः उत्तर के नियम, और चैनल मैपिंग

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

ये कहाँ हैं: पैरेंट और चाइल्ड केस टिकट पर ही, **संबंधित केस** पैनल में दिखते हैं। नियम **सेटिंग्स → स्वचालित उत्तर** में हैं, और मैपिंग **सेटिंग्स → टिकट चैनल** में; दोनों खाता प्रबंधकों के लिए हैं।

केस में तीसरा टैब **संदर्भ** जुड़ा है, और यहीं कंसोल ने आपको दूसरी स्क्रीन पर भेजना बंद किया। इसमें टिकट के अपने फ़ील्ड (आपके बनाए कस्टम फ़ील्ड सहित), संबंधित रिकॉर्ड, गतिविधियाँ और कार्य, फ़ाइलें, पैरेंट और चाइल्ड केस, और उसी ग्राहक के अन्य खुले टिकट दिखते हैं। यदि आपने टिकट ऑब्जेक्ट के लिए Canvas बनाया है, तो वही लेआउट यहाँ भी लागू होता है, इसलिए एक ही चीज़ दो बार बनानी नहीं पड़ती।

परिणाम कोड के साथ टिकट बंद करना

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

इसलिए अब परिणाम एक छोटी सूची है जिसे आप नियंत्रित करते हैं, **सेटिंग्स → परिणाम कोड** में। हर कोड का एक नाम, एक दायरा और एक स्विच होता है जो तय करता है कि उसे चुनने पर स्पष्टीकरण देना ज़रूरी है या नहीं (यह स्विच "अन्य" पर लगाइए, जो अकेले कुछ नहीं समझाता)। यही सूची टिकटों और फ़ोन कॉल दोनों के काम आती है, इसलिए एक ही बात कहने वाली दो शब्दावलियों के बजाय आप एक ही रखते हैं।

1. सेटिंग्स → परिणाम कोड खोलें और डिफ़ॉल्ट सूची बनाएँ पर क्लिक करें, या अपनी सूची खुद लिखें।
2. अगर आप चाहते हैं कि नियम लागू हो, तो "हल करते समय परिणाम अनिवार्य करें" चालू करें।
3. कंसोल में, टिकट हल करने से पहले दाईं ओर के समापन बॉक्स में परिणाम चुनें।

तीन व्यवहार जानने लायक हैं, क्योंकि वे जानबूझकर ऐसे हैं:

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

क्विक टेक्स्ट: टाइप किए गए शॉर्टकट के पीछे तैयार वाक्य

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

1. कंपोज़र में :: लिखें और उसके बाद शॉर्टकट की शुरुआत, जैसे ::hi।
2. सूची छोटी करने के लिए लिखते रहें, या पूरी लाइब्रेरी देखने के लिए सिर्फ़ :: लिखें।
3. सूची में से कोई वाक्य चुनें, या शॉर्टकट पूरा लिखकर पुष्टि करें, तब पूरी तरह मेल खाने वाला वाक्य जुड़ जाएगा।
4. भेजने से पहले पाठ पढ़ें: दोहरे कोष्ठकों वाले चर, जैसे {{protocol}}, {{ticket_subject}}, {{requester_name}}, {{agent_name}} और {{org_name}}, उत्तर भेजते समय भरे जाते हैं, ठीक मैक्रो की तरह।

लाइब्रेरी तीन तरह की हैं: **निजी** (सिर्फ़ आप देखते हैं), **टीम की** (उस टीम के लोग) और **कंपनी की** (हर वह व्यक्ति जो जवाब देता है)। एक ही शॉर्टकट एक से ज़्यादा में हो सकता है, और आपके सबसे नज़दीक वाला जीतता है: आपका निजी वाक्य टीम वाले से आगे, और टीम वाला कंपनी वाले से आगे। यानी आप अपना ::hi रख सकते हैं, बिना किसी से कंपनी का मानक बदलवाए।

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

आपके निजी वाक्य आपके हैं: बनाइए, बदलिए और मिटाइए, किसी से पूछे बिना। टीम और कंपनी के वाक्य घर का मानक हैं, क्योंकि वे तय करते हैं कि कल सब लोग ग्राहक को क्या भेजेंगे, इसलिए वे सेटिंग्स संभालने वालों के हैं। किसी दूसरे का निजी वाक्य कोई नहीं बदल सकता, प्रशासक भी नहीं।

टिकट के ईमेल: घटना, भाषा, श्रेणी और कतार के हिसाब से अपना पाठ

टिकट के पाँच मौकों पर आपका अपना पाठ जा सकता है: **खुला**, **अपडेट हुआ**, **हल हुआ**, **सर्वे** और **समापन**। हर टेम्पलेट एक भाषा में लिखा जाता है और, चाहें तो, किसी श्रेणी तक, किसी कतार तक, या दोनों तक सीमित किया जा सकता है।

चुनाव एक घोषित क्रम से होता है, और उसे दो हिस्सों में पढ़ना सबसे आसान है: सिस्टम पहले तय करता है कि **क्या कहना है** और उसके बाद ही कि **किस भाषा में कहना है**। समूह सबसे विशिष्ट से सबसे सामान्य की ओर देखे जाते हैं: कतार और श्रेणी, फिर कतार, फिर श्रेणी, फिर सामान्य वाला। कतार का वज़न श्रेणी से ज़्यादा है, क्योंकि कतार वह टीम है जो जवाब देती है और पाठ उसी की आवाज़ है; श्रेणी तो सिर्फ़ विषय है।

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

जो भाषा गिनी जाती है वह **टिकट खोलने वाले** की है, यानी उस व्यक्ति की जो ईमेल पढ़ता है, एजेंट की नहीं। विषय और मुख्य पाठ में वही वेरिएबल चलते हैं जो मैक्रो और क्विक टेक्स्ट में चलते हैं, और पूर्वावलोकन कुछ भी भेजे जाने से पहले दिखा देता है कि कौन सा टेम्पलेट जीता और किस भाषा में।

स्वार्म: कठिन केस पर लोगों को बुलाना, और जो निकला उसे दर्ज करना

स्वार्म सत्र वह तरीका दर्ज करता है जो अब तक आंतरिक नोट्स में बिखरा रहता था: किसे बुलाया, किस भूमिका में, किस सवाल का जवाब पाने के लिए, कब तक, और अंत में क्या तय हुआ। **यह सत्र दर्ज करता है; यह न Slack चैनल खोलता है और न वीडियो कॉल शुरू करता है।** बातचीत वहीं होती रहती है जहाँ पहले से होती है (आंतरिक नोट, मेंशन, फ़ॉलोअर, आंतरिक चैट); नया सिर्फ़ उसकी याद बनती है।

1. टिकट पर स्वार्म खोलें और कारण लिखें। समय सीमा वैकल्पिक है, और वह बीते समय की नहीं हो सकती।
2. जो सत्र खोलता है वही **रिपोर्टर** होता है, और टिकट को फ़ॉलो करने लगता है।
3. ज़रूरी लोगों को **विशेषज्ञ** (कोई सीमा नहीं) या **लेखक** (एक ही जगह) के रूप में बुलाएँ। जिसे बुलाया जाता है उसे कारण सहित सूचना मिलती है और वह टिकट फ़ॉलो करने लगता है।
4. सत्र को **निष्कर्ष** के साथ बंद करें। वह आंतरिक नोट बनकर टिकट पर लौट आता है, ताकि केस उठाने वाला अगला व्यक्ति उसे कहीं और खोले बिना पढ़ सके।

• **एक टिकट पर एक ही खुला सत्र।** दो होने पर ध्यान दो हिस्सों में बँट जाता, और निष्कर्ष का कोई एक ठिकाना नहीं रहता।
• **रिपोर्टर और लेखक की जगह भरी रहने तक एक-एक ही है**; विशेषज्ञ की कोई सीमा नहीं, क्योंकि लोगों को बुलाना ही स्वार्म का मकसद है।
• **रिपोर्टर सत्र से बाहर नहीं जाता।** बाहर निकलने का रास्ता यही है कि जो तय हुआ वह लिखकर सत्र बंद किया जाए, भले ही वह 'कुछ तय नहीं हुआ' हो।
• **बंद करने के लिए निष्कर्ष अनिवार्य है**, और उससे सबकी भागीदारी भी खत्म हो जाती है, ताकि लोगों के मिनट अपने आप बढ़ते न रहें।
• **जो निकल गया, वह भी रिकॉर्ड में दिखता रहता है।** कौन शामिल था, यह कल भी सच रहना चाहिए।

तय किया गया फ़ॉलो अप और निजी अनुस्मारक

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

1. टिकट पर फ़ॉलो अप तय करें या मुझे याद दिलाएँ चुनें।
2. कब, यह अपने शब्दों में लिखें: कल 9 बजे, 2 घंटे में, शुक्रवार, अगले सप्ताह, या 2026-09-10 14:30 जैसी तारीख। उत्पाद की दसों भाषाएँ समझी जाती हैं।
3. फ़ॉलो अप में प्रकार चुनें (कार्य, कॉल, ईमेल या मीटिंग) और चाहें तो वह व्यक्ति भी जो उसे संभालेगा। अनुस्मारक हमेशा कार्य होता है, और हमेशा आपका।

• **समय के बिना लिखा गया दिन 09:00 बजता है**, संगठन के समय क्षेत्र में, वही डिफ़ॉल्ट जो उत्पाद के बाकी हिस्सों में चलता है।
• **अवधि लिखने पर मौजूदा समय बना रहता है**, क्योंकि अवधि अपने भीतर समय पहले से रखती है। मिनट और घंटे असली समय में गिने जाते हैं; दिन और सप्ताह कैलेंडर पर चलते हैं, इसलिए डेलाइट सेविंग उन्हें हिला नहीं पाती।
• **बीत चुका समय अगले दिन पर चला जाता है**, जैसा हर अनुस्मारक ऐप करता है। लेकिन बीता हुआ दिन अनुमान लगाने के बजाय अस्वीकार किया जाता है: आपका मतलब कौन सा दिन था, यह अंदाज़ा लगाना गढ़ना होगा।
• **365 दिन से आगे अस्वीकार है।** यह गलत उँगली का छन्ना है, 2026 में टाइप किया गया वह 2027 जिसे कोई कभी देखता ही नहीं।

जब भी आपके लिए 09:00 मान लिया गया हो या समय अगले दिन पर खिसका दिया गया हो, स्क्रीन आपके लिखे शब्द नहीं, बल्कि सचमुच **सहेजा गया** समय दोहराती है। 'यह कब देय है' के दो अलग जवाब होना ठीक वही भ्रम है, जिसे रोकने के लिए यह दोहराव मौजूद है।

कार्य टैब: एक साथ कई केस खुले

कंसोल एक बार में एक ही केस खोलता था, और दूसरा चुनते ही पहला हट जाता था। ज़्यादा मात्रा में काम करने वाले तीन-चार केस साथ चलाते हैं (एक ग्राहक की प्रतीक्षा में, एक इंजीनियरिंग की प्रतीक्षा में, एक जो लिखा जा रहा है), और हर बदलाव पर ड्राफ़्ट और स्क्रॉल की जगह खो जाती थी। कार्य टैब की पट्टी बातचीत के ऊपर रहती है, और जैसे ही दूसरी चीज़ खुलती है, दिख जाती है।

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

**सहेजे हुए बंद करें** उन सभी टैब को बंद करता है जिनमें ड्राफ़्ट नहीं है, और ड्राफ़्ट वालों को रहने देता है: सफ़ाई कभी लिखा हुआ काम साथ नहीं ले जाती। टैब आपके अपने ब्राउज़र में, इसी डिवाइस पर रहते हैं, इसलिए वे आपके हैं, टीम के नहीं।

ग्राहक का संदर्भ: सेहत, मूल्य, प्लान और सेवा का इतिहास

किसी केस का संदर्भ टैब एक ब्लॉक से खुलता है, जो आपके एक भी पंक्ति लिखने से पहले बता देता है कि यह ग्राहक ठीक चल रहा है या नहीं, उसकी कीमत कितनी है, वह किस प्लान पर है और उसके साथ कितनी बार बुरा बर्ताव हो चुका है। इसमें कुछ भी किसी ने टाइप नहीं किया: सब कुछ उसी जानकारी से बनता है जो उत्पाद उस खाते के बारे में पहले से रखता है।

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

ब्लॉक के नीचे, इस संपर्क के साथ की पूरी बातचीत एक ही लड़ी में दिखती है, चैनल कोई भी हो: चैट, SMS, WhatsApp, ईमेल और केस, सब साथ में, क्रम से। यह वही इतिहास है जो संपर्क की फ़ाइल दिखाती है, कंसोल के भीतर ले आया गया, ताकि पहले क्या कहा जा चुका है यह याद करने भर के लिए किसी को स्क्रीन न बदलनी पड़े।

पर्यवेक्षण: वही कामकाज, उसे सँभालने वाले की नज़र से

कंसोल जवाब देने वाले व्यक्ति के लिए "अब मैं क्या करूँ?" का उत्तर देता है। पर्यवेक्षण एक दूसरा सवाल हल करता है, और वह भी दूसरे व्यक्ति के लिए: इस वक़्त कामकाज सँभल रहा है या नहीं। यह अलग स्क्रीन है, दीवार पर खुली छोड़ने के लिए बनी, और यह अपने आप ताज़ा होती रहती है।

• **कामकाज सँभल रहा है?** हर कतार में खुले आइटम, कितने बिना मालिक के हैं, कितने हमारा इंतज़ार कर रहे हैं, और अगले एक घंटे में कितनों की समय-सीमा टूटने वाली है। क्या टूटने वाला है यह जानना और क्या टूट चुका है यह जानना एक बात नहीं है, और पैनल दोनों को अलग रखता है।
• **कौन बोझ में दबा है और कौन खाली है?** हर व्यक्ति के खुले आइटम, उसी व्यक्ति की सीमा के सामने; कौन रोटेशन से बाहर है और कतार का प्रमुख कौन है।
• **अड़चन कहाँ है?** सबसे लंबे इंतज़ार वाली कतार, सबसे ज़्यादा आवक लाने वाला चैनल, और वह कतार जिसमें से कोई कुछ उठा ही नहीं सकता, क्योंकि वह ऐसा कौशल माँगती है जो टीम में किसी के पास नहीं है।
• **पिछले एक घंटे में क्या हुआ?** असाइनमेंट का रिकॉर्ड पहले से ही append-only है, इसलिए पैनल बस उसे दिखा देता है।

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

सेवा कैटलॉग: कोरे केस की जगह एक दुकान की खिड़की

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

1. सेटिंग्स → सेवा कैटलॉग में, व्यवस्थापक कैटलॉग बनाता है: श्रेणियाँ, मदें, और हर मद जो सवाल पूछती है।
2. कोई भी व्यक्ति वही स्क्रीन खोलता है, एक सेवा चुनता है और उसका फ़ॉर्म भरता है।
3. सिस्टम उस मद की कतार में एक केस खोलता है, उसी प्राथमिकता के साथ और जवाब उसके भीतर, ठीक उसी प्रारूप में जो पोर्टल पहले से इस्तेमाल करता है।
4. अगर आइटम को अनुमोदन चाहिए, तो टिकट तुरंत खुलता है और लंबित अनुमोदन उसके समाधान को रोक देता है: जब तक कोई निर्णय न ले, कोई उसे बंद नहीं कर सकता।

• **किसी मद को निष्क्रिय करने से जो पहले माँगा जा चुका है वह रद्द नहीं होता।** इसका मतलब है "अब यह मत माँगिए", कभी नहीं "जो चल रहा है उसे रद्द कर दीजिए": पहले से खुले केस उसी कतार और उसी समय-सीमा के साथ खुले रहते हैं।
• **जो मद एक बार माँगी जा चुकी है उसे हटाया नहीं जा सकता, सिर्फ़ निष्क्रिय किया जा सकता है।** हटाने से इतिहास इस बारे में झूठ बोलने लगेगा कि माँगा क्या गया था।
• **अनुरोध फ़ॉर्म का एक चित्र जमा देता है।** बाद में सवाल बदल दीजिए, तब भी पुराना अनुरोध वही सवाल दिखाता रहेगा जिनका उस व्यक्ति ने सचमुच जवाब दिया था।
• **अनुरोध की स्थिति कोई नक़ल नहीं है।** वह हर बार अनुमोदन से ही पढ़ी जाती है, इसलिए वह कभी उससे अलग नहीं हो सकती जो अनुमोदन इंजन ने कहीं और तय किया है।

सेवा कैटलॉग: अनुरोध को पूरा करना

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

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

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

ग्राहक के उपकरण: यह केस इसी उपकरण के बारे में है

अब टिकट ग्राहक के **उपकरण** की ओर इशारा कर सकता है, यानी सीरियल नंबर वाली लगी हुई इकाई की ओर, न कि सिर्फ़ बेचे गए उत्पाद मॉडल की ओर। टिकट में आप उसे ग्राहक के लगे हुए उपकरणों में से चुनते हैं, सीरियल नंबर से खोजकर, क्योंकि फ़ोन पर ग्राहक उसी से उसकी पहचान बताता है। सिर्फ़ उसी ग्राहक का उपकरण जोड़ा जा सकता है जिसका यह टिकट है, और उसके बाद सेवा की कहानी उपकरण का अपना इतिहास सुनाता है: जुड़े, हटाए गए और हल हुए केस उसी समयरेखा पर आते हैं जिस पर स्थापना, जगह बदलना और रखरखाव हैं।

बंद रहने का समय **लोग** दर्ज करते हैं, या वह टिकट से ही दर्ज होता है। यहाँ न टेलीमेट्री है और न मशीन का कोई संकेत, इसलिए उपलब्धता, MTTR और MTBF की कीमत उतनी ही है जितनी दर्ज करने वालों के अनुशासन की। स्क्रीन आँकड़े को सजाने के बजाय यह बात ऊँची आवाज़ में कहती है।

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

नॉलेज बेस: मालिकाना, समीक्षा और उपयोग

नॉलेज बेस को वह परत मिली है जो बताती है कि हर लेख का जवाबदेह कौन है और क्या उस पर अब भी भरोसा किया जा सकता है: एक मालिक, एक समीक्षक, दिनों में समीक्षा का चक्र, और इन्हीं से निकलता हुआ वह लेख जिसकी **समीक्षा की तारीख निकल चुकी** है। शासन का बोर्ड जीवंत है, वह खोलते ही गिना जाता है, इसलिए वह कभी इस पर निर्भर नहीं करता कि रात की प्रक्रिया चली या नहीं। जवाबदेही सिर्फ़ प्रकाशित लेख की है: मसौदा अभी लिखा जा रहा है और आर्काइव किया हुआ चलन से बाहर है।

दृश्यता अब सिर्फ़ इतनी नहीं रही कि प्रकाशित है या नहीं। हर लेख का अब एक पाठक-वर्ग है: **बाहरी** वह है जो हेल्प सेंटर और पोर्टल लिंक रखने वाले किसी को भी दिखाते हैं, और **आंतरिक** CRM से कभी बाहर नहीं जाता। हर लेख बाहरी के रूप में जन्म लेता है, ठीक वैसे ही जैसे वह पहले बरतता था, इसलिए जब तक आप कुछ और तय न करें, कुछ नहीं बदलता।

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

सेल्फ़-सर्विस: सहायक और डिफ्लेक्शन दर

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

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

• लेख पढ़ना नहीं गिना जाता। पढ़ने वाला शायद तुलना कर रहा हो, शोध कर रहा हो, या टिकट खोलने के रास्ते में ही ग़लत लेख पढ़ रहा हो और टिकट फिर भी खोल दे।
• बिना नतीजे की खोज नहीं गिनी जाती। टैब बंद कर देना सफलता नहीं है।
• टिकट घोषणा पर भारी पड़ता है: अगर व्यक्ति ने कहा कि हल हो गया और उसी विज़िट में केस खोल भी दिया, तो वह विज़िट टिकट के रूप में गिनी जाती है। हम कम नापना पसंद करते हैं।
• जिस विज़िट ने कुछ तय ही नहीं किया, वह दर से पूरी तरह बाहर रहती है, न ऊपर और न नीचे, और उसे अलग से अनिर्णीत बताया जाता है।
• दर उन विज़िट का हिस्सा है जिन्होंने **कुछ तय किया** और तय किया कि टिकट नहीं खोलेंगे। उस अवधि में एक भी निर्णय न हो तो दर खाली रहती है, कभी 0% नहीं, क्योंकि न जानना और शून्य प्रतिशत अलग-अलग जवाब हैं।
• फ़नल (खोजें, सवाल, जवाब पाए सवाल) पहुँच नापता है, नतीजा नहीं, और उसमें से कुछ भी दर में नहीं जाता।

सेवा विश्लेषण: तैयार रिपोर्ट, निष्कर्ष और अनुमान

टिकट कंसोल का विश्लेषण टैब वह बताता है जो अब तक किसी स्क्रीन ने नहीं बताया: कतार कब से पड़ी है, वादा किए गए हर पड़ाव में से कितना निभा, कितना ऊपर चढ़ा, आवाज़, बॉट और मैसेजिंग क्या करते रहे, इंसिडेंट ने टिकटों में कितना ख़र्च कराया, मात्रा किस ओर जा रही है, और आख़िर में, इस सबका करना क्या है। हर आँकड़ा सर्वर से पहले ही गिना हुआ आता है, इसलिए दो स्क्रीन एक ही हिसाब पर चुपचाप अलग-अलग बात नहीं कह सकतीं।

दो पाठ जो एक जैसे लगते हैं और हैं नहीं: **उम्र घड़ी पर चलती है** (टिकट बनने के बाद का कैलेंडर समय) और **समय-सीमा कार्य समय पर चलती है** (SLA का वादा, रोक घटाकर)। इनके नाम जानबूझकर अलग हैं। इन्हें मिला देने पर एक ही लेबल वाले दो आँकड़े मिलते और यह जानने का कोई रास्ता न बचता कि टूटा कौन सा है।

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

नीति के तहत टिकट पर काम करने वाली AI

AI हर टिकट पहले से पढ़ रही थी (श्रेणी, तात्कालिकता, भावना, सारांश) और कोई उसका इस्तेमाल नहीं करता था। अब वह टिकट में श्रेणी और प्राथमिकता **लिख** सकती है, लेकिन सिर्फ़ उस नीति के तहत जो वर्कस्पेस तय करता है, और यह **डिफ़ॉल्ट रूप से बंद** है: जब तक प्रशासक इसे **सेटिंग्स → सर्विस AI** में चालू नहीं करता, कुछ नहीं बदलता। फ़ील्ड दर फ़ील्ड आप **कुछ न करें**, **सुझाव दें (कोई व्यक्ति पुष्टि करे)** और **भरोसा होने पर लिखें** में से चुनते हैं। लिखना सिर्फ़ आपकी तय की गई भरोसे की न्यूनतम सीमा से ऊपर होता है (50% से 100%, डिफ़ॉल्ट 80%); उससे नीचे वही प्रस्ताव एक सुझाव बन जाता है, जो एक क्लिक में लागू हो जाता है।

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

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

टिकट से फ़ील्ड का काम

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

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

• **विज़िट तय करें** कंसोल से उसी जॉब में एक विज़िट जोड़ता है: दोबारा जाना विज़िट 2, 3 और आगे है, कभी दूसरा जॉब नहीं। एक टिकट में ज़्यादा से ज़्यादा एक जॉब होता है, और खोलें पर दूसरा क्लिक जवाब देता है कि वह पहले से मौजूद है।
• जॉब की अपनी आगमन विंडो और तकनीशियन सिर्फ़ तभी भरे जाते हैं जब वे खाली थे: दूसरी विज़िट पहली के लिए तय हुई बात को दोबारा नहीं लिखती।
• **विज़िट देर से** तब दिखता है जब विंडो शुरू हो चुकी है और विज़िट अभी सिर्फ़ तय है, यानी कोई निकला नहीं। स्थिति बदलने वाला चयनकर्ता सिर्फ़ वही बदलाव देता है जो वर्टिकल की स्टेट मशीन मौजूदा स्थिति से स्वीकार करती है।
• जब फ़ील्ड का काम **पूरा हुआ**, **पूरा नहीं हो सका** या **रद्द** हुआ, तो टिकट का मालिक उसकी भाषा में कंसोल के लिंक के साथ सूचित किया जाता है, चाहे बदलाव कंसोल से आया हो, वर्टिकल की स्क्रीन से या ऐप से। भेजा गया, रास्ते में और पुर्ज़े की प्रतीक्षा में बॉक्स में दिखते रहते हैं, बिना किसी की घंटी बजाए।
• फ़ील्ड का काम ख़त्म होने पर **टिकट की स्थिति कभी अपने आप नहीं बदलती**। ग्राहक से पुष्टि करना और टिकट हल करना उसी का फ़ैसला है जो उसे संभाल रहा है।
• **लिंक हटाएँ** टिकट और जॉब के बीच का जोड़ हटाता है और कुछ नहीं: जॉब वर्टिकल में अपने इतिहास के साथ जीता रहता है। उसे रद्द करना वर्टिकल का एक बदलाव है, जो वहीं किया जाता है।
• विज़िट की तारीख़ पर याद दिलाने वाला कार्य वैकल्पिक है और गतिविधियों के मॉड्यूल को दोबारा इस्तेमाल करता है; यह टिकट की समयरेखा में और तकनीशियन की कार्य सूची में दिखता है, या तकनीशियन न होने पर टिकट के मालिक की सूची में।
• वर्टिकल बंद होने पर बॉक्स यही कहता है और **सेटिंग्स · Verticals** की ओर इशारा करता है, बजाय ऐसा बटन दिखाने के जो नाकाम हो जाता। यह वह हल्का रास्ता देता है जो हर वर्कस्पेस के पास है, **इसके बजाय सर्विस ऑर्डर खोलें**, और ऑर्डर मौजूद होने पर वह ऑर्डर और उसकी अपॉइंटमेंट दिखाता है।

कहाँ सेट करें: तैयार वाक्यों के लिए **सेटिंग्स → क्विक टेक्स्ट**, ट्रांज़ैक्शनल टेक्स्ट के लिए **सेटिंग्स → टिकट ईमेल टेम्पलेट**, और कौन क्या जानता है तथा हर क्यू की ज़रूरत के लिए **सेटिंग्स → कौशल**। स्वार्म, फ़ॉलो-अप और वर्क टैब को किसी सेटअप की ज़रूरत नहीं: वे पहले से कंसोल में हैं।

इस लेख को सिस्टम के भीतर खोलें →