Một cuộc trò chuyện trên WhatsApp Business nên trở thành ticket khi câu trả lời phụ thuộc vào điều tra, phòng ban khác hoặc một nhiệm vụ sẽ tiếp tục sau cuộc chat. Để bản ghi này hữu ích, nó cần cho biết vấn đề, những gì đã thử, ai sẽ tiếp tục và bước tiếp theo là gì. Lưu tin nhắn mà không sắp xếp những thông tin này sẽ để lại công việc đang chờ trong lịch sử.
Hướng dẫn này đề xuất một quy trình cho các đội hỗ trợ nhận báo cáo qua WhatsApp và cần theo dõi việc giải quyết. Mẫu, ví dụ và các bài kiểm tra bên dưới là mô hình làm việc để điều chỉnh cho vận hành; không đại diện cho các trường hợp thực tế hay kết quả đã đo lường.
Khi nào mở ticket và khi nào tiếp tục trong cuộc trò chuyện
Ticket, còn gọi là ticket, đại diện cho một yêu cầu có thể theo dõi. Một cuộc trò chuyện có thể chứa một câu hỏi đơn giản và một vấn đề cần phân tích. Hãy tách các chủ đề trước khi quyết định những gì cần ghi nhận.
| Tình huống | Đề xuất chuyển hướng | Tiêu chí quyết định |
|---|---|---|
| Khách hàng hỏi giờ hỗ trợ | Trả lời trong cuộc trò chuyện | Có thông tin hiện hành và đủ để giải quyết thắc mắc. |
| Một chức năng vẫn lỗi sau hướng dẫn ban đầu | Mở ticket kỹ thuật | Cần điều tra hành vi và theo dõi một hành động. |
| Khách hàng yêu cầu điều kiện thương mại | Chuyển đến bộ phận thương mại | Bước tiếp theo là quyết định bán hàng, không phải điều tra hỗ trợ. |
| Khách hàng hỏi lại về một vấn đề đã được ghi nhận | Tìm và tiếp tục trường hợp hiện có | Yêu cầu giống nhau; tin nhắn mới không có nghĩa là vấn đề mới. |
Sự phân tách này là quy tắc vận hành. Đừng giả định hệ thống sẽ phát hiện trùng lặp hoặc gom hồ sơ tự động. Nếu công cụ không thực hiện kiểm tra này, thì một người trong đội cần làm việc đó.
Chuẩn bị một biểu mẫu cho phép tiếp tục công việc
Trước khi chuyển trường hợp, kiểm tra xem người khác có thể hiểu công việc đang chờ mà không yêu cầu khách hàng kể lại mọi thứ hay không. Sử dụng các trường có sẵn trong hệ thống hoặc một hồ sơ nội bộ được ủy quyền. Cấu trúc sau đây là đề xuất quy trình, không phải danh sách trường bắt buộc của Whatsplaid.
- Tham chiếu trường hợp: định danh thực của bản ghi và liên kết với cuộc trò chuyện.
- Vấn đề quan sát được: điều gì đã xảy ra, ở bước nào và từ khi nào.
- Kết quả mong đợi: khách hàng đang cố hoàn thành điều gì.
- Tác động: những hoạt động nào bị cản trở và ai bị ảnh hưởng.
- Bằng chứng hữu ích: thông báo lỗi, thời gian gần đúng và hình ảnh liên quan khi cần.
- Những cố gắng trước đây: hướng dẫn đã thử và kết quả của chúng.
- Công việc đang chờ hiện tại: dữ liệu, quyết định hoặc hành động còn thiếu.
- Tiếp tục: người chịu trách nhiệm nội bộ, bước tiếp theo và thời điểm đã thống nhất để cập nhật.
Chỉ yêu cầu những gì còn thiếu để điều tra. Hướng dẫn khách che thông tin của bên thứ ba trên ảnh và không gửi mật khẩu hoặc mã truy cập. Một báo cáo không đầy đủ cần được xác định là không đầy đủ; IA hoặc người phục vụ không nên điền vào khoảng trống bằng một giả thuyết được trình bày như sự thật.
Ví dụ tóm tắt giúp đội
Hãy cân nhắc tình huống hư cấu sau: một người có thể đăng nhập vào hệ thống nhưng không thể tải xuống báo cáo. “Khách hàng gặp sự cố hệ thống” không cho biết nhiệm vụ bị chặn. Một bản tóm tắt hữu ích hơn sẽ là:
Khách hàng truy cập tài khoản nhưng không hoàn tất việc tải báo cáo. Báo cáo rằng lỗi bắt đầu sáng nay. Đã thử lại theo hướng dẫn nhưng không thay đổi. Ảnh chụp màn hình gửi kèm cho thấy thông báo lỗi, chưa được đội kỹ thuật phân tích. Cần xác nhận báo cáo nào đã được yêu cầu. Hành động tiếp theo: thu thập thông tin này và điều tra việc tải xuống.
Lưu ý rằng bản tóm tắt phân biệt giữa báo cáo, thử nghiệm và xác nhận đang chờ. Nó không gán lỗi cho trình duyệt hoặc máy chủ không có bằng chứng. Đội nên đối chiếu bản tóm tắt với lịch sử trước khi đưa ra quyết định.
Ưu tiên theo tác động và mức khẩn cấp
Tài liệu của Atlassian sử dụng tác động và tính khẩn cấp để xác định thứ tự ưu tiên trong quản lý sự cố. Áp dụng logic này vào quy trình của đội bạn: điều gì đang bị ảnh hưởng và còn bao nhiêu thời gian để hành động? Tham chiếu khái niệm có trong các nguồn ở cuối; điều này không ngụ ý có tích hợp với Whatsplaid.
Trong ví dụ báo cáo, một lỗi ngăn cản hoạt động có thời hạn ngay lập tức có thể xứng đáng nhận được chú ý trước một thắc mắc không gây tắc nghẽn vận hành. Mức ưu tiên phụ thuộc vào bối cảnh đã được xác thực, không chỉ vào từ “khẩn” trong tin nhắn.
Xác định ai kiểm duyệt phân loại ban đầu, đội xử lý tình trạng gián đoạn diện rộng như thế nào và ai chịu trách nhiệm khi người phụ trách thường trực không có mặt. Tách rời thời hạn cập nhật và thời hạn giải quyết: có thể thỏa thuận phản hồi về tiến độ mà không hứa hẹn sửa chữa khi nguyên nhân vẫn chưa rõ.
Giữ rõ trách nhiệm trong suốt quá trình điều tra
Khi chuyển ticket sang bộ phận khác, xác định ai sẽ điều tra và ai sẽ tiếp tục trao đổi với khách hàng. Những vai trò này có thể do những người khác nhau đảm nhiệm, nhưng cam kết phản hồi cần vẫn hiển thị.
Một hộp thư đến có lịch sử và can thiệp con người giúp đội tiếp tục cuộc trò chuyện. Ticket tổ chức công việc còn dang dở. Để sắp xếp hoạt động của nhiều người trên kênh, hướng dẫn về đa xử lý với IA và đội nhân sự đề cập đến các quy tắc chuyển tiếp giữa các đại diện.
Nếu việc tạo hoặc chuyển hướng thất bại
Đừng thông báo rằng một ticket đã được mở trước khi xác nhận ghi nhận. Nếu thao tác dùng tích hợp bên ngoài, cũng kiểm tra xem điểm đến đã nhận trường hợp chưa. Một lần gửi thử không chứng minh đã nhận. Dùng quy trình dự phòng của đội, giữ nguyên bối cảnh và giải thích với khách hàng liên hệ tiếp theo sẽ là gì, không bịa số tham chiếu.
Nếu khách quay lại trước khi có giải pháp
Kiểm tra ticket hiện có, ghi nhận thông tin mới và đánh giá xem mức độ ảnh hưởng có thay đổi không. Tránh lặp lại hướng dẫn đã thử trước đó. Nếu tin nhắn mới đề cập vấn đề khác, ghi lại mối liên hệ giữa các chủ đề và quyết định xem có cần theo dõi riêng biệt hay không.
Những gì có thể tự động hóa trong Whatsplaid
Tài liệu Whatsplaid mô tả tạo ticket nội bộ trong khi hỗ trợ, kèm tóm tắt, danh mục, ưu tiên và bối cảnh cuộc trò chuyện. Đội cũng có thể theo dõi lịch sử, tạm dừng IA và trả lời qua bảng điều khiển. Cấu hình luồng cần được kiểm tra trước khi kích hoạt.
Điều này không biến mọi quy tắc được đề xuất trong hướng dẫn này thành tính năng tự động. Người chịu trách nhiệm vụ việc, xem xét lại ưu tiên, kiểm soát thời hạn, xử lý trùng lặp và tiêu chí đóng vụ việc cần được công ty xác định và kiểm chứng trong công cụ áp dụng. Đừng cho là có phân phối tự động giữa kỹ thuật viên, cảnh báo thời hạn hoặc tích hợp với hệ thống cụ thể mà không có chứng thực.
Cũng phân tách các lớp: cuộc trò chuyện trong ứng dụng WhatsApp Business, gửi tin nhắn qua WhatsApp Business Platform và ticket lưu trong phần mềm hỗ trợ là những phần khác nhau của quy trình. Tự động hóa qua tích hợp phụ thuộc vào hành động và xác nhận có sẵn trong từng hệ thống.
Đóng vụ với bằng chứng và thông báo cho khách
Xác định trước điều gì cho phép kết thúc từng loại ticket. Trong ví dụ báo cáo, một sửa lỗi được áp dụng cần kèm theo kiểm tra việc tải xuống trong bối cảnh bị ảnh hưởng. Ghi nhận một hành động kỹ thuật và xác nhận vấn đề đã được giải quyết là hai bước khác nhau.
Ghi lại biện pháp đã thực hiện, kết quả kiểm tra và bất kỳ giới hạn còn lại. Nếu không có phản hồi từ khách, tuân theo quy tắc theo dõi rõ ràng; đừng ghi nhận xác nhận chưa xảy ra. Việc khởi động lại IA cũng cần được kiểm tra trong luồng đã cấu hình.
Khi gửi phản hồi qua WhatsApp Business Platform, hãy tuân thủ cửa sổ hỗ trợ 24 giờ, mở hoặc được làm mới bởi tin nhắn của người dùng. Ngoài cửa sổ này, chính sách yêu cầu các mẫu đã được phê duyệt. Việc có một ticket mở không kéo dài cửa sổ này. Cũng tôn trọng các yêu cầu ngừng gửi tin nhắn và giữ lộ trình rõ ràng để hỗ trợ bằng con người.
Thử nghiệm quy trình trước khi mở rộng hoạt động
Sử dụng các trường hợp giả để kiểm tra toàn bộ luồng, bao gồm thất bại. Các bài kiểm tra dưới đây là đề xuất xác thực; chúng chưa được chạy trên tài khoản thực.
- Câu hỏi đơn giản: xác nhận rằng nó có thể được giải quyết mà không tạo ticket không cần thiết.
- Báo cáo thiếu: kiểm tra xem dữ liệu thiếu có được yêu cầu hoặc được ghi là đang chờ hay không, không bịa đặt.
- Lỗi tạo: xác minh rằng phản hồi tránh xác nhận bản ghi không tồn tại và kích hoạt phương án dự phòng.
- Phản hồi về cùng một vấn đề: kiểm tra xem đội ngũ có tìm được trường hợp trước đó trước khi mở trường hợp khác không.
- Can thiệp của con người: xác nhận lịch sử có thể truy cập và tạm dừng AI trong khi nhân viên can thiệp.
- Đóng: xác nhận bằng chứng đã giải quyết, giao tiếp được phép và hành vi của tự động hóa sau khi hoàn thành.
Trong giai đoạn thử nghiệm, rà soát các ticket không có bước tiếp theo, hồ sơ không đầy đủ, phản hồi không được giải quyết và các phân loại được đội sửa. Đo theo loại yêu cầu và ghi lại cách mỗi chỉ số được tính. Đây là các đề xuất giám sát; chúng không ngụ ý có báo cáo sẵn trong sản phẩm hoặc mục tiêu hiệu suất chung.
Nguồn tham khảo
Truy vấn thực hiện ngày 30 tháng 9 năm 2026. Quy tắc kênh và tính năng công cụ có thể thay đổi; kiểm tra tài liệu hiện hành khi cấu hình hoạt động.
- Chính sách nhắn tin của WhatsApp Business: cửa sổ dịch vụ, mẫu và đường dây leo thang.
- Atlassian: tác động, mức khẩn cấp và ưu tiên: tham chiếu khái niệm để tổ chức phân loại (triage).
Để đánh giá việc tạo ticket có ngữ cảnh từ các cuộc trò chuyện của công ty bạn, tìm hiểu về ticket của Whatsplaid cho hỗ trợ trên WhatsApp Business và xem cách tính năng này phù hợp với quy trình hỗ trợ của bạn.