top of page

Cổng self-service IT Helpdesk cần có gì để nhân viên thực sự sử dụng?

4 ngày trước
11 phút đọc

Một cổng hỗ trợ có thể chứa hàng trăm bài hướng dẫn và biểu mẫu nhưng vẫn ít người dùng. Khi không tìm thấy đúng yêu cầu, không hiểu bước tiếp theo hoặc không biết ai đang xử lý, nhân viên thường quay lại nhắn trực tiếp cho IT.

Vì vậy, doanh nghiệp đang cân nhắc triển khai cổng self-service IT Helpdesk cần đánh giá nhiều hơn phần mềm: nhân viên sẽ dùng cổng để làm việc gì, tìm thông tin ra sao, yêu cầu được chuyển cho ai và hiệu quả được đo thế nào. Cổng tự phục vụ nên giúp nhân viên giải quyết những việc phù hợp hoặc gửi yêu cầu đầy đủ thông tin. IT Helpdesk vẫn cần tiếp nhận các tình huống phức tạp, khẩn cấp và cần can thiệp kỹ thuật.

Những yêu cầu nào phù hợp để đưa lên cổng self-service IT Helpdesk?

Một cổng tự phục vụ hữu ích nên bắt đầu từ các yêu cầu thường gặp, có hướng dẫn rõ ràng hoặc có quy trình tiếp nhận lặp lại được. Đó có thể là cách kết nối máy in, yêu cầu cài ứng dụng đã được doanh nghiệp phê duyệt, đề nghị cấp thiết bị hoặc báo lỗi tài khoản.

cong-self-service-it-helpdesk
Một cổng tự phục vụ hữu ích nên bắt đầu từ các yêu cầu thường gặp, có hướng dẫn rõ ràng hoặc có quy trình tiếp nhận lặp lại được

Cần phân biệt hai việc thường được gọi chung là “tự phục vụ”:

  • Tự tra cứu và thực hiện: Nhân viên đọc hướng dẫn, làm theo các bước được phép và xác nhận kết quả.

  • Tự gửi và theo dõi yêu cầu: Nhân viên chọn đúng loại việc, cung cấp thông tin cần thiết, rồi theo dõi trạng thái. Bộ phận IT vẫn phê duyệt hoặc xử lý khi cần.

Ví dụ, hướng dẫn kiểm tra kết nối Wi-Fi có thể giúp nhân viên tự xác định một lỗi đơn giản. Trái lại, yêu cầu cấp quyền vào dữ liệu nhạy cảm không nên trở thành thao tác “bấm để được cấp quyền”. Doanh nghiệp cần xác minh người yêu cầu, người phê duyệt và phạm vi truy cập.

Sự cố ảnh hưởng nhiều người, nghi ngờ mất an toàn thông tin, máy không thể khởi động hoặc nhân viên không thể đăng nhập vào chính cổng hỗ trợ cũng cần một lối liên hệ khác. Theo hướng dẫn nhận hỗ trợ qua Intune Company Portal của Microsoft, người dùng có thể tra cứu câu trả lời và thông tin liên hệ Helpdesk; khi không truy cập được ứng dụng cổng, họ còn có lựa chọn hỗ trợ qua trang web. Đây là ví dụ về việc duy trì đường hỗ trợ khi kênh chính gặp trở ngại, không phải khuôn mẫu bắt buộc cho mọi doanh nghiệp.

Để chọn phạm vi triển khai đầu tiên, hãy xem lại yêu cầu Helpdesk trong vài tháng gần nhất: việc nào xuất hiện thường xuyên, mất thời gian hỏi đi hỏi lại nhưng có thể hướng dẫn hoặc thu thập thông tin theo một cách nhất quán? Bắt đầu từ nhóm đó sẽ có cơ sở thực tế hơn việc đưa toàn bộ công việc IT lên cổng cùng lúc.

Danh mục dịch vụ cần được thiết kế thế nào để nhân viên chọn đúng yêu cầu?

