हेल्पडेस्क तिकीट प्रणाली कशी बनवायची: तिकिटे, स्थिती, नेमणूक आणि ईमेल
हेल्पडेस्क तिकीट प्रणाली विखुरलेल्या विनंत्या — ईमेल, मेसेज, कॉरिडॉरमधील "छोटे प्रश्न" — तिकिटांमध्ये बदलते: प्रत्येक समस्येसाठी एक नोंद, मालक, स्थिती, प्राधान्य आणि संपूर्ण संभाषण. ती बनवण्यासाठी तुम्हाला तिकीट तयार करण्याचा मार्ग, फिल्टरसह सामायिक रांग, नेमणूक, सार्वजनिक उत्तरे आणि अंतर्गत नोंदी वेगळ्या करणारा धागा, आणि कोणीही वाट पाहत राहू नये म्हणून सूचना लागतात. अंतर्गत IT, HR किंवा सुविधा डेस्कसाठी AI ॲप बिल्डर एका दुपारी भक्कम पहिली आवृत्ती बनवू शकतो. ईमेल थ्रेडिंग, प्रतिसाद लक्ष्ये आणि अहवालांसह ग्राहक-सपोर्ट अधिक काळजी घेण्याचा आहे — आणि तिथेच प्रस्थापित हेल्पडेस्क उत्पादने त्यांचे शुल्क कमावतात.
प्रणालीला काय लागते
डेटा
| टेबल | मुख्य फील्ड |
|---|---|
| Tickets | क्रमांक, विषय, विनंती करणारा, श्रेणी, प्राधान्य, स्थिती, नेमलेला, टीम, तयार केल्याची वेळ, पहिला प्रतिसाद, निराकरणाची वेळ |
| Messages | तिकीट, लेखक, मजकूर, सार्वजनिक उत्तर किंवा अंतर्गत नोंद, जोडणी, पाठवल्याची वेळ |
| Requesters | नाव, ईमेल, संस्था किंवा विभाग |
| Agents | नाव, ईमेल, टीम, भूमिका (एजंट, लीड, ॲडमिन) |
| Categories | नाव, डीफॉल्ट टीम, डीफॉल्ट प्राधान्य |
| Canned replies | शीर्षक, मजकूर, श्रेणी |
| Activity log | तिकीट, कोणी, काय बदलले, केव्हा |
पहिला प्रतिसाद आणि निराकरणाचे टाइमस्टॅम्प सुरुवातीपासून साठवा. प्रत्येक अहवाल त्यावर आधारित असतो, आणि ते नंतर पुन्हा तयार करता येत नाहीत.
पाने
- विनंती करणारा: श्रेणी आणि जोडण्यांसह "विनंती सबमिट करा" फॉर्म, "माझ्या विनंत्या" यादी, आणि प्रत्येक तिकिटाचा धागा.
- एजंट: रांग (माझी तिकिटे, नेमलेली नसलेली, सर्व उघडी), फिल्टर आणि शोध, आणि उत्तर, नोंद, स्थिती, प्राधान्य व नेमणूक नियंत्रणांसह तिकीट दृश्य.
- ॲडमिन: श्रेण्या, टीम, एजंट, तयार उत्तरे, आणि एक साधा अहवाल.
परवानग्या
विनंती करणाऱ्यांना फक्त स्वतःची तिकिटे आणि फक्त सार्वजनिक उत्तरे दिसतात. एजंटना त्यांच्या टीमची तिकिटे आणि अंतर्गत नोंदी दिसतात. लीड आणि ॲडमिन सर्व पाहतात आणि सेटिंग्ज व्यवस्थापित करतात. अंतर्गत नोंदी ग्राहकापर्यंत पोहोचणे ही क्लासिक हेल्पडेस्क आपत्ती आहे, त्यामुळे ते फक्त टॅब लपवून नव्हे, तर सर्व्हरवर लागू करा. भूमिका-आधारित प्रवेश नियंत्रण पहा.
निर्णय आणि तडजोडी
फॉर्म, ईमेल किंवा दोन्ही
वेब फॉर्म सर्वात सोपा आहे आणि स्वच्छ डेटा देतो: श्रेणी, प्राधान्य आणि आवश्यक फील्ड. ईमेल इनटेक — लोक support@ ला लिहितात आणि तिकीट दिसते — हे ग्राहकांना अपेक्षित असते, पण त्यासाठी मेल स्वीकारून तुमच्या ॲपकडे पोस्ट करू शकणारा ईमेल प्रदाता, तसेच उत्तरे योग्य तिकिटाशी जोडण्यासाठी थ्रेडिंग (सहसा विषयात तिकीट क्रमांक किंवा अनोखा reply-to पत्ता) लागतो. फॉर्मने सुरुवात करा; कार्यप्रवाह सिद्ध झाल्यावर ईमेल जोडा. बाहेर जाणाऱ्या ईमेलसाठी तुमच्या ॲपमधून ईमेल कसा पाठवायचा पहा.
नेमणूक
पर्याय: एजंट नेमलेल्या नसलेल्या रांगेतून निवडतात; टीममध्ये राउंड-रॉबिन; किंवा श्रेणीनुसार नेमणूक. लहान टीमसाठी रांगेतून निवड चालते. तिकिटे मालकाशिवाय पडून राहू लागली की स्वयंचलित नेमणूक मदत करते.
प्राधान्ये आणि प्रतिसाद लक्ष्ये
पहिल्या प्रतिसादासाठी लक्ष्यासह दोन-तीन प्राधान्ये ठरवा ("तातडीचे: 1 तास, सामान्य: 1 व्यावसायिक दिवस"). प्रत्येक तिकिटावर उरलेला वेळ दाखवणे, कोणीही न वाचणाऱ्या मासिक अहवालापेक्षा अधिक उपयुक्त आहे. व्यावसायिक तास गणित कठीण करतात — लक्ष्ये रात्री आणि शनिवार-रविवार मोजली जातात का ते लवकर ठरवा.
विलीनीकरण आणि डुप्लिकेट
तीन वेळा नोंदवलेली एकच समस्या सामान्य आहे. "या तिकिटात विलीन करा #" ही क्रिया एजंटांना एकच उत्तर वारंवार देण्यापासून वाचवते; ती लवकर बनवण्यासारखी आहे.
एक काम करणारा पहिला प्रॉम्प्ट
60 लोकांच्या कंपनीसाठी एक अंतर्गत IT हेल्पडेस्क बनवा. कर्मचारी फॉर्मद्वारे विनंत्या सबमिट करतात: विषय, श्रेणी (hardware, software, access, network, other), प्राधान्य (low, normal, urgent), वर्णन आणि जोडणी. प्रत्येक तिकिटाला क्रमांक मिळतो आणि स्थिती new, open, waiting on requester, resolved, closed. IT एजंट रांग पाहतात, ज्यात टॅब आहेत: नेमलेली नसलेली, माझी आणि सर्व उघडी; श्रेणी, प्राधान्य आणि स्थितीनुसार फिल्टर, आणि शोध. तिकीट पान धागा दाखवते, ज्यात सार्वजनिक उत्तरे आणि अंतर्गत नोंदी स्पष्टपणे वेगळ्या आहेत; कर्मचाऱ्यांना अंतर्गत नोंदी कधीही दिसत नाहीत. एजंट नेमणूक, स्थिती आणि प्राधान्य बदलू शकतात, तयार उत्तरे वापरू शकतात, आणि डुप्लिकेट विलीन करू शकतात. पहिला-प्रतिसाद आणि निराकरण वेळा ट्रॅक करा आणि प्रत्येक तिकिटावर शेवटच्या अद्ययावतीपासूनचा वेळ दाखवा. कर्मचाऱ्यांसाठी "माझ्या विनंत्या" पान. भूमिका: employee, agent, admin. सर्व काही डेटाबेसमध्ये साठवा. साधा, दाट, जलद इंटरफेस — सजावटीपेक्षा वेग.
बिल्ड स्टेप्स
- तिकीट मॉडेल आणि फॉर्म. सबमिट करा, यादी पहा, तिकीट उघडा, उत्तर द्या.
- रांग आणि फिल्टर. नेमलेली नसलेली, माझी, सर्व उघडी; फिल्टर आणि शोध; प्राधान्य आणि वयानुसार क्रम.
- भूमिका आणि लॉगिन. विनंती करणारा, एजंट, ॲडमिन — विनंती करणाऱ्यांपासून नोंदी सर्व्हरवर लपवलेल्या.
- नेमणूक, स्थिती आणि प्राधान्य नियंत्रणे, प्रत्येक बदलाच्या ॲक्टिव्हिटी लॉगसह.
- सूचना. सार्वजनिक उत्तरांवर विनंती करणाऱ्याला आणि नवीन नेमणुकीवर एजंटला, तुमच्या स्वतःच्या ईमेल प्रदात्यामार्फत ईमेल.
- तयार उत्तरे आणि विलीनीकरण.
- प्रतिसाद लक्ष्ये आणि मूलभूत अहवाल: वयानुसार उघडी तिकिटे, पहिला प्रतिसाद वेळ, श्रेणीनुसार तिकिटे.
- ईमेल इनटेक, बाकी सर्व काम झाल्यावर, थ्रेडिंगची काटेकोर चाचणी करून.
- एका टीमसह पायलट दोन आठवडे, मग सर्वांना हलवण्यापूर्वी.
सामान्य चुका
- अंतर्गत नोंदी विनंती करणाऱ्यांना दिसणे, कारण त्या फक्त इंटरफेसमध्ये लपवलेल्या होत्या.
- खूप स्थिती आणि श्रेण्या. एजंट जवळची वाटणारी पहिली निवडतात. प्रत्येकी जास्तीत जास्त पाच ठेवा.
- पहिला प्रतिसाद आणि निराकरणासाठी टाइमस्टॅम्प नसणे. "आपण जलद होत आहोत का?" असे कोणी विचारेल त्या दिवशी तुम्हाला आकडे हवे असतील.
- ईमेल उत्तरांनी थ्रेड न करता नवीन तिकिटे बनवणे. फोनच्या मेल ॲपमधून उत्तर देऊन चाचणी करा, कारण ते अनेकदा विषय बदलते.
- सर्वांना नेमणूक, पण कोणीच जबाबदार नाही. प्रत्येक तिकिटाला एक नेमलेला; इतरांसाठी watchers वापरा.
- सार्वजनिक URL असलेल्या जोडण्या. एररच्या स्क्रीनशॉटमध्ये अनेकदा खाजगी डेटा असतो. फाइल्स खाजगी ठेवा आणि फक्त तिकीट पाहू शकणाऱ्यांना द्या.
तयार उत्पादन कधी चांगला पर्याय ठरते
ईमेल, चॅट आणि सोशल चॅनेलवरील ग्राहक-सपोर्टसाठी — प्रतिसाद-लक्ष्य ट्रॅकिंग, समाधान सर्वेक्षण, मॅक्रो, अहवाल आणि इंटिग्रेशनसह — समर्पित हेल्पडेस्क उत्पादन जवळजवळ नेहमीच चांगली गुंतवणूक असते. त्या उत्पादनांनी ईमेल थ्रेडिंग, स्पॅम, राउटिंग आणि अहवालांवर वर्षे घालवली आहेत, आणि तुमच्या व्यवसायाला वेगळे बनवणारा तो भाग नाहीत. आमचे Zendesk पर्याय मार्गदर्शक पर्यायांची तुलना करते.
कस्टम बिल्ड अंतर्गत डेस्क (IT, HR, सुविधा, वित्त विनंत्या), जिथे तिकीट म्हणजे विशिष्ट चरणांचे काम असते अशा विशेष कार्यप्रवाहांसाठी, आणि आधीच ठेवत असलेल्या इतर डेटाशी विनंत्या जोडू इच्छिणाऱ्या टीमसाठी योग्य आहे. जेव्हा अनेक लोक अधूनमधून तिकिटे हाताळतात, तेव्हा प्रति-एजंट किंमत टाळतेही. त्या श्रेणीबद्दल व्यापक माहितीसाठी अंतर्गत टूल मार्गदर्शक पहा.
Mythex सह बनवणे
Mythex वर तुम्ही चॅटमध्ये हेल्पडेस्कचे वर्णन करता, लाइव्ह प्रिव्ह्यूमध्ये पुनरावलोकन करता आणि तुमच्या टीमसाठी प्रकाशित करता. डेटा साठवण्याची गरज भासल्यावर एजंट जोडत असलेल्या Postgres डेटाबेसमध्ये तिकिटे राहतात, आणि जोडण्या प्रोजेक्टच्या फाइल स्टोरेज मध्ये जातात. विनंती करणाऱ्यांसाठी आणि एजंटांसाठी लॉगिन, आणि आत-बाहेरचे सर्व ईमेल, तुमच्या स्वतःच्या प्रदात्यांद्वारे होतात — Mythex कडे अंगभूत एंड-यूजर लॉगिन किंवा ईमेल उत्पादन नाही; ईमेल पाठवण्याची रेसिपी दृष्टिकोन दाखवते. सहकारी सामायिक वर्कस्पेसद्वारे मदत करू शकतात, आणि Mythex वर स्वतःच प्रति-सीट शुल्क नाही.
सुरुवातीच्या प्रॉम्प्टसाठी अंतर्गत विनंती रांग किंवा बग ट्रॅकर टेम्प्लेट्स वापरून पहा, आणि सामान्य प्रश्न स्वतः उत्तरित होण्यासाठी हेल्पडेस्कला नॉलेज बेस सोबत जोडा.
प्रश्न
तिकीट प्रणालीची मुख्य वैशिष्ट्ये कोणती?
तिकीट तयार करण्याचा मार्ग (फॉर्म किंवा ईमेल), स्थिती आणि प्राधान्यासह एक सामायिक रांग, एजंटला नेमणूक, सार्वजनिक उत्तरे आणि खाजगी नोंदी असलेला संभाषण धागा, आणि शोध. बाकी सर्व — प्रतिसाद लक्ष्ये, तयार उत्तरे, अहवाल — यावर आधारित आहे.
स्वतःचे हेल्पडेस्क ईमेलद्वारे तिकिटे घेऊ शकते का?
हो, पण त्यासाठी ईमेल प्रदाता हवा जो मेल स्वीकारू शकेल आणि प्रत्येक संदेश वेबहुक म्हणून तुमच्या ॲपकडे पाठवेल. उत्तरांमध्ये तिकीट संदर्भ असणे आवश्यक आहे, म्हणजे ती नवीन तिकिटे न बनवता योग्य तिकिटाशी जोडली जातील.
अंतर्गत IT किंवा HR हेल्पडेस्क बनवावे की विकत घ्यावे?
अंतर्गत विनंती डेस्क कस्टम बिल्डसाठी योग्य आहेत: त्यांची संख्या अंदाजे असते, श्रेण्या तुमच्या कंपनीसाठी खास असतात, आणि कोणाला काय दिसते ते तुम्ही नियंत्रित करता. मोठ्या प्रमाणावरील ग्राहक-सपोर्टसाठी सहसा समर्पित उत्पादनच योग्य ठरते.
तिकिटांना कोणत्या स्थिती असाव्यात?
छोटी ठेवा: नवीन, उघडे, ग्राहकाची वाट पाहत, निराकरण झाले आणि बंद. बहुतेक टीमसाठी हे पुरेसे आहे. तुम्ही वारंवार तिसऱ्या पक्षाची वाट पाहत असाल तरच 'होल्डवर' जोडा. प्रत्येक अतिरिक्त स्थिती म्हणजे एजंटांनी चुकीने सेट करण्याची आणखी एक संधी.