Cách xây dựng hệ thống ticket hỗ trợ: ticket, trạng thái, phân công và email

Hệ thống ticket hỗ trợ biến những yêu cầu rải rác (email, tin nhắn, các “câu hỏi nhanh” ngoài hành lang) thành ticket: mỗi vấn đề là một bản ghi, có người phụ trách, trạng thái, mức ưu tiên và toàn bộ cuộc trao đổi. Để xây một hệ thống như vậy, bạn cần cách tạo ticket, một hàng đợi chung có bộ lọc, phân công, một chuỗi tách biệt trả lời công khai và ghi chú nội bộ, và thông báo để không ai phải chờ mà không biết. Trình tạo app bằng AI có thể dựng một phiên bản đầu tốt cho bàn hỗ trợ IT, HR hoặc cơ sở vật chất nội bộ chỉ trong một buổi chiều. Hỗ trợ khách hàng bên ngoài với nhận diện chuỗi email, mục tiêu phản hồi và báo cáo cần nhiều công sức hơn, và đây là nơi các sản phẩm helpdesk có sẵn xứng đáng với phí của chúng.

Hệ thống cần những gì

Dữ liệu

Lưu thời điểm phản hồi đầu tiên và thời điểm giải quyết ngay từ đầu. Chúng là nền tảng của mọi báo cáo, và bạn không thể tái tạo lại về sau.

Các trang

• Người yêu cầu: biểu mẫu “gửi yêu cầu” với danh mục và tệp đính kèm, danh sách “yêu cầu của tôi”, và chuỗi của từng ticket.
• Nhân viên: hàng đợi (ticket của tôi, chưa được giao, tất cả đang mở), bộ lọc và tìm kiếm, trang ticket với các điều khiển trả lời, ghi chú, trạng thái, mức ưu tiên và người được giao.
• Quản trị: danh mục, nhóm, nhân viên, câu trả lời mẫu, và một báo cáo đơn giản.

Phân quyền

Người yêu cầu chỉ thấy ticket của chính họ và chỉ thấy trả lời công khai. Nhân viên thấy ticket của nhóm mình và ghi chú nội bộ. Trưởng nhóm và quản trị viên thấy tất cả và quản lý cài đặt. Ghi chú nội bộ bị lộ cho khách hàng là thảm họa kinh điển của helpdesk, nên hãy thực thi điều này trên máy chủ, không chỉ bằng cách ẩn một tab. Xem kiểm soát truy cập theo vai trò.

Quyết định và đánh đổi

Biểu mẫu, email hay cả hai

Biểu mẫu web là đơn giản nhất và cho dữ liệu sạch: danh mục, mức ưu tiên và các trường bắt buộc. Nhận yêu cầu qua email, nơi người ta viết đến địa chỉ hỗ trợ và một ticket xuất hiện, là điều khách hàng kỳ vọng, nhưng cần một nhà cung cấp email có thể nhận thư và đưa chúng vào ứng dụng của bạn, cùng với cơ chế nhận diện chuỗi để trả lời được gắn đúng ticket (thường là mã ticket trong tiêu đề hoặc một địa chỉ trả lời duy nhất). Hãy bắt đầu bằng biểu mẫu; thêm email khi quy trình đã được chứng minh. Gửi email từ ứng dụng bao quát phần gửi đi.

Phân công

Các lựa chọn: nhân viên tự chọn từ hàng đợi chưa được giao; xoay vòng trong nhóm; hoặc phân công theo danh mục. Chọn từ hàng đợi phù hợp với đội nhỏ. Phân công tự động hữu ích khi các ticket bắt đầu nằm không có người nhận.

Mức ưu tiên và mục tiêu phản hồi

Xác định hai hoặc ba mức ưu tiên, kèm mục tiêu phản hồi đầu tiên (“khẩn: 1 giờ, bình thường: 1 ngày làm việc”). Hiển thị thời gian còn lại trên mỗi ticket hữu ích hơn một báo cáo hằng tháng không ai đọc. Giờ làm việc khiến phép tính khó hơn; hãy quyết định sớm xem mục tiêu có tính ban đêm và cuối tuần hay không.

Gộp và ticket trùng

Cùng một vấn đề bị báo cáo ba lần là chuyện thường gặp. Hành động “gộp vào ticket số …” giúp nhân viên khỏi phải trả lời cùng một nội dung nhiều lần; đáng xây sớm.

Prompt đầu tiên hiệu quả

Xây dựng một helpdesk IT nội bộ cho công ty 60 người. Nhân viên gửi yêu cầu bằng biểu mẫu: tiêu đề, danh mục (phần cứng, phần mềm, quyền truy cập, mạng, khác), mức ưu tiên (thấp, bình thường, khẩn), mô tả và tệp đính kèm. Mỗi ticket có số và các trạng thái: mới, đang mở, chờ người yêu cầu, đã giải quyết, đã đóng. Nhân viên IT thấy hàng đợi với các tab: chưa được giao, của tôi, tất cả đang mở; lọc theo danh mục, mức ưu tiên và trạng thái, cùng tìm kiếm. Trang ticket hiển thị chuỗi với trả lời công khai và ghi chú nội bộ được tách rõ ràng; nhân viên không bao giờ thấy ghi chú nội bộ. Nhân viên IT có thể giao việc, đổi trạng thái và mức ưu tiên, dùng câu trả lời mẫu, và gộp ticket trùng. Theo dõi thời gian phản hồi đầu tiên và thời gian giải quyết, và hiển thị thời gian kể từ lần cập nhật cuối trên mỗi ticket. Nhân viên có trang “yêu cầu của tôi”. Vai trò: nhân viên, nhân viên IT, quản trị. Lưu mọi thứ trong cơ sở dữ liệu. Giao diện gọn, rõ, nhanh; ưu tiên tốc độ hơn trang trí.