Danh mục dịch vụ nên gọi tên công việc theo cách nhân viên nhận biết vấn đề, sau đó mới ánh xạ sang nhóm xử lý nội bộ. “Tôi cần cài phần mềm để làm việc” thường dễ chọn hơn một tên biểu mẫu dựa trên mã hệ thống hoặc cơ cấu phòng IT.

Một mục trong danh mục nên trả lời được: yêu cầu này dành cho ai, người gửi cần chuẩn bị gì, ai có quyền phê duyệt, nhóm nào xử lý và nhân viên sẽ nhận cập nhật ở đâu. Tài liệu cách sử dụng danh mục dịch vụ của Microsoft Service Manager cho thấy mỗi loại yêu cầu có thể quy định thông tin cần hỏi và gắn bài kiến thức liên quan. Đây là nguyên tắc thiết kế có thể tham khảo dù doanh nghiệp sử dụng công cụ khác.

Nhóm nhu cầu của nhân viên

Cổng nên cung cấp gì?

Điểm cần quản trị

Chỉ số nên theo dõi

Cài ứng dụng phục vụ công việc

Danh sách ứng dụng được phép, điều kiện sử dụng, biểu mẫu yêu cầu

Giấy phép, quyền phê duyệt, thiết bị phù hợp

Tỷ lệ chọn đúng biểu mẫu; thời gian hoàn tất

Lỗi đăng nhập hoặc tài khoản

Hướng dẫn kiểm tra an toàn và cách liên hệ hỗ trợ

Xác minh danh tính; không thu thập mật khẩu qua biểu mẫu

Tỷ lệ yêu cầu phải hỏi lại; thời gian phản hồi

Cấp thiết bị cho nhân viên mới

Mẫu yêu cầu với ngày bắt đầu, địa điểm và nhu cầu công việc

Người duyệt, tồn kho, trách nhiệm bàn giao

Tỷ lệ yêu cầu đủ thông tin; tỷ lệ bàn giao đúng hạn

Lỗi máy in, mạng hoặc phần mềm

Các bước kiểm tra cơ bản và nút báo sự cố dễ thấy

Phân biệt lỗi cá nhân với sự cố diện rộng

Tỷ lệ tìm được hướng dẫn; số lần chuyển nhóm xử lý

Bảng này là mẫu thiết kế để doanh nghiệp điều chỉnh, không phải danh mục hay mức cam kết dịch vụ mặc định của một nhà cung cấp. Với mỗi mục, chỉ nên hỏi thông tin thực sự giúp xử lý. Biểu mẫu quá dài có thể khiến nhân viên bỏ dở hoặc chuyển sang nhắn tin riêng.

Danh mục dịch vụ chỉ hữu ích khi yêu cầu gửi từ cổng đi tiếp theo một quy trình rõ ràng. Mỗi yêu cầu cần được ghi nhận, phân loại, giao người phụ trách và cập nhật trạng thái cho nhân viên. Quy trình vận hành IT Helpdesk từ lúc nhận ticket đến khi đóng yêu cầu bao gồm chuyển cấp và dùng dữ liệu ticket để cải thiện nội dung hỗ trợ.

Danh mục cũng cần chủ sở hữu nội dung. Khi ứng dụng, quy định cấp quyền hoặc người phê duyệt thay đổi, ai cập nhật mục tương ứng? Nếu thiếu câu trả lời, ngay cả một danh mục được sắp xếp tốt lúc ra mắt cũng có thể nhanh chóng trở nên sai lệch.

Trải nghiệm tìm kiếm cần hoạt động ra sao khi nhân viên chưa biết tên dịch vụ?

Tìm kiếm tốt phải giúp nhân viên đi từ cách họ mô tả vấn đề đến một hướng xử lý rõ ràng. Người dùng có thể gõ “không vào được mail”, “máy in báo lỗi” hoặc “xin thêm quyền”, thay vì tên chính thức của hệ thống hay loại ticket.

