Phân loại ticket IT Helpdesk: Incident, Service Request, Problem và Change khác nhau thế nào?

10 giờ trước

9 phút đọc

Một nhân viên báo “Outlook không gửi được email”, một người khác yêu cầu cấp tài khoản Microsoft 365, trong khi hệ thống Wi-Fi văn phòng liên tục mất kết nối mỗi tuần. Cả ba trường hợp đều có thể đi qua IT Helpdesk, nhưng không nên được xử lý như cùng một loại ticket.

Trong thực tế vận hành IT, Incident, Service Request, Problem và Change khác nhau chủ yếu ở mục tiêu xử lý: Incident tập trung khôi phục một dịch vụ đang bị gián đoạn hoặc suy giảm. Service Request đáp ứng một yêu cầu dịch vụ được xác định trước từ người dùng. Problem tập trung tìm và quản lý nguyên nhân của một hoặc nhiều Incident. Change kiểm soát việc thay đổi sản phẩm, dịch vụ hoặc thành phần IT nhằm tạo ra trạng thái mới với mức rủi ro được quản lý.

incident-service-request-problem-va-change-khac-nhau — Incident, Service Request, Problem và Change khác nhau như thế nào?

ITIL 4 cũng quản lý Incident Management, Service Request Management, Problem Management và Change Enablement như các practice riêng. Vì vậy, dù doanh nghiệp thường gọi chung chúng là “ticket”, không nên hiểu rằng bốn khái niệm này luôn là bốn loại record hoàn toàn giống nhau trong mọi hệ thống ITSM.

Incident, Service Request, Problem và Change khác nhau ở đâu?

Cách dễ nhất để phân biệt là hỏi: "Đội IT đang cố đạt kết quả gì với record này?"

Loại	Câu hỏi nhận diện	Mục tiêu chính	Ví dụ
Incident	Có dịch vụ đang bị lỗi, gián đoạn hoặc hoạt động không như mong đợi?	Khôi phục hoạt động bình thường càng sớm càng phù hợp	Outlook đột nhiên không gửi email
Service Request	Người dùng đang yêu cầu một dịch vụ, thông tin hoặc quyền truy cập đã được xác định trước?	Thực hiện yêu cầu theo quy trình chuẩn	Nhân viên mới cần tài khoản Microsoft 365
Problem	Có cần tìm hoặc quản lý nguyên nhân của một hay nhiều Incident?	Giảm khả năng Incident tái diễn hoặc giảm tác động	Wi-Fi tầng 3 mất kết nối nhiều lần mỗi tuần
Change	Có cần thay đổi có kiểm soát đối với hệ thống hoặc dịch vụ?	Thực hiện thay đổi với rủi ro được đánh giá và quản lý	Nâng cấp firmware Access Point để xử lý lỗi

PeopleCert mô tả:

Incident Management với vai trò khôi phục hoạt động dịch vụ bình thường nhanh chóng sau gián đoạn.
Service Request Management xử lý các yêu cầu được xác định trước và do người dùng khởi tạo.
Problem Management hướng tới giảm khả năng và tác động của Incident bằng cách xác định nguyên nhân thực tế hoặc tiềm năng, đồng thời quản lý workaround và known error.
Change Enablement tập trung tăng tỷ lệ thay đổi thành công thông qua đánh giá rủi ro, phê duyệt và quản lý lịch thay đổi.

Điểm quan trọng là cùng một vấn đề kinh doanh có thể tạo ra nhiều record liên quan, thay vì phải chọn duy nhất một trong bốn loại.

Ví dụ, 20 nhân viên không kết nối được Wi-Fi có thể tạo một Incident để khôi phục dịch vụ. Nếu tình trạng này tái diễn, đội IT có thể mở Problem để tìm nguyên nhân. Khi xác định firmware của Access Point cần nâng cấp, một Change tiếp tục được tạo để kiểm soát việc thay đổi.

Incident không tự động “biến thành” Problem hay Change. Chúng có thể tồn tại song song và liên kết với nhau.

Cách nhận diện đúng loại ticket bằng 4 câu hỏi

Khi nhận yêu cầu, Helpdesk có thể sử dụng một logic đơn giản.

Câu hỏi thứ nhất: Có thứ gì đang hoạt động nhưng hiện bị hỏng, gián đoạn hoặc suy giảm không?
Nếu có, trước tiên hãy nghĩ đến Incident. Ví dụ nhân viên không đăng nhập được ERP dù trước đó vẫn sử dụng bình thường, máy in phòng kế toán ngừng hoạt động hoặc kết nối Internet bị mất.
Câu hỏi thứ hai: Không có sự cố, người dùng chỉ đang cần một dịch vụ chuẩn?
Trường hợp này thường là Service Request. Ví dụ cấp tài khoản cho nhân viên mới, yêu cầu cài một phần mềm đã được phê duyệt hoặc xin quyền truy cập vào thư mục dùng chung.
Câu hỏi thứ ba: Mục tiêu hiện tại có phải tìm hiểu tại sao một hoặc nhiều Incident xảy ra hoặc tái diễn hay không?
Nếu có, đó là phạm vi của Problem. Problem không nhất thiết đồng nghĩa với “sự cố nghiêm trọng hơn”. Một Incident mức độ cao vẫn là Incident nếu mục tiêu trước mắt là khôi phục dịch vụ.
Câu hỏi thứ tư: Có cần thay đổi cấu hình, hạ tầng, ứng dụng hoặc một thành phần dịch vụ theo cách phải đánh giá và kiểm soát rủi ro?
Khi đó cần xem xét Change.