Các bước xây dựng

1. Mô hình ticket và biểu mẫu. Gửi, liệt kê, mở một ticket, trả lời.
2. Hàng đợi và bộ lọc. Chưa được giao, của tôi, tất cả đang mở; lọc và tìm kiếm; sắp xếp theo mức ưu tiên và thời gian tồn.
3. Vai trò và đăng nhập. Người yêu cầu, nhân viên, quản trị, với ghi chú bị ẩn khỏi người yêu cầu trên máy chủ.
4. Điều khiển phân công, trạng thái và mức ưu tiên, kèm nhật ký hoạt động ghi lại mọi thay đổi.
5. Thông báo. Gửi email cho người yêu cầu khi có trả lời công khai và cho nhân viên khi được giao việc, qua nhà cung cấp email của bạn.
6. Câu trả lời mẫu và gộp.
7. Mục tiêu phản hồi và một báo cáo cơ bản: ticket đang mở theo độ tuổi, thời gian phản hồi đầu tiên, số ticket theo danh mục.
8. Nhận email, sau khi phần còn lại hoạt động, với việc nhận diện chuỗi được kiểm thử kỹ.
9. Chạy thử với một nhóm trong hai tuần trước khi chuyển mọi người sang.

Những lỗi thường gặp

• Ghi chú nội bộ hiển thị với người yêu cầu chỉ vì chúng chỉ được ẩn trên giao diện.
• Quá nhiều trạng thái và danh mục. Nhân viên sẽ chọn cái đầu tiên trông gần đúng. Ban đầu chỉ nên có tối đa năm mỗi loại.
• Không có dấu thời gian cho phản hồi đầu tiên và giải quyết. Bạn sẽ cần các con số vào ngày ai đó hỏi “chúng ta có đang nhanh hơn không?”.
• Trả lời qua email tạo ticket mới thay vì gắn vào chuỗi. Hãy kiểm thử bằng cách trả lời từ ứng dụng thư trên điện thoại, nơi tiêu đề thường bị đổi.
• Mọi người đều được giao, không ai chịu trách nhiệm. Mỗi ticket chỉ nên có một người phụ trách; dùng người theo dõi cho những người còn lại.
• Tệp đính kèm có URL công khai. Ảnh chụp thông báo lỗi thường chứa dữ liệu riêng tư. Hãy giữ tệp ở chế độ riêng tư và chỉ phục vụ cho những người có quyền xem ticket.

Khi một sản phẩm có sẵn là lựa chọn tốt hơn

Với hỗ trợ khách hàng bên ngoài qua email, chat và mạng xã hội, kèm theo theo dõi mục tiêu phản hồi, khảo sát hài lòng, macro, báo cáo và tích hợp, một sản phẩm helpdesk chuyên dụng hầu như luôn là khoản đầu tư tốt hơn. Các sản phẩm đó đã mất nhiều năm cho việc nhận diện chuỗi email, spam, định tuyến và báo cáo, và đó không phải là phần làm nên sự khác biệt của doanh nghiệp bạn. Hướng dẫn các lựa chọn thay thế Zendesk so sánh các lựa chọn.

Tự xây phù hợp với bàn nội bộ (IT, HR, cơ sở vật chất, yêu cầu tài chính), các quy trình đặc thù nơi một ticket thực chất là một công việc có các bước riêng, và các đội muốn yêu cầu gắn với dữ liệu khác họ đang giữ. Cách này cũng tránh được giá theo từng nhân viên khi nhiều người thỉnh thoảng cùng xử lý ticket. Hướng dẫn xây công cụ nội bộ bao quát rộng hơn về nhóm này.

Xây dựng với Mythex

Trên Mythex, bạn mô tả helpdesk trong khung chat, xem lại trong bản xem trước trực tiếp, và xuất bản cho đội của bạn. Ticket nằm trong cơ sở dữ liệu Postgres mà agent thêm vào khi dữ liệu cần được lưu, còn tệp đính kèm đi vào lưu trữ file của dự án. Đăng nhập cho người yêu cầu và nhân viên, cùng toàn bộ email đi và đến, dùng nhà cung cấp riêng của bạn; Mythex không có sản phẩm đăng nhập hay email cho người dùng cuối tích hợp sẵn. Công thức gửi email cho thấy cách tiếp cận. Các thành viên trong đội có thể cùng xây thông qua một không gian làm việc chung, và Mythex không tính phí theo từng chỗ ngồi.

Để có prompt khởi đầu, hãy thử mẫu hàng đợi yêu cầu nội bộ hoặc mẫu theo dõi lỗi, và kết hợp helpdesk với cơ sở kiến thức để các câu hỏi thường gặp tự được trả lời.

Câu hỏi thường gặp