हेल्पडेस्क टिकटिंग सिस्टम कैसे बनाएँ: टिकट, स्थितियाँ, असाइनमेंट और ईमेल
हेल्पडेस्क टिकटिंग सिस्टम बिखरे हुए अनुरोधों — ईमेल, संदेश, गलियारे में पूछे गए “छोटे सवाल” — को टिकटों में बदल देता है: हर समस्या का एक रिकॉर्ड, उसका मालिक, एक स्थिति, एक प्राथमिकता और पूरी बातचीत। इसे बनाने के लिए आपको टिकट बनाने का तरीका, फ़िल्टर वाली एक साझा कतार, असाइनमेंट, एक ऐसा थ्रेड जो सार्वजनिक जवाबों को आंतरिक नोट्स से अलग रखे, और सूचनाएँ चाहिए ताकि कोई इंतज़ार में न छूटे। AI ऐप बिल्डर एक आंतरिक IT, HR या facilities डेस्क के लिए एक ठोस पहला संस्करण एक दोपहर में बना सकता है। ईमेल थ्रेडिंग, प्रतिक्रिया लक्ष्यों और रिपोर्टिंग वाली ग्राहक-सहायता में ज़्यादा सावधानी चाहिए — और यही वह जगह है जहाँ स्थापित हेल्पडेस्क प्रोडक्ट अपनी फ़ीस वसूलते हैं।
सिस्टम को क्या चाहिए
डेटा
| तालिका | मुख्य फ़ील्ड |
|---|---|
| Tickets | नंबर, विषय, अनुरोधकर्ता, श्रेणी, प्राथमिकता, स्थिति, असाइनी, टीम, बनाया गया, पहली प्रतिक्रिया, हल हुआ |
| Messages | टिकट, लेखक, मुख्य पाठ, सार्वजनिक जवाब या आंतरिक नोट, अटैचमेंट, भेजा गया |
| Requesters | नाम, ईमेल, संगठन या विभाग |
| Agents | नाम, ईमेल, टीम, भूमिका (agent, lead, admin) |
| Categories | नाम, डिफ़ॉल्ट टीम, डिफ़ॉल्ट प्राथमिकता |
| Canned replies | शीर्षक, मुख्य पाठ, श्रेणी |
| Activity log | टिकट, किसने, क्या बदला, कब |
पहली प्रतिक्रिया और समाधान के टाइमस्टैम्प शुरू से सेव करें। हर रिपोर्ट इन्हीं पर बनती है, और इन्हें बाद में दोबारा नहीं बनाया जा सकता।
पेज
- अनुरोधकर्ता: श्रेणी और अटैचमेंट वाला “अनुरोध भेजें” फ़ॉर्म, “मेरे अनुरोध” की सूची, और हर टिकट का थ्रेड।
- एजेंट: कतार (मेरे टिकट, असाइन न हुए, सभी खुले), फ़िल्टर और खोज, और जवाब, नोट, स्थिति, प्राथमिकता व असाइनी नियंत्रण वाला टिकट दृश्य।
- एडमिन: श्रेणियाँ, टीमें, एजेंट, तैयार जवाब, और एक सरल रिपोर्ट।
अनुमतियाँ
अनुरोधकर्ता सिर्फ़ अपने टिकट और सिर्फ़ सार्वजनिक जवाब देखते हैं। एजेंट अपनी टीम के टिकट और आंतरिक नोट देखते हैं। लीड और एडमिन सब देखते हैं और सेटिंग संभालते हैं। आंतरिक नोट का ग्राहक तक पहुँच जाना हेल्पडेस्क की क्लासिक आपदा है, इसलिए इसे सिर्फ़ टैब छिपाकर नहीं, सर्वर पर लागू करें। देखें रोल-आधारित एक्सेस कंट्रोल।
फ़ैसले और समझौते
फ़ॉर्म, ईमेल, या दोनों
वेब फ़ॉर्म सबसे सरल है और आपको साफ़ डेटा देता है: श्रेणी, प्राथमिकता और ज़रूरी फ़ील्ड। ईमेल इनटेक — लोग support@ पर लिखते हैं और एक टिकट बन जाता है — वह है जिसकी ग्राहक उम्मीद करते हैं, लेकिन इसके लिए ऐसा ईमेल प्रदाता चाहिए जो संदेश प्राप्त करके आपके ऐप को भेज सके, साथ में थ्रेडिंग ताकि जवाब सही टिकट से जुड़ें (आम तौर पर विषय में टिकट नंबर या एक अनूठा reply-to पता)। फ़ॉर्म से शुरू करें; वर्कफ़्लो साबित होने पर ईमेल जोड़ें। बाहर जाने वाले हिस्से के लिए अपने ऐप से ईमेल भेजना देखें।
असाइनमेंट
विकल्प: एजेंट असाइन न हुई कतार से चुनें; टीम के भीतर round-robin; या श्रेणी के अनुसार असाइनमेंट। छोटी टीमों के लिए कतार से चुनना काम करता है। जब टिकट बिना मालिक के पड़े रहने लगें, तो स्वचालित असाइनमेंट मदद करता है।
प्राथमिकताएँ और प्रतिक्रिया लक्ष्य
दो या तीन प्राथमिकताएँ तय करें, हर एक के लिए पहली प्रतिक्रिया का लक्ष्य रखकर (“अति-आवश्यक: 1 घंटा, सामान्य: 1 कार्य-दिवस”)। हर टिकट पर बचा समय दिखाना उस मासिक रिपोर्ट से ज़्यादा काम का है जिसे कोई पढ़ता नहीं। कार्य-घंटे गणित को मुश्किल बनाते हैं — जल्दी तय करें कि लक्ष्य रातों और सप्ताहांत को गिनते हैं या नहीं।
मर्ज करना और डुप्लिकेट
एक ही समस्या तीन बार रिपोर्ट होना आम है। “टिकट # में मर्ज करें” क्रिया एजेंटों को एक ही बात बार-बार लिखने से बचाती है; इसे जल्दी बनाना फ़ायदेमंद है।
एक ऐसा पहला प्रॉम्प्ट जो काम करता है
60 लोगों की एक कंपनी के लिए एक आंतरिक IT हेल्पडेस्क बनाओ। कर्मचारी एक फ़ॉर्म से अनुरोध भेजते हैं: विषय, श्रेणी (hardware, software, access, network, other), प्राथमिकता (low, normal, urgent), विवरण और अटैचमेंट। हर टिकट को एक नंबर मिले और स्थितियाँ हों: new, open, waiting on requester, resolved, closed। IT एजेंट एक कतार देखें जिसमें असाइन न हुए, मेरे, और सभी खुले के टैब हों, श्रेणी, प्राथमिकता और स्थिति के फ़िल्टर, और खोज। टिकट पेज पर सार्वजनिक जवाब और आंतरिक नोट साफ़ अलग दिखें; कर्मचारी कभी आंतरिक नोट न देखें। एजेंट असाइन कर सकें, स्थिति और प्राथमिकता बदल सकें, तैयार जवाब इस्तेमाल कर सकें, और डुप्लिकेट मर्ज कर सकें। पहली प्रतिक्रिया और समाधान के समय ट्रैक करो, और हर टिकट पर आख़िरी अपडेट के बाद बीता समय दिखाओ। कर्मचारियों के लिए “मेरे अनुरोध” पेज हो। भूमिकाएँ: employee, agent, admin। सब कुछ एक database में रखो। सादा, घना और तेज़ इंटरफ़ेस — सजावट से ज़्यादा गति।
बनाने के चरण
- टिकट मॉडल और फ़ॉर्म। भेजना, सूची, टिकट खोलना, जवाब देना।
- कतार और फ़िल्टर। असाइन न हुए, मेरे, सभी खुले; फ़िल्टर और खोज; प्राथमिकता और उम्र से क्रम।
- भूमिकाएँ और लॉगिन। अनुरोधकर्ता, एजेंट, एडमिन — सर्वर पर अनुरोधकर्ताओं से नोट छिपे हों।
- असाइनमेंट, स्थिति और प्राथमिकता नियंत्रण, हर बदलाव के एक activity log के साथ।
- सूचनाएँ। सार्वजनिक जवाबों पर अनुरोधकर्ता को और नए असाइनमेंट पर एजेंट को ईमेल, आपके अपने ईमेल प्रदाता से।
- तैयार जवाब और मर्ज।
- प्रतिक्रिया लक्ष्य और एक बुनियादी रिपोर्ट: उम्र के हिसाब से खुले टिकट, पहली प्रतिक्रिया का समय, श्रेणी के अनुसार टिकट।
- ईमेल इनटेक, बाकी काम होने के बाद, थ्रेडिंग की पूरी जाँच के साथ।
- एक टीम के साथ दो हफ़्ते का पायलट सभी को स्थानांतरित करने से पहले।
आम गलतियाँ
- आंतरिक नोट अनुरोधकर्ताओं को दिखना, क्योंकि वे सिर्फ़ इंटरफ़ेस में छिपाए गए थे।
- बहुत ज़्यादा स्थितियाँ और श्रेणियाँ। एजेंट वह पहली चुन लेते हैं जो नज़दीक लगे। हर एक में ज़्यादा से ज़्यादा पाँच से शुरू करें।
- पहली प्रतिक्रिया और समाधान के लिए टाइमस्टैम्प न होना। जिस दिन कोई पूछे “क्या हम तेज़ हो रहे हैं?”, आपको ये संख्याएँ चाहिए होंगी।
- ईमेल जवाब थ्रेड होने के बजाय नए टिकट बनाना। फ़ोन के मेल ऐप से जवाब देकर परखें, क्योंकि वे अक्सर विषय बदल देते हैं।
- सब असाइन, कोई ज़िम्मेदार नहीं। हर टिकट का एक असाइनी हो; बाकी सबके लिए watchers।
- सार्वजनिक URL वाले अटैचमेंट। त्रुटि संदेशों के स्क्रीनशॉट में अक्सर निजी डेटा होता है। फ़ाइलें निजी रखें और सिर्फ़ उन्हीं को दें जो टिकट देख सकते हैं।
कब बना-बनाया प्रोडक्ट बेहतर विकल्प है
ईमेल, चैट और सोशल चैनलों पर ग्राहक-सहायता के लिए — प्रतिक्रिया-लक्ष्य ट्रैकिंग, संतुष्टि सर्वे, मैक्रो, रिपोर्टिंग और इंटीग्रेशन के साथ — समर्पित हेल्पडेस्क प्रोडक्ट लगभग हमेशा बेहतर निवेश है। उन प्रोडक्ट्स ने ईमेल थ्रेडिंग, स्पैम, रूटिंग और रिपोर्टिंग पर वर्षों लगाए हैं, और वह हिस्सा आपके व्यवसाय को अलग नहीं बनाता। हमारी Zendesk विकल्प गाइड विकल्पों की तुलना करती है।
कस्टम बिल्ड आंतरिक डेस्क (IT, HR, facilities, वित्त अनुरोध), उन खास वर्कफ़्लो के लिए फ़िट बैठता है जहाँ टिकट असल में ऐसा काम है जिसके तय चरण हैं, और उन टीमों के लिए जो अनुरोधों को उस दूसरे डेटा से जोड़ना चाहती हैं जो वे पहले से रखती हैं। जब कई लोग कभी-कभार टिकट संभालते हैं, तो प्रति-एजेंट कीमत से भी बचाता है। आंतरिक टूल गाइड इस श्रेणी को व्यापक रूप से कवर करती है।
Mythex के साथ बनाना
Mythex पर आप चैट में हेल्पडेस्क का वर्णन करते हैं, लाइव प्रीव्यू में उसकी समीक्षा करते हैं, और अपनी टीम के लिए उसे प्रकाशित करते हैं। टिकट एक Postgres database में रहते हैं, जिसे एजेंट तब जोड़ता है जब डेटा सेव करना हो, और अटैचमेंट प्रोजेक्ट की file storage में जाते हैं। अनुरोधकर्ताओं और एजेंटों के लॉगिन, और अंदर-बाहर का सारा ईमेल, आपके अपने प्रदाताओं से आते हैं — Mythex में अंतिम-उपयोगकर्ता लॉगिन या ईमेल प्रोडक्ट बिल्ट-इन नहीं है; ईमेल भेजने की रेसिपी तरीका दिखाती है। टीम के साथी एक साझा वर्कस्पेस के ज़रिए मदद कर सकते हैं, और Mythex के अपने प्लान पर प्रति-सीट शुल्क नहीं है।
शुरुआती प्रॉम्प्ट के लिए आंतरिक अनुरोध कतार या बग ट्रैकर टेम्पलेट आज़माएँ, और हेल्पडेस्क को एक नॉलेज बेस के साथ जोड़ें, ताकि आम सवालों के जवाब अपने-आप मिल जाएँ।
सवाल
टिकटिंग सिस्टम की मुख्य विशेषताएँ क्या हैं?
टिकट बनाने का तरीका (फ़ॉर्म या ईमेल), स्थिति और प्राथमिकता वाली एक साझा कतार, एजेंट को असाइनमेंट, सार्वजनिक जवाब और निजी नोट वाला संवाद थ्रेड, और खोज। बाकी सब — प्रतिक्रिया लक्ष्य, तैयार जवाब, रिपोर्ट — इन्हीं पर बनता है।
क्या कस्टम हेल्पडेस्क ईमेल से टिकट ले सकता है?
हाँ, लेकिन इसके लिए ऐसा ईमेल प्रदाता चाहिए जो मेल प्राप्त कर सके और हर संदेश को वेबहुक के ज़रिए आपके ऐप तक भेजे। जवाबों में टिकट संदर्भ होना चाहिए, ताकि वे नए टिकट बनाने के बजाय सही टिकट से जुड़ें।
आंतरिक IT या HR हेल्पडेस्क बनाया जाए या खरीदा जाए?
आंतरिक अनुरोध डेस्क कस्टम बिल्ड के लिए अच्छे हैं: मात्रा का अंदाज़ा रहता है, श्रेणियाँ आपकी कंपनी की खास होती हैं, और आप तय करते हैं कि कौन क्या देखे। बड़े पैमाने पर ग्राहक-सहायता के लिए आम तौर पर समर्पित प्रोडक्ट ही जायज़ है।
टिकट की कौन सी स्थितियाँ होनी चाहिए?
छोटी रखें: new, open, waiting on customer, resolved और closed ज़्यादातर टीमों के लिए काफ़ी है। “on hold” तभी जोड़ें जब आपको अक्सर किसी तीसरे पक्ष का इंतज़ार करना पड़ता है। हर अतिरिक्त स्थिति एक और चीज़ है जिसे एजेंट गलत सेट करेंगे।