Cách tiếp cận này hữu ích hơn việc phân loại chỉ dựa trên từ khóa trong mô tả. Một ticket ghi “cài phần mềm” chẳng hạn, có thể là Service Request nếu đây là ứng dụng chuẩn đã được duyệt. Nhưng việc triển khai phiên bản mới của phần mềm nghiệp vụ lên toàn công ty có thể cần Change vì phạm vi, rủi ro và cách phê duyệt hoàn toàn khác.

Ticket khác email hoặc chat như thế nào?

Email, điện thoại và chat có thể là kênh tiếp nhận yêu cầu. Ticket là record dùng để quản lý công việc.

Sự khác biệt trở nên rõ khi doanh nghiệp có nhiều người dùng và nhiều kỹ thuật viên. Một tin nhắn "máy em không vào mạng, anh xem giúp" trên chat có thể đủ để bắt đầu trao đổi, nhưng thường không cho biết ticket thuộc loại nào, ai đang chịu trách nhiệm, mức độ ảnh hưởng ra sao, đã xử lý đến đâu và khi nào yêu cầu được hoàn tất.

Một ticket có cấu trúc giữ những thông tin này trong cùng một record, cho phép Helpdesk phân loại, chuyển người xử lý, theo dõi trạng thái và tạo dữ liệu phục vụ báo cáo.

Đây cũng là lý do mô hình IT Helpdesk và IT Support cho doanh nghiệp thường sử dụng hệ thống ticket thay vì phụ thuộc hoàn toàn vào email hoặc tin nhắn cá nhân.

IT Support là gì? Vai trò, công việc và checklist cho doanh nghiệp

Điều này không có nghĩa doanh nghiệp phải loại bỏ email hoặc chat. Một thiết kế Helpdesk tốt có thể cho phép người dùng tiếp tục gửi email hoặc liên hệ qua kênh thuận tiện, nhưng phía sau nên chuyển yêu cầu thành record có cấu trúc để tránh thất lạc thông tin và khó truy vết.

Một ticket IT Helpdesk cần những trường dữ liệu nào?

Không cần xây một form quá dài ngay từ đầu. Mục tiêu là thu thập đủ dữ liệu để hiểu yêu cầu, phân loại, ưu tiên, giao người xử lý và theo dõi kết quả.

Một ticket tối thiểu nên có:

Requester: Ai là người gửi yêu cầu?
Ticket Type: Incident, Service Request, Problem hay Change?
Service/Category: Dịch vụ hoặc hệ thống nào liên quan?
Summary: Mô tả ngắn vấn đề hoặc yêu cầu.
Description: Thông tin chi tiết về tình huống.
Impact: Bao nhiêu người hoặc hoạt động kinh doanh bị ảnh hưởng?
Urgency/Priority: Mức độ cần xử lý.
Assignee/Owner: Cá nhân hoặc nhóm chịu trách nhiệm.
Status: Ticket đang ở giai đoạn nào?
Created Time: Ticket được ghi nhận khi nào?

Khi hệ thống trưởng thành hơn, doanh nghiệp có thể bổ sung Asset hoặc Configuration Item liên quan, địa điểm, ticket cha/con, Problem liên quan, Change liên quan, mã resolution, nguyên nhân gốc, workaround và các mốc thời gian phục vụ SLA.

Ví dụ, thay vì chỉ ghi:

“Không vào được Wi-Fi.”

Một ticket có cấu trúc tốt hơn có thể là:

Type: Incident
Service: Corporate Wi-Fi
Requester: Nguyễn A – Phòng Kế toán
Location: Tầng 3
Affected scope: 8 người dùng
Started: 09:15
Description: Thiết bị kết nối được SSID nhưng không nhận IP
Business impact: Không truy cập ERP nội bộ
Priority: Xác định theo impact và urgency
Status: New
Assignee: Network Support

Nhìn vào mẫu này, kỹ thuật viên không chỉ biết “Wi-Fi đang lỗi” mà còn biết ai bị ảnh hưởng, phạm vi bao nhiêu, dịch vụ nào liên quan, mức độ tác động và ai đang chịu trách nhiệm xử lý.

ticket-it-helpdesk — Ticket IT Helpdesk với đầy đủ thông tin

Các trường liên quan đến response time, resolution time và cam kết dịch vụ cần được thiết kế cùng cơ chế SLA IT Helpdesk, thay vì chỉ gắn một nhãn “gấp” cho mọi yêu cầu.