Hãy kiểm tra trải nghiệm này bằng các truy vấn thực tế lấy từ yêu cầu hỗ trợ, trao đổi với nhân viên và phản hồi của Helpdesk. Kết quả nên có tiêu đề dễ hiểu, đoạn mô tả ngắn, dấu hiệu nhận biết bài hướng dẫn hay mẫu yêu cầu, cùng ngày cập nhật khi thông tin dễ thay đổi. Nếu nhiều cách gọi cùng chỉ một vấn đề, nội dung và từ khóa tìm kiếm cần phản ánh các cách gọi đó.

Một bài hướng dẫn hữu ích nên nêu điều kiện áp dụng, các bước vừa đủ, dấu hiệu cho thấy thao tác đã thành công và cách gửi yêu cầu nếu chưa giải quyết được. Với những việc có thể gây mất dữ liệu, thay đổi quyền truy cập hoặc tác động đến nhiều người, bài viết cần chỉ rõ thời điểm dừng thao tác và liên hệ IT.

Cũng cần thiết kế trường hợp không có kết quả phù hợp. Một trang trắng hoặc thông báo “không tìm thấy” không giúp nhân viên tiến thêm bước nào. Hãy đưa ra cách gửi yêu cầu chung, kênh báo sự cố khẩn cấp và một ô mô tả vấn đề bằng ngôn ngữ tự nhiên. Theo tài liệu triển khai cổng tự phục vụ Microsoft Service Manager, nút yêu cầu chung cho trường hợp người dùng không tìm được mục thích hợp trong danh mục.

Trước khi chọn công cụ, doanh nghiệp nên yêu cầu xem thử một hành trình hoàn chỉnh: nhân viên tìm bằng từ ngữ thông thường, mở kết quả, gửi yêu cầu và kiểm tra trạng thái. Bản trình diễn đẹp ở trang chủ chưa đủ để đánh giá các bước này.

Làm sao để nhân viên hình thành thói quen sử dụng cổng?

Nhân viên sẽ quay lại cổng khi nó giúp họ tìm được câu trả lời hoặc nhận hỗ trợ dễ hơn kênh họ đang dùng. Truyền thông ra mắt chỉ tạo lượt truy cập ban đầu; trải nghiệm của những lần sử dụng đầu tiên mới quyết định thói quen lâu dài.

Doanh nghiệp có thể bắt đầu với một nhóm nhân viên ở nhiều bộ phận, quan sát họ xử lý vài việc thường gặp rồi sửa nhãn mục, biểu mẫu và bài hướng dẫn trước khi mở rộng. Khi triển khai, hãy giới thiệu cổng theo tình huống cụ thể: “Cần phần mềm mới thì vào đâu?”, “Báo mất thiết bị bằng cách nào?”, “Xem tiến độ yêu cầu ở đâu?”. Một đường dẫn trên trang nội bộ, tài liệu chào đón nhân viên mới và thông báo trong các kênh làm việc thường dùng có thể giúp nhân viên nhớ nơi bắt đầu.

Helpdesk cũng có vai trò trong việc hình thành thói quen. Khi nhận câu hỏi qua điện thoại hoặc tin nhắn, nhân viên hỗ trợ có thể gửi đường dẫn thẳng đến hướng dẫn hoặc biểu mẫu phù hợp, giải thích lợi ích của việc ghi nhận yêu cầu và tiếp tục hỗ trợ người gặp khó khăn. Đừng yêu cầu mọi người “tự lên cổng” trong lúc họ đang mắc kẹt vì một sự cố cần xử lý ngay.

Sau khi ra mắt, nội dung phải được chăm sóc như một phần công việc vận hành: xem các truy vấn không có kết quả, bài được đánh giá chưa hữu ích, biểu mẫu bị bỏ dở và câu hỏi Helpdesk phải trả lời lặp lại. Mỗi tín hiệu có thể chỉ ra một điểm cần sửa trong nội dung hoặc quy trình.

KPI nào cho biết cổng đang được sử dụng hiệu quả?

