सपोर्ट टिकट रिपोर्ट कैसे बनाएं: चरण-दर-चरण

सपोर्ट टिकट रिपोर्ट मुख्य रूप से परिभाषाओं से जुड़ी एक समस्या है। टिकटों का बनना (Tickets created), टिकटों का हल होना (tickets solved), पहला उत्तर समय (first reply time), और समाधान समय (resolution time) सुनने में बहुत स्पष्ट लगते हैं। लेकिन एक ही हेल्प डेस्क के भीतर इनमें से हर एक के एक से अधिक आधिकारिक अर्थ होते हैं।

गणना के नियमों को स्पष्ट कर लें, तो रिपोर्ट अपने आप बन जाती है। इस कदम को छोड़ दें, तो दो ईमानदार लोग एक ही एक्सपोर्ट निकालेंगे और उनके नतीजों में घंटों का अंतर आ जाएगा।

यह गाइड बताती है कि रिपोर्ट में क्या शामिल होना चाहिए, वे चार जगहें जहाँ परिभाषाएँ अलग हो जाती हैं, और टिकट एक्सपोर्ट से इसे कैसे तैयार किया जाए।

सपोर्ट टिकट रिपोर्ट में क्या शामिल होना चाहिए

केवल वॉल्यूम (संख्या) से लगभग कुछ पता नहीं चलता। इन आंकड़ों को सही ढंग से समझने के लिए उनका व्यवस्थित होना ज़रूरी है।

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

दो पंक्तियाँ अपने आकार से कहीं अधिक महत्व रखती हैं। फिर से खोले गए (Reopened) और अनुत्तरित (unreplied) टिकट ही वे बिंदु हैं जहाँ एक रिपोर्ट केवल स्कोरबोर्ड न रहकर वास्तव में उपयोगी बन जाती है।

Zendesk इसके पीछे के सूत्रों को प्रकाशित करता है, जिससे परिभाषाओं को केवल राय मानने के बजाय जांचा जा सकता है। इसका मेट्रिक्स और एट्रिब्यूट्स संदर्भ हर एक की जानकारी देता है।

सबसे सरल से शुरू करते हैं। हल किए गए टिकट (Solved tickets) का अर्थ है "हल किए गए या बंद किए गए टिकटों की संख्या," इसलिए यह मीट्रिक केवल एक के बजाय दो स्टेटस को कवर करता है।

"First reply time" की दो आधिकारिक परिभाषाएँ हैं

यह वह विभाजन है जो सबसे अधिक असहमति का कारण बनता है, और वेंडर इसके बारे में सीधे चेतावनी देता है

Zendesk का SLA दस्तावेज़ इसे एक लाइन में कहता है: "SLA उत्तर समय को मूल Zendesk उत्तर समय मीट्रिक के साथ भ्रमित न करें।"

मूल मीट्रिक इस बात को लेकर सख्त है कि उत्तर कौन दे रहा है। Zendesk का कहना है कि "पहले उत्तर के समय की गणना विशेष रूप से एजेंट के उत्तरों के आधार पर की जाती है।" स्वचालित और बॉट से जुड़ी गतिविधियों को "पहले उत्तर के समय की गणना करते समय ध्यान में नहीं रखा जाता है।"

SLA मीट्रिक के साथ ऐसा नहीं है। वहाँ, पहला उत्तर समय "टिकट बनने और एजेंट की ओर से पहली सार्वजनिक टिप्पणी (या ऑटो-रिप्लाई) के बीच का समय" होता है। Zendesk आगे कहता है कि "यदि आप सार्वजनिक टिप्पणी के साथ ऑटो-रिप्लाई करने के लिए एक ट्रिगर सेट करते हैं, तो उत्तर समय मीट्रिक की शर्तें पूरी हो जाती हैं।"

इन दोनों को एक साथ पढ़ें तो परिणाम बिल्कुल स्पष्ट हो जाता है। एक ऑटो-रिस्पॉन्डर आपके SLA लक्ष्य को पूरा कर सकता है, जबकि मूल पहला उत्तर समय (first reply time) लगातार चलता रहता है।

