Hệ thống hỗ trợ & quản lý phiếu

Bản ghi xuất hiện dưới dạng ghi chú nội bộ trên phiếu nhân viên đang mở - không phải yêu cầu mới mà chẳng ai đề nghị.

1. Câu hỏi tính năng này phải trả lời trước

Phiếu nào?

Tạo phiếu cho mỗi phiên được nhận diện sẽ là spam: nhóm hỗ trợ sẽ thấy những yêu cầu chưa ai mở. Thêm ghi chú vào mọi phiếu người đó từng gửi cũng là spam, chỉ chậm hơn.

Vì vậy: ghi chú nội bộ trên phiếu MỞ gần nhất của người gửi. Nếu không có phiếu mở, hoàn toàn không có gì xảy ra. Nhờ đó chúng tôi không bao giờ tạo yêu cầu khách hàng chưa khởi tạo và nhân viên tìm thấy bản ghi đúng nơi đang xem.

Nội bộ, không bao giờ công khai. Liên kết dẫn vào MousePlayer. Khách hàng không nên nhìn thấy và dù sao cũng không thể truy cập.

2. Zendesk Support và Freshdesk

Cả hai đều được hỗ trợ và giải quyết cùng công việc theo cách khác nhau. Bạn không cần quan tâm - nhưng điều đó giải thích vì sao biểu mẫu yêu cầu thông tin hơi khác nhau.

Zendesk SupportFreshdesk
Miền phụacme từ acme.zendesk.comacme từ acme.freshdesk.com
Email nhân viêncần - Zendesk đăng nhập dưới dạng email/tokenkhông cần, để trống
Token APITrung tâm quản trị → Ứng dụng và tích hợp → APICài đặt hồ sơ của bạn
Ghi chú trở thànhbình luận nội bộ trên phiếughi chú riêng tư trên phiếu

Dán toàn bộ URL vào trường miền phụ nếu tiện hơn - chúng tôi rút gọn thành phần cần dùng nên https://acme.zendesk.com/agent/tickets/1 trở thành acme.

3. Khi nào kích hoạt

Ngay khi phiên được nhận diện - khi trang của bạn gọi MousePlayer.setUserId(), khi cầu nối phân tích đọc lại mã định danh riêng hoặc khi máy chủ của bạn gọi điểm cuối identify.

Chỉ với địa chỉ email

Phiếu thuộc một người gửi và hệ thống hỗ trợ biết người gửi qua email. Số hợp đồng không tìm được gì ở đó nên không gửi gì.

Chỉ với phiếu mở

Bỏ qua phiếu đã giải quyết và đã đóng. Ghi chú trên yêu cầu không ai xem nữa không giúp được ai và đẩy phiếu đã đóng trở lại tầm nhìn của nhân viên mà không có lý do.

Nếu người gửi không có phiếu mở, được tính là hoàn tất, không phải thất bại - đó là trường hợp bình thường và thử lại không thay đổi gì.

4. Điều nhân viên nhìn thấy

Một ghi chú nội bộ: MousePlayer: bản ghi phiên từ <email> rồi đến liên kết. Một lượt nhấp để xem người đó thực sự đã làm gì, ngay cạnh những gì họ đã mô tả.

Nơi tính năng mang lại giá trị

  • Phiếu “Không hoạt động”. Bản ghi thường cho thấy trong hai mươi giây điều mà ba vòng email không làm được.
  • Các bước tái hiện mà không ai tái hiện được. Bạn không còn cần chúng - đã có phiên.
  • Nhấp do bực bội và nhấp không có phản hồi mà khách hàng không bao giờ nhắc đến vì cho rằng sản phẩm hoạt động như vậy.

Token không bao giờ rời máy chủ của chúng tôi

Được lưu có mã hóa AES-256-GCM, không hiển thị lại sau khi lưu và chủ động không nằm trong hàng đợi nội bộ mang tác vụ.

5. Help Scout, Front và Gorgias

Thêm ba hệ thống hỗ trợ. Cả ba đều thêm ghi chú nội bộ vào hội thoại mở và thực hiện theo những cách khác nhau.

Bạn cung cấpMiền phụ
Help ScoutID máy khách và khóa bí mật máy khách của ứng dụng nội bộkhông cần
Fronttoken API và ID đồng độikhông cần
Gorgiasemail nhân viên và khóa APIcần

Help Scout trao đổi trước khi gửi

Không chấp nhận trực tiếp khóa bí mật máy khách. Trước tiên cầu nối đổi lấy token truy cập ngắn hạn - luồng thông tin xác thực máy khách, dành cho tích hợp tự hoạt động thay vì đại diện người dùng. Token nằm trong bộ nhớ suốt thời hạn hiệu lực; khóa bí mật ở lại cơ sở dữ liệu.

Bình luận Front cần tác giả

Bình luận trong Front xuất hiện dưới tên đồng đội và API bắt buộc có tác giả. Đó là nội dung trường dành cho nhân viên ở đây - không phải tên đăng nhập, chỉ là ID có tên xuất hiện trên ghi chú.

Gorgias cần hai truy vấn thay vì một

Danh sách phiếu chỉ lọc theo customer_id và không có gì khác - không có bộ lọc email. Vì vậy cầu nối tìm khách hàng trước rồi yêu cầu phiếu của họ. Cũng không thể lọc theo trạng thái nên phiếu mở được chọn phía chúng tôi, giống cách đã dùng cho Freshdesk.

Mọi nhãn hiệu nêu ở đây thuộc chủ sở hữu tương ứng. MousePlayer không có quan hệ kinh doanh với các nhà cung cấp này.