KPI về mức độ sử dụng nên cho thấy nhân viên có dùng cổng để tiến gần hơn đến cách giải quyết hay không, đồng thời theo dõi chất lượng hỗ trợ sau đó. Lượt truy cập cao, nếu đứng riêng, không chứng minh cổng hữu ích.

Một bộ chỉ số gọn có thể gồm:

  • Tỷ lệ người dùng phù hợp đã sử dụng cổng: Số nhân viên có ít nhất một hành động có ý nghĩa trong kỳ chia cho số nhân viên thuộc phạm vi triển khai. Cần xác định rõ “hành động” là xem hướng dẫn, gửi yêu cầu hay theo dõi ticket.

  • Tỷ lệ tìm kiếm không có kết quả hữu ích: Theo dõi truy vấn không ra kết quả và trường hợp người dùng tìm nhiều lần rồi vẫn phải gửi yêu cầu chung.

  • Tỷ lệ hoàn tất biểu mẫu: So sánh lượt bắt đầu với lượt gửi thành công; xem xét biểu mẫu có tỷ lệ bỏ dở cao.

  • Chất lượng yêu cầu đầu vào: Đo tỷ lệ ticket phải hỏi lại vì thiếu thông tin hoặc chuyển nhóm do chọn sai loại yêu cầu.

  • Chất lượng hỗ trợ: Theo dõi thời gian phản hồi, thời gian xử lý và phản hồi của nhân viên theo loại yêu cầu, bên cạnh mức tuân thủ SLA đã thống nhất.

Ngoài mức độ sử dụng cổng, doanh nghiệp nên xem nhân viên trải nghiệm kết quả hỗ trợ ra sao. Một yêu cầu đạt thời hạn SLA vẫn có thể khiến người dùng phải hỏi lại nhiều lần hoặc không biết tiến độ. Doanh nghiệp có thể tham khảo đánh giá chất lượng IT Helpdesk: từ SLA đến XLA khi muốn đối chiếu chỉ số vận hành với trải nghiệm nhân viên.

Các chỉ số phải được đọc cùng nhau. Chẳng hạn, tỷ lệ tự tìm lời giải tăng nhưng khiếu nại chưa được giải quyết cũng tăng là dấu hiệu cần kiểm tra lại cách đo, chứ chưa thể kết luận cổng thành công. Tương tự, số ticket qua cổng tăng có thể phản ánh nhân viên đã biết kênh tiếp nhận mới; nó không tự chứng minh sự cố IT đang nhiều hơn.

Tài liệu theo dõi mức độ ứng dụng Power Platform của Microsoft khuyến nghị xem xu hướng người dùng hoạt động, cách họ sử dụng tính năng và thu thập phản hồi để tìm rào cản. Với cổng Helpdesk, doanh nghiệp có thể áp dụng nguyên tắc đo lường này theo từng nhóm nhân viên và loại yêu cầu, rồi đối chiếu với dữ liệu xử lý ticket.

Doanh nghiệp cần làm gì trước khi tự triển khai hoặc thuê đơn vị vận hành?

Quyết định nên dựa trên trách nhiệm vận hành cổng và Helpdesk, không chỉ dựa trên danh sách tính năng. Dù tự triển khai hay thuê ngoài, doanh nghiệp vẫn cần xác định ai sở hữu quy trình, dữ liệu, nội dung hướng dẫn và trải nghiệm của nhân viên.