इसलिए, 98% SLA प्राप्ति और चार घंटे का औसत (median) पहला उत्तर दिखाने वाली रिपोर्ट आपस में विरोधाभासी नहीं है। यह दो अलग-अलग चीज़ों की रिपोर्ट कर रही है, और दोनों ही सही हैं।

जानने योग्य दो छोटे अपवाद भी हैं। उस स्थिति को लें जहाँ एक एजेंट टिकट बनाता है और पहली टिप्पणी सार्वजनिक होती है। अवधि मीट्रिक संदर्भ कहता है कि दूसरा टाइमस्टैम्प "दूसरे सार्वजनिक एजेंट टिप्पणी पर स्थानांतरित हो जाता है।"

और साझा किए गए टिकटों की गणना नहीं की जाती है। Zendesk नोट करता है कि जब कोई एजेंट टिकट शेयरिंग का उपयोग करके किसी अन्य खाते से सार्वजनिक रूप से टिप्पणी करता है, तो "यह आपके खाते के पहले उत्तर समय में नहीं गिना जाता है।"

"Resolution time" की भी दो परिभाषाएँ हैं

यही विभाजन समाधान मीट्रिक में भी देखने को मिलता है, और यहाँ दोनों संस्करण डिफ़ॉल्ट रूप से मिलते हैं।

पहला समाधान समय (First resolution time) "टिकट बनने और उसके पहले समाधान के बीच की अवधि" है, जो "टिकट का स्टेटस पहली बार हल (solved) होने पर" समाप्त होता है।

पूर्ण समाधान समय (Full resolution time) "टिकट बनने और उसके सबसे हालिया समाधान के बीच की अवधि" है। यह "आखिरी बार जब टिकट का स्टेटस हल (solved) सेट किया गया था" पर समाप्त होता है।

एक बार हल किए गए टिकट के लिए, ये दोनों समान होते हैं। लेकिन एक टिकट जो हल हुआ, फिर से खुला, और फिर से हल हुआ, उसके लिए दोनों में उतना ही अंतर आ जाएगा जितना समय दूसरे दौर में लगा था।

यही कारण है कि फिर से खोले गए (reopened) टिकटों को रिपोर्ट में शामिल किया जाना चाहिए। Zendesk इन्हें "हल होने के बाद फिर से खोले गए" टिकटों के रूप में परिभाषित करता है, और नोट करता है कि इस मीट्रिक में "एक ही अपडेट के दौरान हल किए गए और फिर से खोले गए टिकट शामिल नहीं हैं।"

एक दूसरा प्रभाव भी है जिस पर लोग ध्यान नहीं देते। हल किए गए टिकटों का दैनिक औसत उन्हें "केवल तभी गिनता है जब वे वर्तमान में हल या बंद हों।" इसलिए आज फिर से खोला गया टिकट चुपचाप पिछले महीने के हल किए गए टिकटों की संख्या से बाहर हो जाता है।

इसलिए जून में निकाली गई रिपोर्ट अगस्त में वैसी नहीं दिखेगी। कुछ भी खराब नहीं हुआ है; बस उसके पीछे का स्टेटस बदल गया है।

दो और मीट्रिक प्रतीक्षा (waiting) और काम करने (working) के समय को अलग करते हैं। अनुरोधकर्ता प्रतीक्षा समय (Requester wait time) नए (new), खुले (open), और होल्ड (on-hold) स्टेटस में बिताया गया कुल समय है, और एजेंट प्रतीक्षा समय (agent wait time) पेंडिंग (pending) स्टेटस में बिताया गया कुल समय है।

यह जोड़ी उस सवाल का जवाब देती है जो समाधान का औसत नहीं दे पाता। ग्राहक की प्रतीक्षा के कारण होने वाला लंबा समाधान समय, कतार (queue) की लंबाई के कारण होने वाले लंबे समाधान समय से बिल्कुल अलग समस्या है।

कैलेंडर घंटे या व्यावसायिक घंटे

प्रत्येक उत्तर और समाधान का आंकड़ा दो अलग-अलग समय-चक्रों (clocks) पर आधारित होता है, और इनमें से किसी एक को चुनना वैकल्पिक नहीं है।

