INFOCHIEF ACADEMY · HELPDESK & SERVICE DESK KNOWLEDGE SERIES

Kỹ thuật đặt câu hỏi để xác định đúng vấn đề người dùng đang gặp phải.

Câu hỏi đúng biến phản ánh chung thành hiện tượng có thể kiểm chứng. Bắt đầu từ công việc, đối chiếu phạm vi và thời điểm, rồi xác nhận cách hiểu giúp Helpdesk chọn phép thử phù hợp và giảm vòng liên hệ lại.

Biên soạn: Infochief Academy · Chuyên đề: Helpdesk và Service Desk

← Trở về thư viện bài viết

Minh họa biên tập: nhân viên hỗ trợ lắng nghe người dùng mô tả biểu hiện trên màn hình cùng người hướng dẫn.

“Máy tính của tôi không dùng được” có thể nghĩa là không bật lên, không vào được mạng hoặc một thao tác trong ứng dụng không hoàn tất. Nếu nhân viên hỗ trợ lập tức đề nghị khởi động lại, cuộc trao đổi đã chuyển sang giải pháp trước khi xác định hiện tượng. Một câu hỏi đúng ở đầu cuộc gọi có thể tiết kiệm nhiều vòng thử sau đó.

Đặt câu hỏi không phải lấy đủ trường trong biểu mẫu hay kiểm tra kiến thức của người dùng. Mục tiêu là xây một mô tả mà hai bên cùng hiểu, từ đó chọn phép kiểm tra phân biệt được các khả năng. Câu hỏi tốt cần vừa có giá trị chẩn đoán vừa giữ cho người dùng cảm thấy mình đang được hỗ trợ.

Mở bằng công việc, rồi thu hẹp đến bước bị chặn

Hãy bắt đầu với “Anh chị đang cần làm việc gì?” hoặc “Ở bước nào kết quả khác với bình thường?”. Người dùng có thể không biết thuật ngữ kỹ thuật, nhưng thường mô tả được hành động và điều họ mong xảy ra. Thông tin này giúp chọn đúng phạm vi trước khi hỏi cấu hình.

Sau câu hỏi mở, dùng câu hỏi cụ thể để làm rõ: màn hình hiện gì, có thông báo nào, thao tác có hoàn tất một phần không. Hỏi từng ý, tránh một chuỗi dài khiến người dùng trả lời sót. Không nên đặt câu dẫn như “Chắc anh chị vừa đổi mật khẩu?” nếu chưa có bằng chứng.

Cần phân biệt điều người dùng quan sát với điều họ suy đoán. “Nhấn gửi nhưng không có xác nhận” là hiện tượng; “máy chủ lỗi” là giả thuyết. Tôn trọng lời giải thích của người dùng nhưng giữ hai loại thông tin riêng để không khóa hướng điều tra quá sớm.

Nền tảng trong IT Helpdesk giúp kết hợp giao tiếp và chẩn đoán. Nhân viên cần nghe đủ bối cảnh rồi chọn câu hỏi tiếp theo theo dữ liệu, thay vì đọc một danh sách cố định cho mọi tình huống.

Lập mốc thời gian và phạm vi bằng câu hỏi đối chiếu

Hỏi lần cuối còn dùng được, lần đầu thấy lỗi và lỗi có lặp lại không. Người dùng có thể không nhớ chính xác; ghi thời gian ước lượng và mức chắc chắn. Không nên biến một mốc gần đúng thành dữ liệu chính xác khi đối chiếu log sau đó.

Phạm vi giúp phân nhánh: chỉ một người hay nhiều người, chỉ một ứng dụng hay nhiều ứng dụng, chỉ một mạng hay mọi nơi. Câu hỏi cần kiểm tra điều biết thật. “Có ai khác gặp không?” khác với “Tất cả mọi người đều lỗi phải không?”; cách thứ hai dễ tạo một khẳng định chưa được xác nhận.

Các thay đổi gần đây là đầu mối: phiên bản mới, thiết bị khác, nơi làm việc mới hoặc một thao tác vừa thực hiện. Nhưng thời điểm gần nhau chưa chứng minh nguyên nhân. Hỏi theo cách trung tính, tránh làm người dùng cảm thấy bị tìm lỗi hoặc phải che thông tin mình đã thao tác.

