मदत केंद्र & तिकीट प्रणाली
एजंटच्या आधीच उघड्या तिकिटावर रेकॉर्डिंग अंतर्गत टीप म्हणून येते — कुणी न मागितलेले नवीन प्रकरण नाही.
1. आधी सोडवावा लागलेला प्रश्न
कोणते तिकीट?
प्रत्येक ओळखलेल्या सत्राचे तिकीट म्हणजे स्पॅम: कुणी न उघडलेली प्रकरणे दिसतील. त्या व्यक्तीच्या प्रत्येक जुन्या तिकिटावर टीप जोडणेही स्पॅम, फक्त हळू.
म्हणून: पाठवणाऱ्याच्या अलीकडील उघड्या तिकिटावर अंतर्गत टीप. उघडे तिकीट नसेल तर काहीच नाही. ग्राहकाने न सुरू केलेले प्रकरण बनवत नाही; एजंट पाहत असतो तिथेच रेकॉर्डिंग मिळते.
अंतर्गत, कधीच सार्वजनिक नाही. दुवा MousePlayer मध्ये जातो. ग्राहकाने पाहू नये; उघडताही येणार नाही.
2. Zendesk Support आणि Freshdesk
दोन्ही समर्थित; तेच काम वेगळ्या प्रकारे. लक्ष देण्याची गरज नाही, पण फॉर्म वेगळी माहिती का विचारतो ते स्पष्ट होते.
| Zendesk Support | Freshdesk | |
|---|---|---|
| उपडोमेन | acme acme.zendesk.com मधून | acme acme.freshdesk.com मधून |
| एजंट ईमेल | आवश्यक — Zendesk पुढीलने साइन इन करते: email/token | लागत नाही, रिकामे ठेवा |
| API टोकन | अॅडमिन केंद्र → अॅप आणि एकत्रीकरणे → API | तुमची प्रोफाइल सेटिंग्ज |
| टीप बनते | तिकिटावरील अंतर्गत टिप्पणी | तिकिटावरील खाजगी टीप |
सोपे वाटल्यास उपडोमेन फील्डमध्ये पूर्ण URL पेस्ट करा; आवश्यक भाग घेतो, म्हणून https://acme.zendesk.com/agent/tickets/1 याचे रूपांतर acme.
3. केव्हा चालते
सत्र ओळखताच — साइटचा पुढील कॉल: MousePlayer.setUserId(), विश्लेषण ब्रिजचा वेगळा ID किंवा सर्व्हर identify एंडपॉइंट कॉल.
फक्त ईमेलसह
तिकीट पाठवणाऱ्याचे; मदत केंद्र ईमेलने ओळखते. करार क्रमांक उपयोगी नाही, म्हणून पाठवत नाही.
फक्त उघड्या तिकिटांसाठी
सोडवलेली आणि बंद तिकिटे वगळतो. कोणी न पाहणाऱ्या प्रकरणावरील टीप उपयोगी नाही; विनाकारण पुन्हा एजंटसमोर येईल.
उघडे तिकीट नसेल तर पूर्ण मानतो, अयशस्वी नाही — सामान्य स्थिती; पुनर्प्रयत्नाने फरक नाही.
4. एजंटला काय दिसते
एक अंतर्गत टीप: MousePlayer: <email> चे सत्र रेकॉर्डिंग आणि दुवा. एका क्लिकवर व्यक्तीने काय केले ते त्याच्या वर्णनाशेजारी दिसते.
कुठे उपयोगी
- “चालत नाही” तिकिटे. ईमेलच्या तीन फेऱ्यांत न समजणारे रेकॉर्डिंग वीस सेकंदांत दाखवते.
- कुणालाही पुन्हा न घडवता येणाऱ्या पायऱ्या. आता गरज नाही — सत्र तुमच्याकडे आहे.
- संतप्त आणि निष्फळ क्लिक — ग्राहक सांगत नाही, कारण उत्पादन असेच चालते असे मानतो.
टोकन सर्व्हर सोडत नाही
AES-256-GCM एन्क्रिप्टेड; जतन केल्यावर पुन्हा दिसत नाही; कामाच्या अंतर्गत रांगेत मुद्दाम नाही.
5. Help Scout, Front आणि Gorgias
आणखी तीन मदत केंद्रे. तिन्ही उघड्या संवादावर अंतर्गत टीप, पण वेगळ्या मार्गांनी.
| तुम्ही देता | उपडोमेन | |
|---|---|---|
| Help Scout | अंतर्गत अॅपचा क्लायंट ID आणि सीक्रेट | लागत नाही |
| Front | API टोकन आणि सहकारी ID | लागत नाही |
| Gorgias | एजंट ईमेल आणि API की | आवश्यक |
Help Scout आधी टोकन बदलते
थेट क्लायंट सीक्रेट स्वीकारत नाही. ब्रिज आधी अल्पकालीन अॅक्सेस टोकन मिळवतो — वापरकर्त्यासाठी नव्हे, स्वतः कार्य करणाऱ्या जोडणीचा client credentials प्रवाह. मुदतीपर्यंत टोकन मेमरीत; सीक्रेट डेटाबेसमध्ये.
Front टिप्पणीला लेखक हवा
टिप्पणी सहकाऱ्याच्या नावाने; API ला ID हवा. एजंट लेबलच्या फील्डमध्ये लॉगिन नव्हे, टीप ज्याच्या नावाने येते तो ID.
Gorgias ला एका ऐवजी दोन प्रश्न
तिकीट यादी फक्त पुढीलने फिल्टर होते: customer_id — ईमेल फिल्टर नाही. म्हणून आधी ग्राहक शोधून मग तिकिटे मागवतो. स्थिती फिल्टरही नाही; Freshdesk प्रमाणे उघडे तिकीट आमच्याकडे निवडतो.
सर्व ट्रेडमार्क संबंधित मालकांचे आहेत. MousePlayer चे या प्रदात्यांशी व्यावसायिक संबंध नाहीत.