Zendesk दोनों को स्टोर करता है। पहले सार्वजनिक उत्तर के बाद, "सिस्टम कैलेंडर घंटों और व्यावसायिक घंटों में पहले उत्तर के समय की गणना करता है।" दोनों मीट्रिक "टिकट डेटा के साथ स्टोर किए जाते हैं।"

जो डिफ़ॉल्ट आप देखते हैं वह निष्पक्ष नहीं है। Zendesk नोट करता है कि पहले से बनी Explore रिपोर्ट "पहले से बनी रिपोर्टों में जानकारी को कैलेंडर घंटों में प्रदर्शित करती हैं।" व्यावसायिक घंटों के मीट्रिक "उपलब्ध हैं और इनका उपयोग आपकी अपनी रिपोर्टों में किया जा सकता है।"

सो सुबह नौ से शाम पांच बजे तक काम करने वाली टीम डिफ़ॉल्ट रिपोर्ट में धीमी दिखाई देगी। शुक्रवार शाम 6 बजे आने वाले टिकट में सोमवार सुबह तक लगभग 63 कैलेंडर घंटे जुड़ जाते हैं, जबकि व्यावसायिक घंटे लगभग शून्य होते हैं।

लाइव बातचीत के चैनल इसमें एक और पेंच जोड़ देते हैं। मैसेजिंग और चैट के लिए पहला उत्तर समय (सेकंड) मीट्रिक "आपके मैसेजिंग व्यावसायिक घंटों और लाइव चैट के संचालन घंटों की सेटिंग्स को अनदेखा करता है।"

और चैट उत्तर-समय SLA वैकल्पिक (opt-in) हैं। Zendesk का कहना है कि लाइव चैट के लिए उत्तर समय SLA "डिफ़ॉल्ट रूप से बंद होते हैं," इसलिए उनका न होना एक कॉन्फ़िगरेशन स्थिति है, न कि कोई बेहतरीन प्रदर्शन।

इसे मैन्युअल रूप से कैसे करें

विकल्प 1: प्रत्येक मीट्रिक श्रेणी के लिए एक टैब

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

एक्सपोर्ट करते समय किसी एक को चुनने के बजाय कैलेंडर और व्यावसायिक घंटों के कॉलम को अगल-बगल रखें। आपसे दूसरे के बारे में भी पूछा जाएगा।

समय मीट्रिक के लिए औसत (mean) के बजाय माध्यिका (median) की गणना करें। छुट्टी के दौरान खुले छोड़े गए कुछ टिकट औसत को ऐसे स्तर पर ले जाएंगे जहाँ वास्तव में कोई टिकट नहीं होता।

इसकी सीमा यह है कि स्प्रेडशीट स्टेटस का इतिहास नहीं देख सकती। आपको प्रत्येक टिकट की वर्तमान स्थिति मिलती है, इसलिए फिर से खोले जाने (reopen) के व्यवहार को पुनर्निर्माण के बजाय फिर से खोले गए टिकटों की संख्या से ही समझना होगा।

विकल्प 2: एक परिभाषा टैब, जिसे पहले लिखा गया हो

उत्तर समय की परिभाषा, समय-चक्र (clock), समाधान मीट्रिक, हल किए गए टिकटों के लिए स्टेटस नियम, दायरे में आने वाले चैनल और तारीख के आधार को रिकॉर्ड करें।

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

इसकी सीमा हमेशा की तरह ही है। किसी नियम का दस्तावेजीकरण करने से वह लागू नहीं हो जाता, और अगली तिमाही में कोई व्यक्ति अपनी याददाश्त के आधार पर पिवट (pivot) को फिर से बना लेता है।

विकल्प 3: औसत निकालने से पहले विभाजित (Segment) करें

किसी भी समय मीट्रिक की गणना करने से पहले चैनल के आधार पर विभाजित करें। ईमेल, चैट और फोन टिकटों की प्रकृति अलग होती है, और एक मिश्रित माध्यिका (blended median) उनमें से किसी का भी सही वर्णन नहीं करती है।

फिर उन टिकटों को बाहर करें या चिह्नित करें जो आंकड़ों को बिगाड़ते हैं। हफ्तों से ग्राहक के जवाब का इंतजार कर रहे टिकटों को समाधान के औसत में रखने के बजाय उनकी अपनी अलग लाइन में होना चाहिए।

