Hỗ trợ hàng đợi chat và email
Khi hai kênh cùng tăng tải, cần quy tắc ưu tiên. Không nên tính mỗi tin nhắn là một yêu cầu hoàn tất nếu vấn đề vẫn đang mở.
Phạm vi, nguồn lực, chi phí và lịch phục vụ được xác định sau khảo sát.
Điều cần biết trước khi bắt đầu
Chat và email có cách vận hành khác nhau: chat phụ thuộc số hội thoại đồng thời và bàn giao trực tiếp; email phụ thuộc luồng thư, người sở hữu hồ sơ và theo dõi phản hồi. Cả hai cần nguồn trả lời được duyệt, bước xác minh và giới hạn giữa soạn nháp với gửi đi.
Chuẩn bị đủ bối cảnh để trả lời
Cung cấp luồng hội thoại mẫu, giọng văn, liên kết chính sách và quyền tài khoản. Gắn phản hồi với mã yêu cầu, giữ lịch sử trao đổi và chỉ định người theo dõi để tránh gửi hai câu trả lời mâu thuẫn cho cùng một khách.
Xử lý thiếu thông tin và yêu cầu nhạy cảm
Dùng mẫu xin bổ sung được duyệt khi thiếu bằng chứng. Chuyển khiếu nại, yêu cầu tài khoản bất thường và ngoại lệ chính sách kèm tóm tắt. Tệp đính kèm cần nằm trong công cụ được phép, không sao chép thông tin nhạy cảm sang nơi không thuộc phạm vi.
Đo công theo cách vận hành thực tế
Lô thử cần có email dài, chat chồng thời điểm và công sau hội thoại. Phí phụ thuộc ngôn ngữ, lịch phục vụ, quyền gửi và định nghĩa hồ sơ hoàn tất; quy tắc mở lại yêu cầu phải rõ trước khi tính sản lượng.
Quy tắc chat và email khác nhau ở điểm nào
Hỗ trợ viết tập trung vào luồng hội thoại, quyền gửi và bàn giao theo kênh. Bảng dưới là mẫu thiết kế để khảo sát; số cuộc chat đồng thời và thời gian trả lời phải được đo với độ phức tạp thực, không đặt chung trước khi thử.
| Tiêu chí | Chat | Điều cần chốt | |
|---|---|---|---|
| Người theo dõi | Có thể cần chuyển khi hết phiên | Một chủ hồ sơ theo luồng | Ai nhận khi chuyển ca |
| Công xử lý | Tin đến chồng thời điểm | Đọc cả thư và tệp liên quan | Cách đo công sau hội thoại |
| Thời điểm phản hồi | Thông điệp có nội dung | Thư trả lời được phép gửi | Auto-reply có được tính không |
| Quyền gửi | Kịch bản và ngoại lệ | Soạn nháp hoặc duyệt rồi gửi | Ai phê duyệt nội dung nhạy cảm |
| Mở lại | Khách quay lại cùng vấn đề | Reply trong thread cũ | Mã chung và quy tắc tính vụ việc |
Mẫu bàn giao một luồng thư chưa đủ dữ kiện
Ví dụ minh họa: khách gửi thư báo sản phẩm không đúng lựa chọn nhưng thiếu mã đơn. Người xử lý đọc toàn bộ thread, kiểm tài liệu được phép xem rồi soạn yêu cầu bổ sung mã đơn và lựa chọn đã nhận. Mẫu cần nói rõ thông tin nào còn thiếu, dùng để làm gì và kênh gửi phù hợp; không yêu cầu khách gửi giấy tờ nhạy cảm không cần thiết.
Nếu cuối ca vẫn chưa có phản hồi, hồ sơ bàn giao ghi mã vụ việc, vấn đề, dữ kiện đã có, thư cuối đã gửi hoặc còn chờ duyệt, người nhận ca và bước tiếp theo. Không gửi thêm một email cùng nội dung chỉ để làm mới thời điểm hoạt động.
Kiểm tra trước khi gửi và trước khi mở tệp
Thư nháp phải được đối chiếu người nhận, mã vụ việc, chính sách, giọng văn và phần đính kèm. Kiểm liên kết hay tệp trong công cụ được phép; không chuyển tệp khách sang tài khoản cá nhân. Với thư hàng loạt hoặc gửi người ngoài luồng, cần xác nhận rõ quyền và danh sách nhận.
Một email soạn xong không phải một email đã được doanh nghiệp duyệt. Báo cáo cần phân biệt chờ duyệt, sẵn sàng gửi, đã gửi và chờ khách. Nếu khách hỏi qua cả chat và email, nối mã vụ việc theo quy tắc để tránh câu trả lời mâu thuẫn và đếm trùng kết quả.
Khảo sát tải đồng thời thay vì chỉ đếm số tin
Mẫu thử cần phản ánh giờ đông khách, độ dài thư, số tệp và tỷ lệ cần người khác trả lời. Theo dõi thời gian đọc ngữ cảnh, soạn, kiểm và ghi nhận sau trao đổi; tổng số tin không cho thấy khả năng xử lý đồng thời hay công cho một ca khó.
Doanh nghiệp cần chốt kênh ưu tiên, thời gian phục vụ theo múi giờ, tuyến thay thế và ngôn ngữ được kiểm tra. Phí, đơn vị tính hội thoại và giới hạn công việc phụ thuộc kết quả khảo sát này; không mặc định mỗi tin nhắn là một việc được nghiệm thu.
Câu hỏi thường gặp
Có chỉ thuê soạn nháp được không?
Có thể khảo sát phạm vi phân loại và soạn nháp, doanh nghiệp giữ quyền duyệt và gửi.
Một tin nhắn có phải một đơn vị nghiệm thu?
Nên định nghĩa theo hội thoại hoặc đầu ra cụ thể, tránh đếm tin nhắn thay cho kết quả.
Email trả lời tự động có tính đạt phản hồi đầu tiên không?
Chỉ khi định nghĩa dịch vụ chấp nhận rõ mốc đó. Nên tách thông báo nhận yêu cầu khỏi phản hồi có nội dung để số đo có ý nghĩa.
Một khách hỏi hai kênh được tính mấy yêu cầu?
Cần kiểm có cùng vấn đề và cùng hồ sơ hay không. Quy tắc nối mã, mở lại và đơn vị nghiệm thu được thỏa thuận để tránh đếm trùng.
Ai chịu trách nhiệm email chưa được duyệt?
Hồ sơ phải ghi người duyệt và người theo dõi. Việc chờ không biến thành quyền tự gửi; tuyến nhắc và thay thế cần được xác định trước.
Đầu việc nào đang cần giảm tải?
Mô tả công việc, khối lượng và đầu ra doanh nghiệp cần nhận. Uptech sẽ trao đổi để xác định phạm vi, cách kiểm tra và nguồn lực phù hợp.
- Một đầu việc hoặc lô xử lý để bắt đầu
- Giá và lịch làm thử được thỏa thuận trước
- SLA theo quy trình và kết quả khảo sát
Ở bước này, chỉ cần mô tả nhu cầu. Dữ liệu mẫu cần bảo vệ sẽ được trao đổi qua kênh thống nhất sau khi làm rõ quyền truy cập.