ฝ่ายช่วยเหลือ & ทิกเก็ต
บันทึกปรากฏเป็นหมายเหตุภายในทิกเก็ตที่เจ้าหน้าที่เปิดอยู่แล้ว ไม่ใช่กรณีใหม่ที่ไม่มีใครร้องขอ
1. คำถามแรกที่ฟีเจอร์นี้ต้องตอบ
ทิกเก็ตใด
สร้างทิกเก็ตทุกเซสชันที่ระบุตัวตนจะเป็นสแปม ทีมจะพบกรณีที่ไม่มีใครเปิด เพิ่มหมายเหตุทุกทิกเก็ตที่บุคคลเคยส่งก็เป็นสแปมเช่นกัน แค่ช้ากว่า
ดังนั้น: เพิ่มหมายเหตุภายในทิกเก็ตที่ยังเปิดล่าสุดของผู้ส่ง หากไม่มีทิกเก็ตเปิดจะไม่ทำอะไร จึงไม่สร้างกรณีที่ลูกค้าไม่ได้เริ่ม และเจ้าหน้าที่พบบันทึกในที่ที่กำลังดู
ภายในเท่านั้น ไม่เผยแพร่สาธารณะ ลิงก์นำเข้า MousePlayer ลูกค้าไม่ควรเห็นและเปิดตามไม่ได้อยู่แล้ว
2. Zendesk Support และ Freshdesk
รองรับทั้งคู่ ทำงานเดียวกันคนละวิธี ไม่ต้องจัดการความต่าง แต่ช่วยอธิบายว่าทำไมแบบฟอร์มถามต่างกันเล็กน้อย
| Zendesk Support | Freshdesk | |
|---|---|---|
| โดเมนย่อย | acme จาก acme.zendesk.com | acme จาก acme.freshdesk.com |
| อีเมลเจ้าหน้าที่ | ต้องใช้ Zendesk ลงชื่อเข้าใช้เป็น email/token | ไม่ต้องใช้ เว้นว่าง |
| โทเค็น API | Admin Center → Apps and integrations → APIs | การตั้งค่าโปรไฟล์ |
| หมายเหตุเป็น | ความคิดเห็นภายในทิกเก็ต | หมายเหตุส่วนตัวในทิกเก็ต |
วาง URL ทั้งหมดในช่องโดเมนย่อยได้หากสะดวกกว่า เราแยกส่วนที่ต้องการ เช่น https://acme.zendesk.com/agent/tickets/1 กลายเป็น acme
3. ทำงานเมื่อใด
ทันทีที่ระบุตัวตนเซสชัน เมื่อเว็บไซต์เรียก MousePlayer.setUserId() หรือสะพานวิเคราะห์อ่าน distinct ID กลับมา หรือเซิร์ฟเวอร์เรียกปลายทาง identify
เฉพาะ ID อีเมล
ทิกเก็ตเป็นของผู้ส่ง และระบบรู้จักผ่านอีเมล เลขสัญญาจึงค้นไม่ได้และไม่มีการส่ง
เฉพาะทิกเก็ตที่เปิด
ข้ามทิกเก็ตแก้แล้วหรือปิดแล้ว หมายเหตุในกรณีที่ไม่มีใครดูไม่ช่วยใคร และจะดันทิกเก็ตกลับให้เจ้าหน้าที่เห็นโดยไม่มีเหตุผล
หากผู้ส่งไม่มีทิกเก็ตเปิด นับว่าเสร็จ ไม่ใช่ล้มเหลว เป็นเรื่องปกติและลองใหม่ไม่เปลี่ยนอะไร
4. สิ่งที่เจ้าหน้าที่เห็น
หนึ่งหมายเหตุภายใน: MousePlayer: บันทึกเซสชันจาก <email> ตามด้วยลิงก์ คลิกเดียวดูสิ่งที่บุคคลทำจริงข้างคำอธิบายที่เขียน
จุดที่คุ้มค่า
- ทิกเก็ต “ใช้ไม่ได้” บันทึกมักแสดงในยี่สิบวินาทีสิ่งที่อีเมลสามรอบยังอธิบายไม่ได้
- ขั้นตอนทำซ้ำที่ไม่มีใครทำซ้ำได้ ไม่ต้องใช้แล้ว เพราะมีเซสชัน
- คลิกด้วยความหงุดหงิดและคลิกไม่ตอบสนอง ที่ลูกค้าไม่เคยกล่าวถึง เพราะคิดว่าผลิตภัณฑ์ทำงานแบบนั้น
โทเค็นไม่ออกจากเซิร์ฟเวอร์เรา
เก็บเข้ารหัส AES-256-GCM ไม่แสดงอีกหลังบันทึก และตั้งใจไม่ใส่ในคิวภายในที่เก็บงาน
5. Help Scout, Front และ Gorgias
อีกสามระบบช่วยเหลือ ทุกระบบเพิ่มหมายเหตุภายในบทสนทนาที่เปิด แต่ใช้วิธีต่างกัน
| สิ่งที่ระบุ | โดเมนย่อย | |
|---|---|---|
| Help Scout | ID และความลับไคลเอนต์ของแอปภายใน | ไม่ต้องใช้ |
| Front | โทเค็น API และ ID สมาชิกทีม | ไม่ต้องใช้ |
| Gorgias | อีเมลเจ้าหน้าที่และคีย์ API | ต้องใช้ |
Help Scout แลกก่อนสื่อสาร
ไม่รับความลับไคลเอนต์โดยตรง สะพานแลกเป็นโทเค็นเข้าถึงอายุสั้นก่อนด้วย client credentials flow สำหรับการเชื่อมต่อที่ทำในนามตนเอง ไม่ใช่ผู้ใช้ โทเค็นอยู่ในหน่วยความจำตลอดอายุ ส่วนความลับอยู่ในฐานข้อมูล
ความคิดเห็น Front ต้องมีผู้เขียน
ความคิดเห็นปรากฏในนามสมาชิกทีม และ API ต้องการ ID ช่องที่ระบุเจ้าหน้าที่จึงเก็บ ID นี้ ไม่ใช่ข้อมูลลงชื่อเข้าใช้ แต่เป็นผู้ที่แสดงชื่อบนหมายเหตุ
Gorgias ต้องถามสองครั้งแทนหนึ่ง
รายการทิกเก็ตกรองได้ด้วย customer_id เท่านั้น ไม่มีตัวกรองอีเมล สะพานจึงค้นลูกค้าก่อนแล้วขอทิกเก็ต กรองสถานะก็ไม่ได้ เราจึงเลือกทิกเก็ตเปิดฝั่งเราเหมือน Freshdesk
เครื่องหมายการค้าทั้งหมดที่กล่าวถึงเป็นของเจ้าของแต่ละราย MousePlayer ไม่มีความสัมพันธ์ทางธุรกิจกับผู้ให้บริการเหล่านี้