दिखाएं कि आपने किसे बाहर किया और उनकी संख्या कितनी थी। जो पाठक फ़िल्टर को नहीं देख सकता, वह मान लेगा कि कोई फ़िल्टर था ही नहीं।

सीमा यह है कि विभाजन से काम कई गुना बढ़ जाता है। तीन चैनल गुणा दो समय-चक्र गुणा दो समाधान मीट्रिक का मतलब है बारह अलग-अलग आंकड़ों को याद रखना।

साझा सीमा। ये तीनों मानकर चलते हैं कि एक्सपोर्ट हर कतार (queue) के लिए एक ही तारीख के आधार पर एक ही तारीख की सीमा को कवर करता है। अलग-अलग टैब में मिश्रित तारीख सीमाएं इस रिपोर्ट में होने वाली सबसे आम छिपी हुई गलती है।

जहाँ मैन्युअल तरीका धीमा पड़ जाता है

पहली सपोर्ट टिकट रिपोर्ट बनाने में एक दोपहर का समय लगता है। चौथी रिपोर्ट में अधिक समय लगता है, क्योंकि इस बीच हेल्प डेस्क का ढांचा बदल चुका होता है।

एक नया चैनल शुरू हो जाता है, जिससे मिश्रित माध्यिका (blended median) उन कारणों से बदल जाती है जिनका प्रदर्शन से कोई लेना-देना नहीं होता। किसी नए क्षेत्र के लिए व्यावसायिक घंटों में बदलाव किया जाता है, और उसके साथ ही व्यावसायिक घंटों के सभी ऐतिहासिक आंकड़े भी बदल जाते हैं।

फिर रीओपन (reopen) का प्रभाव सामने आता है। पिछली तिमाही के आंकड़े अब मेल नहीं खाते, और इसका कारण समझाना रिपोर्ट को फिर से बनाने से अधिक समय लेता है।

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

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

Powerdrill Bloom के साथ इसे कैसे बनाएं

चरण 1: अपना टिकट एक्सपोर्ट अपलोड करें

टिकट एक्सपोर्ट, या टिकट और SLA एक्सपोर्ट दोनों को एक साथ अपलोड करें। Powerdrill Bloom अपलोड होते ही कॉलम का विश्लेषण करता है, जिससे खाली टाइमस्टैम्प, मिश्रित तारीख प्रारूप और बिना किसी पहले उत्तर वाले टिकट किसी भी माध्यिका (median) की गणना होने से पहले ही सामने आ जाते हैं।

चरण 2: प्राकृतिक भाषा (natural language) में रिपोर्ट का वर्णन करें

परिभाषाओं को फिर से बनाने के बजाय उन्हें स्पष्ट रूप से बताएं। उत्तर समय की परिभाषा, समय-चक्र (clock), आप कौन सा समाधान मीट्रिक चाहते हैं, हल किए गए टिकटों के लिए स्टेटस नियम और दायरे में आने वाले चैनलों के नाम बताएं।

फिर वे सवाल पूछें जो गलतियों को पकड़ते हैं। पूछें कि कितने टिकटों पर एजेंट का कोई उत्तर नहीं आया है। पूछें कि कौन से टिकट फिर से खोले गए थे। एक मिश्रित आंकड़े के बजाय प्रति चैनल माध्यिका (median) की मांग करें।

चरण 3: चार्ट, रिपोर्ट या डेक एक्सपोर्ट करें

प्रति चैनल मीट्रिक तालिका, या बैकलॉग के साथ बनाए गए बनाम हल किए गए टिकटों का चार्ट निकालें। वे स्लाइड्स जिनमें आंकड़ों के बगल में परिभाषाएं होती हैं, इसी प्रक्रिया से तैयार हो जाती हैं।

आम गलतियाँ

SLA प्राप्ति को पहले उत्तर समय (first reply time) के रूप में बताना। एक ऑटो-रिप्लाई को स्वीकार करता है और दूसरा स्वचालित गतिविधियों को पूरी तरह से बाहर रखता है।

कैलेंडर घंटों की तुलना व्यावसायिक घंटों से करना। डिफ़ॉल्ट रिपोर्ट आपको पहला विकल्प देती है, जबकि आपका लक्ष्य शायद दूसरे पर सेट था।