Nhóm câu hỏi	Cách hỏi minh họa	Mục đích chẩn đoán
Công việc và biểu hiện	Anh chị làm bước nào, mong kết quả gì và hiện thấy gì?	Xác định hiện tượng cần kiểm chứng
Thời gian	Lần cuối dùng được và lần đầu thấy lỗi vào khoảng nào?	Chọn dữ liệu và điều kiện liên quan
Phạm vi	Chức năng khác hoặc người khác có dùng được không?	Thu hẹp thành phần hoặc khả năng sự cố chung
Điều kiện	Khi đổi mạng hoặc thử lại, biểu hiện có khác không?	So sánh giả thuyết trong phép thử an toàn

Các câu trong bảng là ví dụ, không phải kịch bản bắt buộc. Nhân viên cần chọn theo thông tin đã có; hỏi lại điều người dùng vừa giải thích sẽ làm họ thấy mình chưa được lắng nghe.

Đọc lại mô tả trước khi đề nghị thao tác

Một câu tóm tắt ngắn giúp kiểm tra cách hiểu: người dùng, công việc, biểu hiện, thời điểm và phạm vi. Hãy để người dùng sửa những chỗ chưa đúng. Chỉ sau đó mới đề nghị phép kiểm tra phù hợp, đồng thời giải thích nó sẽ giúp xác nhận điều gì.

Mỗi phép thử nên có một mục đích. Nếu kiểm tra ứng dụng khác, mục đích có thể là phân biệt lỗi toàn kết nối với lỗi một dịch vụ. Nếu thử một tệp mẫu được phép, có thể kiểm tra vấn đề gắn với dữ liệu hay chức năng. Không yêu cầu đổi nhiều điều cùng lúc nếu muốn hiểu kết quả.

Cần hỏi kết quả sau mỗi bước bằng hiện tượng cụ thể. “Được chưa?” có thể được hiểu là cửa sổ đã mở, trong khi giao dịch vẫn lỗi. “Anh chị đã gửi được và thấy xác nhận chưa?” nối phép thử với kết quả cần đạt trong phạm vi đang xử lý.

Khi câu trả lời không khớp, trở lại mô tả và giả thuyết. Đừng lặp một thao tác chỉ vì nó thường hiệu quả ở các ca khác. Những bước đã thử và kết quả cần được ghi để nhóm nhận sau không yêu cầu người dùng làm lại mà không có lý do.

Giữ câu hỏi trong giới hạn bảo mật và khả năng của người dùng

Không hỏi mật khẩu, mã xác thực hoặc yêu cầu gửi toàn bộ dữ liệu nhạy cảm. Nếu cần ảnh chụp, hướng dẫn che phần không liên quan và dùng kênh được phép. Nếu cần log, chọn phạm vi đủ cho điều tra và quyền truy cập phù hợp.

Với thao tác có thể ảnh hưởng dữ liệu, cần giải thích rủi ro và điều kiện. Không hướng dẫn người dùng xóa, đặt lại hoặc thay quyền khi chưa hiểu tác động và chưa có cơ chế cho phép. Một câu hỏi chẩn đoán có thể dẫn đến hành động, nên người hỗ trợ vẫn phải chịu trách nhiệm với hướng dẫn đó.

Nội dung trong quản trị an toàn thông tin giúp đội thống nhất những giới hạn này. Áp lực thời gian không làm việc xác minh danh tính hoặc bảo vệ dữ liệu trở nên tùy chọn.

Cần điều chỉnh nhịp theo người dùng. Người không quen kỹ thuật có thể cần mô tả bằng hình ảnh và thao tác đơn giản; người có kinh nghiệm có thể cung cấp chi tiết nhanh hơn. Không đánh đồng giọng bình tĩnh với hiểu biết kỹ thuật hoặc giọng căng thẳng với thông tin không đáng tin.

Tình huống giả định: “không vào được email”

Giả sử người dùng báo không vào được email. Đây là ví dụ minh họa. Nhân viên hỏi công việc và thấy người dùng mở được hộp thư nhưng không gửi được một tệp đính kèm. Nếu bắt đầu bằng đặt lại mật khẩu, đội sẽ xử lý một điều chưa có bằng chứng là vấn đề.