Khi trao đổi với nhà cung cấp hoặc đội triển khai, hãy yêu cầu câu trả lời cụ thể cho những câu hỏi sau:

  1. Ai xây dựng và cập nhật danh mục dịch vụ? Khi quy định nội bộ đổi, việc sửa biểu mẫu, hướng dẫn và tuyến xử lý được thực hiện thế nào?

  2. Cổng liên kết với ticket ra sao? Nhân viên có nhận được mã yêu cầu, trạng thái và thông báo khi cần bổ sung thông tin không? Yêu cầu qua email hoặc điện thoại có được ghi nhận tập trung không?

  3. Phê duyệt và chuyển cấp được phân định thế nào? Ai quyết định cấp quyền, ai xử lý kỹ thuật, ai tiếp nhận sự cố vượt phạm vi hỗ trợ ban đầu?

  4. Dữ liệu được bảo vệ ra sao? Cần xem quyền truy cập, thông tin nào biểu mẫu được phép thu thập, thời gian lưu và trách nhiệm của mỗi bên theo chính sách doanh nghiệp.

  5. Đo và cải thiện mức độ sử dụng bằng cách nào? Báo cáo có chỉ ra truy vấn thất bại, mục ít dùng, biểu mẫu bị bỏ dở và yêu cầu bị chuyển sai nhóm không?

  6. Nhân viên liên hệ ai khi không thể dùng cổng? Kênh thay thế và quy trình xử lý sự cố khẩn cấp phải rõ ràng.

Việc tiếp nhận, theo dõi và xử lý yêu cầu cần gắn với danh mục dịch vụ và quy trình Helpdesk. Theo tài liệu quản lý yêu cầu dịch vụ trong Microsoft Service Manager, yêu cầu có thể được tạo qua cổng, email hoặc được nhân viên Helpdesk nhập khi người dùng gọi điện. Các tuyến tiếp nhận này đều cần được quản lý như công việc hỗ trợ.

Nếu doanh nghiệp đã có đội IT nội bộ, câu hỏi cần giải quyết là phân công để đội hiện tại và đối tác phối hợp hiệu quả. Khi đánh giá phương án, hãy yêu cầu phạm vi hỗ trợ và mức dịch vụ được ghi rõ trong thỏa thuận cụ thể.

Cổng self-service IT Helpdesk chỉ phát huy giá trị khi nhân viên tìm được đúng việc cần làm và biết rằng sẽ có người tiếp nhận khi họ không tự giải quyết được. Hãy dùng hành trình thực tế của nhân viên, chất lượng ticket và phản hồi sau hỗ trợ làm tiêu chí lựa chọn, rồi cải thiện danh mục và nội dung theo dữ liệu sử dụng.

IPSIP Việt Nam có thể đồng hành cùng doanh nghiệp xây dựng trải nghiệm hỗ trợ IT hiệu quả hơn như thế nào?

Một cổng tự phục vụ dễ dùng là điểm khởi đầu, phía sau vẫn cần đội ngũ tiếp nhận, xử lý và cập nhật tiến độ khi nhân viên không thể tự giải quyết. Dịch vụ IT Helpdesk của IPSIP Việt Nam vận hành đầu mối hỗ trợ hoặc phối hợp với đội IT nội bộ. Phạm vi hỗ trợ bao gồm các nhu cầu thường ngày về tài khoản, thiết bị, phần mềm và kết nối mạng, với yêu cầu được ghi nhận và theo dõi theo SLA đã thống nhất.

ipsip-viet-nam
IPSIP Việt Nam cung cấp dịch vụ IT Helpdesk trọn gói, đồng hành cùng doanh nghiệp xây dựng hạ tầng tối ưu

Nếu đang cân nhắc một cổng self-service IT Helpdesk, doanh nghiệp có thể bắt đầu bằng cách tham khảo những Checklist/Mẫu đánh giá để xác định những yêu cầu nên đưa lên cổng, ai phụ trách nội dung và sẽ đo mức độ sử dụng ra sao. Bên cạnh đó, hình dung rõ hơn công việc phía sau cổng qua bài viết IT Support hỗ trợ doanh nghiệp những gì. Khi đã có những yêu cầu ban đầu, liên hệ ngay dịch vụ IT Helpdesk của IPSIP và đặt lịch tư vấn để trao đổi về cách phối hợp với IT nội bộ, quy trình xử lý ticket và phạm vi SLA phù hợp.


Tham khảo

Microsoft Learn, Use the service catalog

Microsoft Learn, Manage service requests

Bình luận


theo dõi ipsip việt nam trên google news.png
conact-ipsip-vietnam
zalo
đặt lịch hẹn
bottom of page