उत्तर और समाधान समय के लिए औसत (mean) का उपयोग करना। कुछ छोड़े गए टिकट औसत को ऐसे स्तर पर ले जाते हैं जहाँ कोई वास्तविक टिकट नहीं होता।

चैनलों को आपस में मिलाना। चैट और ईमेल की माध्यिकाएं (medians) स्वाभाविक रूप से अलग होती हैं, और उन्हें मिलाने से दोनों छिप जाती हैं।

यह बताए बिना समाधान समय की रिपोर्ट करना कि वह कौन सा है। पहला और पूर्ण समाधान समय अलग-अलग संग्रहीत (stored) मीट्रिक हैं, न कि केवल राउंडिंग के अंतर।

हल किए गए टिकटों की संख्या को अंतिम मानना। हल की गई संख्या में केवल वही टिकट शामिल होते हैं जो वर्तमान में हल या बंद हैं, इसलिए फिर से खोले जाने पर अतीत के आंकड़े बदल जाते हैं।

अनुत्तरित टिकटों को बाहर छोड़ना। इन्हें ऐसे टिकटों के रूप में परिभाषित किया जाता है जिन पर एजेंट का एक भी उत्तर नहीं आया है, और ये सबसे स्पष्ट विफलता हैं जिसे रिपोर्ट सामने ला सकती है।

निष्कर्ष

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

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

इसके बजाय नियमों के एक निश्चित सेट पर इसे अपने इतिहास के खिलाफ ट्रैक करें। यही वह संस्करण है जो आपको बताता है कि क्या वास्तव में कुछ सुधार हुआ है।

यदि हर महीने इसे फिर से बनाने में आपका एक दिन बर्बाद होता है, तो अपने टिकट एक्सपोर्ट पर Powerdrill Bloom आज़माएं। AI रिपोर्ट जनरेटर पेज और वॉइस ऑफ कस्टमर समराइज़र भी देखें।

अक्सर पूछे जाने वाले प्रश्न

मेरी SLA प्राप्ति मेरे पहले उत्तर समय (first reply time) से मेल क्यों नहीं खाती?

वे अलग-अलग घटनाओं को मापते हैं। Zendesk का SLA पहला उत्तर समय एक ऑटो-रिप्लाई द्वारा पूरा किया जा सकता है, जबकि मूल पहला उत्तर समय मीट्रिक स्वचालित और बॉट गतिविधियों को पूरी तरह से बाहर रखता है।

क्या मुझे पहले समाधान समय (first resolution time) की रिपोर्ट करनी चाहिए या पूर्ण समाधान समय (full resolution time) की?

आप जिसका भी नाम लें, उसकी रिपोर्ट करें। पहला समाधान समय तब समाप्त होता है जब टिकट को पहली बार हल (solved) सेट किया जाता है। पूर्ण समाधान समय आखिरी बार हल होने पर समाप्त होता है, इसलिए फिर से खोले गए टिकट इन दोनों को अलग करते हैं।

क्या सपोर्ट मीट्रिक की गणना कैलेंडर घंटों में की जाती है या व्यावसायिक घंटों में?

दोनों को स्टोर किया जाता है। Zendesk की पहले से बनी Explore रिपोर्ट कैलेंडर घंटे प्रदर्शित करती हैं, और व्यावसायिक घंटों के मीट्रिक आपके द्वारा खुद बनाई जाने वाली रिपोर्टों के लिए उपलब्ध हैं।

पिछली तिमाही के हल किए गए टिकटों की संख्या क्यों बदल गई?

हल की गई संख्या में वे टिकट शामिल होते हैं जो वर्तमान में हल या बंद हैं। अवधि समाप्त होने के बाद फिर से खोला गया टिकट उस अवधि की संख्या से बाहर हो जाता है।

क्या मैं अपने समाधान समय की तुलना किसी उद्योग बेंचमार्क से कर सकता हूँ?

केवल मोटे तौर पर। परिभाषाएँ, समय-चक्र (clock) और चैनलों का मिश्रण सभी कॉन्फ़िगर करने योग्य हैं, इसलिए प्रकाशित आंकड़ा शायद आपके नियमों से अलग नियमों पर मापा गया था।