Trạng thái vòng đời không nên giống nhau cho mọi loại ticket

Nếu bốn loại record có mục tiêu khác nhau, workflow của chúng cũng không nhất thiết giống nhau.

Một Incident có thể đi từ New → Assigned → In Progress → Resolved → Closed, vì mục tiêu chính là xử lý gián đoạn và khôi phục dịch vụ.
Một Service Request có thể cần Submitted → Approved → Fulfilment → Completed nếu yêu cầu cần bước phê duyệt trước khi thực hiện.
Một Problem thường cần nhiều thời gian điều tra hơn, chẳng hạn Identified → Investigation → Workaround/Known Error → Resolved.
Trong khi đó, một Change có thể cần Proposed → Assessment → Approval → Scheduled → Implemented → Review/Closed để bảo đảm rủi ro và thời điểm triển khai được kiểm soát.

Đây chỉ là mô hình tham khảo, không phải bộ status bắt buộc. Doanh nghiệp có thể đặt tên trạng thái khác tùy công cụ và quy trình. Điều cần giữ là vòng đời phải phản ánh mục tiêu thực sự của record, thay vì bắt mọi công việc IT đi qua cùng một chuỗi trạng thái.

Ticket tốt và ticket xấu khác nhau thế nào?

Một ticket xấu thường không sai vì thiếu thuật ngữ kỹ thuật. Nó kém chất lượng vì người tiếp nhận không có đủ dữ liệu để đưa ra quyết định.

Ví dụ: “Máy không vào mạng, xử lý giúp gấp.”

Người xử lý chưa biết máy nào, người dùng nào, đang ở đâu, Ethernet hay Wi-Fi, lỗi bắt đầu khi nào, một hay nhiều người bị ảnh hưởng và công việc nào đang bị gián đoạn.

Một ticket tốt có thể đơn giản hơn nhiều nhưng đủ cấu trúc:

“Incident – Laptop FIN-023 tại tầng 3 không truy cập được Wi-Fi Corporate từ 9:15. Ba máy gần đó có cùng tình trạng. Thiết bị vẫn thấy SSID nhưng không nhận địa chỉ IP. Người dùng không truy cập được ERP nội bộ. Đã thử tắt/bật Wi-Fi nhưng lỗi vẫn còn.”

Không cần người dùng cuối biết ITIL để viết được ticket như vậy. Form, category và cách đội Helpdesk đặt câu hỏi mới là yếu tố giúp dữ liệu trở nên đầy đủ.

Một lỗi phân loại thường gặp khác là gọi mọi sự cố tái diễn là Problem ngay từ khi người dùng báo lỗi. Yêu cầu “Internet tầng 2 đang mất” trước hết vẫn có thể là Incident vì mục tiêu tức thời là khôi phục kết nối. Problem được mở khi tổ chức cần quản lý việc điều tra nguyên nhân thực tế hoặc tiềm năng và giảm khả năng sự cố tiếp tục xảy ra.

Checklist áp dụng phân loại ticket IT Helpdesk

Doanh nghiệp không cần triển khai một hệ thống ITSM phức tạp ngay từ đầu. Có thể bắt đầu với tám điểm:

Thống nhất định nghĩa Incident, Service Request, Problem và Change.
Viết một câu hỏi nhận diện rõ cho từng loại.
Biến Ticket Type thành trường dữ liệu có kiểm soát.
Xác định ai được phép tạo hoặc quản lý Problem và Change.
Cho phép liên kết Incident với Problem và Change liên quan.
Chuẩn hóa các field tối thiểu về requester, service, impact, owner và status.
Thiết kế lifecycle phù hợp với từng loại record.
Đào tạo đội Helpdesk bằng các case thực tế của doanh nghiệp thay vì chỉ học định nghĩa.

Các nguyên tắc này có thể áp dụng cho Helpdesk nội bộ, thuê ngoài hoặc mô hình kết hợp. Khác biệt nằm ở trách nhiệm, phạm vi hỗ trợ và cách phối hợp giữa các bên.

Nếu doanh nghiệp đang cân nhắc mô hình tổ chức, có thể tham khảo thêm phân tích về IT nội bộ và IT Helpdesk thuê ngoài.

Phân biệt Incident, Service Request, Problem và Change không phải để đội IT sử dụng nhiều thuật ngữ hơn. Mục đích thực tế là giúp mỗi yêu cầu đi đúng workflow, có đúng người chịu trách nhiệm, dữ liệu phù hợp và cơ chế kiểm soát cần thiết.

Doanh nghiệp muốn xây một đầu mối tiếp nhận, phân loại và theo dõi yêu cầu IT có cấu trúc?

Xem phạm vi dịch vụ, mô hình hỗ trợ, SLA và bảng giá tham khảo của IPSIP tại Dịch vụ IT Helpdesk và IT Support cho doanh nghiệp

XEM NGAY