مدد ڊيسڪ & Ticketing
رڪارڊنگ انهيءَ ticket تي اندروني نوٽ طور اچي ٿي جيڪو توهان جي ايجنٽ اڳ ئي کوليو آهي — ڪنهن جي نه گهريل نئين ڪيس طور نه.
1. پهريون سوال جنهن جو هن خصوصيت کي جواب ڏيڻو هو
ڪهڙو ticket؟
هر سڃاتل سيشن لاءِ ticket ٺاهڻ اسپام هوندو: مدد ٽيم کي اڻکليل ڪيس ملن. انهيءَ شخص جي هر لکيل ticket تي نوٽ شامل ڪرڻ به اسپام هوندو، رڳو وڌيڪ سست.
تنهنڪري: موڪليندڙ جي سڀ کان تازي کليل ticket تي اندروني نوٽ. کليل ticket نه هجي ته ڪجهه به نٿو ٿئي. ائين ڪڏهن به اهڙو ڪيس نٿا ٺاهيون جيڪو گراهڪ شروع نه ڪيو، ۽ ايجنٽ رڪارڊنگ بلڪل انهيءَ هنڌ ڳولي ٿو جتي اڳ ئي ڏسي رهيو آهي.
اندروني، ڪڏهن به عوامي نه. لنڪ MousePlayer اندر وڃي ٿو. گراهڪ کي ڏسڻ نه گهرجي، ۽ ان تي هلي به نه سگهندو.
2. Zendesk Support ۽ Freshdesk
ٻئي موجود آهن، ۽ ساڳيو ڪم مختلف طريقي سان ڪن ٿا. توهان کي ان بابت فڪر جي ضرورت ناهي — پر اهو سمجهائي ٿو ته فارم ٿوريون مختلف شيون ڇو گهري ٿو.
| Zendesk Support | Freshdesk | |
|---|---|---|
| ذيلي ڊومين | acme acme.zendesk.com مان | acme acme.freshdesk.com مان |
| ايجنٽ جي اي ميل | ضروري — Zendesk هن طور لاگ ان ٿئي ٿو email/token | ضروري ناهي، خالي ڇڏيو |
| API token | ايڊمن مرڪز → ايپس ۽ ڳانڍاپا → API | توهان جون پروفائيل سيٽنگون |
| نوٽ بڻجي ٿو | Ticket تي اندروني تبصرو | Ticket تي ذاتي نوٽ |
سولو لڳي ته ذيلي ڊومين خاني ۾ پورو URL پيسٽ ڪريو — اسان گهربل حصو وٺون ٿا، تنهنڪري https://acme.zendesk.com/agent/tickets/1 بدلجي ٿو هن ۾ acme.
3. ڪڏهن هلي ٿو
سيشن سڃاڻجڻ وقت — جڏهن توهان جي سائيٽ هي سڏي MousePlayer.setUserId()، جڏهن اسان جو تجزياتي پل distinct ID واپس پڙهي، يا توهان جو سرور identify endpoint سڏي.
رڳو اي ميل پتي سان
Ticket موڪليندڙ جو هوندو آهي، ۽ مدد ڊيسڪ کيس اي ميل سان سڃاڻي ٿو. معاهدي جو نمبر اتي ڪجهه نٿو ڳولي، تنهنڪري ڪجهه نه موڪليو وڃي ٿو.
رڳو کليل ticket لاءِ
حل ٿيل ۽ بند ticket ڇڏجن ٿا. اهڙي ڪيس تي نوٽ جيڪو ڪو نٿو ڏسي، ڪنهن جي مدد نٿو ڪري، ۽ بنا سبب بند ticket ايجنٽن جي نظر ۾ وري آڻيندو.
موڪليندڙ جو کليل ticket نه هجي ته مڪمل ڳڻجي ٿو، ناڪام نه — اها عام حالت آهي، ۽ ٻيهر ڪوشش ڪجهه نه بدلائيندي.
4. ايجنٽ ڇا ڏسي ٿو
هڪ اندروني نوٽ: MousePlayer: <email> جي سيشن رڪارڊنگ پوءِ لنڪ. هڪ ڪلڪ سان ڏسن ٿا ته انهيءَ ماڻهو حقيقت ۾ ڇا ڪيو، سندس لکيل بيان جي بلڪل ڀرسان.
ڪٿي ڪارائتو ثابت ٿئي ٿو
- “ڪم نٿو ڪري” وارا ticket. رڪارڊنگ اڪثر ويهن سيڪنڊن ۾ اهو ڏيکاري ٿي جيڪو اي ميل جا ٽي دور به نه ڏيکارين.
- مسئلو ورجائڻ جا قدم جيڪي ڪو ورجائي نٿو سگهي. هاڻي انهن جي ضرورت ناهي — سيشن توهان وٽ آهي.
- ڪاوڙ وارا ۽ بي اثر ڪلڪ جن جو گراهڪ ذڪر نٿو ڪري، ڇاڪاڻ ته هو ان کي پراڊڪٽ جو عام ڪم سمجهي ٿو.
Token ڪڏهن اسان جو سرور نٿو ڇڏي
AES-256-GCM سان انڪرپٽ ٿي محفوظ، محفوظ ٿيڻ کان پوءِ وري نه ڏيکاريل، ۽ ڪم کڻندڙ اندروني قطار کان ڄاڻي واڻي ٻاهر رکيل.
5. Help Scout، Front ۽ Gorgias
ٽي وڌيڪ مدد ڊيسڪ. ٽئي کليل ڳالهه ٻولهه تي اندروني نوٽ ڏين ٿا، پر پهچڻ جو طريقو مختلف آهي.
| توهان ڏيو ٿا | ذيلي ڊومين | |
|---|---|---|
| Help Scout | اندروني ايپ جو client ID ۽ client secret | ضروري ناهي |
| Front | API token ۽ teammate ID | ضروري ناهي |
| Gorgias | ايجنٽ جي اي ميل ۽ API key | ضروري |
Help Scout ڳالهائڻ کان اڳ مٽاسٽا ڪري ٿو
Client secret سڌو قبول نٿو ڪري. پل پهرين مختصر مدي واري access token سان مٽائي ٿو — client credentials flow، جيڪو استعمال ڪندڙ بدران پنهنجي طرفان ڪم ڪندڙ ڳانڍاپي لاءِ آهي. Token پنهنجي مدي تائين يادگيري ۾ رهي ٿو؛ secret ڊيٽابيس ۾ رهي ٿو.
Front تبصري لاءِ ليکڪ گهرجي
Front ۾ تبصرو teammate جي نالي سان اچي ٿو، ۽ API اهو گهري ٿي. هتي ايجنٽ جي ليبل وارو خانو اهو رکي ٿو — لاگ ان نه، رڳو اهو ID جنهن جي نالي سان نوٽ آهي.
Gorgias کي هڪ بدران ٻه سوال گهرجن
ان جي ticket فهرست هن سان فلٽر ٿئي ٿي customer_id ۽ ٻئي ڪنهن سان نه — اي ميل فلٽر ناهي. تنهنڪري پل پهرين گراهڪ ڳولي، پوءِ سندس ticket گهري ٿو. Status سان به فلٽر نٿو ڪري سگهي، تنهنڪري کليل ticket اسان جي پاسي چونڊيو وڃي ٿو، بلڪل Freshdesk وانگر.
هتي ڄاڻايل سڀ تجارتي نشان پنهنجن مالڪن جا آهن. MousePlayer جو انهن فراهم ڪندڙن سان ڪو ڪاروباري لاڳاپو ناهي.