Tiếp theo, nhân viên xác nhận loại thông báo, thời điểm, kích thước tệp và khả năng gửi thư không đính kèm. Chỉ thu thập đặc điểm cần thiết, không yêu cầu gửi nội dung tài liệu. Những đối chiếu này giúp chọn nhánh về giới hạn tệp, chính sách hoặc đường gửi, nhưng chưa tự chứng minh nguyên nhân.

Nếu người dùng khác có biểu hiện tương tự, cần kiểm tra khả năng sự cố chung. Nếu chỉ một tệp, có thể cần xem định dạng hoặc điều kiện dữ liệu theo hướng dẫn. Mỗi bước được giải thích và ghi kết quả, tránh để người dùng thử nhiều thay đổi mà không biết mục đích.

Sau xử lý, kiểm tra việc gửi trong phạm vi được phép và xác nhận người nhận hoặc trạng thái gửi theo điều kiện phù hợp. Nếu cần chuyển nhóm, hồ sơ mô tả rõ khả năng nào đạt, khả năng nào chưa đạt và các bước đã thử. Người dùng không phải kể lại từ đầu.

Theo cách tiếp cận quản lý dịch vụ IT, thông tin chẩn đoán này còn hỗ trợ phân loại, ưu tiên và cải tiến hướng dẫn. Câu hỏi tốt làm chất lượng dữ liệu đầu vào cao hơn cho toàn chuỗi hỗ trợ.

Nếu người dùng không biết câu trả lời, đừng buộc họ đoán để điền đủ hồ sơ. Có thể đổi cách hỏi sang điều họ nhìn thấy hoặc xin phép kiểm tra qua công cụ được cho phép. Trong hồ sơ, giữ phần chưa xác nhận như một khoảng trống cần kiểm tra. Dữ liệu thiếu nhưng được ghi rõ thường hữu ích hơn một câu trả lời có vẻ cụ thể nhưng chỉ được suy đoán để cuộc gọi tiếp tục.

Đào tạo bằng cuộc trao đổi thực tế và dữ liệu ticket

Người giám sát có thể rà mẫu ticket hoặc cuộc trao đổi theo cơ chế được tổ chức cho phép. Xem nhân viên có làm rõ công việc, hỏi trung tính, xác nhận phạm vi và đọc lại cách hiểu không. Không nên đánh giá chỉ bằng số câu hỏi hoặc độ ngắn cuộc gọi.

Cần nhận biết những lần hỏi thiếu khiến phải liên hệ lại, và những lần hỏi quá nhiều không tạo thêm giá trị. Một cuộc gọi ngắn nhưng chuyển sai nhóm có thể làm tổng thời gian dài hơn. Chất lượng đặt câu hỏi được đo theo khả năng đưa vấn đề đến đúng bước tiếp theo.

Năng lực giám sát đội IT giúp biến kết quả rà thành huấn luyện cụ thể. Có thể dùng tình huống giả lập, cho nhân viên giải thích câu hỏi nào phân biệt các khả năng và phản hồi về cách diễn đạt với người dùng.

Bộ câu hỏi nên giữ như hướng dẫn linh hoạt theo loại nhu cầu. Khi dịch vụ hoặc cách dùng thay đổi, cập nhật những câu quan trọng và điều kiện chuyển cấp. Tránh thêm mọi câu vào một mẫu chung khiến người dùng phải trả lời thông tin không liên quan.

Trong ca hỗ trợ tiếp theo, nhân viên có thể bắt đầu với công việc, biểu hiện và một câu đối chiếu phạm vi, rồi đọc lại trước thao tác. Cách làm nhỏ này tạo kỷ luật chẩn đoán mà không biến cuộc trò chuyện thành một cuộc hỏi cung.

Đặt câu hỏi tốt là cách đội IT bảo vệ độ chính xác của hành động. Khi người dùng được lắng nghe và hiện tượng được mô tả rõ, giải pháp được chọn có căn cứ hơn, chuyển cấp ít mất thông tin hơn và kết quả hỗ trợ có thể được xác nhận theo điều cả hai bên cùng hiểu.