Checklist bàn giao ca IT Helpdesk để không thất lạc ticket quan trọng

7 giờ trước

9 phút đọc

Một ca IT Helpdesk kết thúc không có nghĩa là các ticket đang xử lý cũng đã hoàn thành. Nếu thông tin quan trọng chỉ nằm trong cuộc gọi, cửa sổ chat hoặc trí nhớ của kỹ thuật viên, ca tiếp theo có thể nhìn thấy ticket nhưng không biết chính xác phải làm gì tiếp theo.

Một bản bàn giao ca IT Helpdesk hiệu quả phải giúp người tiếp nhận trả lời được ngay 5 câu hỏi: Ticket quan trọng nào đang mở? Đã thực hiện những gì? Bước tiếp theo là gì? Ai chịu trách nhiệm? và Có SLA hoặc mốc thời gian nào sắp đến hạn?

Vì vậy, bàn giao ca IT Helpdesk không nên chỉ là gửi danh sách ticket chưa đóng. Đó phải là quá trình chuyển giao đủ ngữ cảnh để ca tiếp theo có thể tiếp tục công việc mà không phải điều tra lại từ đầu.

Điều này đặc biệt quan trọng với doanh nghiệp tổ chức IT Support theo nhiều ca, hỗ trợ ngoài giờ hoặc có nhiều nhóm cùng tham gia xử lý. Trong một mô hình IT Support cho doanh nghiệp, ticket đóng vai trò là đầu mối ghi nhận và theo dõi công việc; còn handover giúp duy trì tính liên tục khi người phụ trách thay đổi.

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

Khi nào một ca IT Helpdesk cần bàn giao?

Không phải mọi ticket đều cần một buổi bàn giao dài. Một yêu cầu đã hoàn thành, có lịch sử xử lý đầy đủ và không còn hành động tiếp theo thường chỉ cần được đóng đúng quy trình.

Bàn giao trở nên quan trọng khi công việc vẫn tiếp tục sau thời điểm người đang xử lý kết thúc ca.

Các trường hợp nên được đưa vào handover gồm:

Ticket chưa hoàn thành khi kết thúc ca.
Ticket có mức ưu tiên cao như P1 hoặc P2.
Sự cố đang ảnh hưởng đến nhiều người dùng hoặc một hệ thống quan trọng.
Ticket đang chờ phản hồi từ người dùng, vendor hoặc nhóm kỹ thuật khác.
Đã có workaround tạm thời nhưng nguyên nhân chưa được xử lý dứt điểm.
Có lịch bảo trì hoặc thay đổi hệ thống diễn ra trong ca kế tiếp.
Có tác vụ cần thực hiện tại một thời điểm cụ thể.
Ticket sắp chạm ngưỡng phản hồi, xử lý hoặc escalation theo SLA.
Có quyền truy cập, phê duyệt hoặc thông tin từ bên thứ ba đang chờ xử lý.

Một nguyên tắc đơn giản là: nếu ca sau có khả năng phải hành động trước khi người xử lý hiện tại quay lại làm việc, ticket đó nên được bàn giao rõ ràng.

ban-giao-ca-it-helpdesk — Bàn giao ca IT Helpdesk cần đảm bảo nội dung nào?

Tài liệu Shift Handover của ServiceNow cập nhật ngày 12/3/2026 cũng sử dụng một cấu trúc tương tự, gồm các incident/sự kiện quan trọng trong ca, vấn đề cần tiếp tục theo dõi, cập nhật hệ thống, bước tiếp theo và tài liệu tham chiếu. Báo cáo sau đó được chuyển cho Shift Owner và đội trực tiếp theo.

Nội dung bàn giao ca IT Helpdesk phải có những thông tin gì?

Điểm khó của handover không nằm ở việc ghi thật nhiều thông tin. Mục tiêu là ghi đủ thông tin để người khác tiếp tục xử lý mà không phải đoán.

Mỗi ticket cần bàn giao nên có ít nhất 5 nhóm thông tin sau.

1. Nhận diện ticket và mức độ ưu tiên

Ghi rõ:

Ticket ID.
Priority.
Người dùng hoặc bộ phận bị ảnh hưởng.
Hệ thống, ứng dụng hoặc thiết bị liên quan.

Ticket ID giúp người nhận truy cập ngay lịch sử đầy đủ thay vì phải tìm kiếm từ nội dung mô tả thủ công.

Priority giúp ca tiếp theo biết ticket nào phải xử lý trước.

2. Trạng thái hiện tại

Không nên chỉ ghi “đang xử lý”.

Ca tiếp theo cần biết tình trạng cụ thể, chẳng hạn:

Người dùng hiện còn bị ảnh hưởng hay không?
Dịch vụ đã được phục hồi một phần hay toàn bộ?
Workaround đang hoạt động không?
Sự cố có đang tiếp tục mở rộng không?
Đang chờ điều kiện nào để tiếp tục?

Một câu mô tả trạng thái tốt phải cho người đọc hiểu vấn đề đang đứng ở đâu tại thời điểm bàn giao.

3. Những gì đã thực hiện

Liệt kê ngắn các bước quan trọng đã thử và kết quả.

Ví dụ:

Đã restart service nhưng lỗi vẫn tái diễn.
Đã kiểm tra kết nối LAN, chưa phát hiện mất kết nối.
Đã cấp workaround tạm thời cho người dùng.
Đã chuyển log cho vendor và đang chờ phản hồi.

Phần này giúp ca sau tránh lặp lại troubleshooting đã hoàn thành.

Không cần copy toàn bộ lịch sử ticket vào handover nếu thông tin đã nằm trên hệ thống. Chỉ giữ những hành động có ảnh hưởng đến quyết định tiếp theo.

4. Next action và owner

Đây là phần quan trọng nhất.

Mỗi ticket nên thể hiện rõ:

Việc tiếp theo là gì – ai thực hiện – khi nào cần thực hiện.

Ví dụ:

09:00 kiểm tra phản hồi của ISP. Nếu đường truyền chưa phục hồi, gọi đầu mối escalation của nhà mạng và cập nhật ticket INC-2458.

Cách ghi này hữu ích hơn nhiều so với:

Tiếp tục theo dõi mạng.

Nếu không xác định được next action, ca nhận rất dễ phải tự đọc lại toàn bộ ticket rồi quyết định từ đầu.

5. Dependency và mốc thời gian

Ghi rõ ticket đang phụ thuộc vào:

User.
Vendor.
Nhà cung cấp Internet.
Nhóm Infrastructure.
Security.
Application team.
Approval từ quản lý.
Thời gian maintenance.
Một thay đổi hệ thống khác.

Nếu có deadline hoặc SLA, phải ghi cùng trạng thái hiện tại.

Ticket P1 và major incident cần được bàn giao thế nào?

Ticket thông thường có thể bàn giao bằng một dòng đủ ngữ cảnh. P1 hoặc major incident cần chặt chẽ hơn vì khoảng trống thông tin giữa hai ca có thể làm chậm phản ứng trong thời điểm hệ thống vẫn đang bị ảnh hưởng.

Bản handover cho một sự cố nghiêm trọng nên nêu rõ:

Business impact: hệ thống nào bị ảnh hưởng, phạm vi người dùng và tình trạng dịch vụ hiện tại.
Incident owner: ai đang điều phối sự cố.
Timeline chính: sự cố bắt đầu khi nào và các mốc xử lý quan trọng.
Actions taken: những gì đã kiểm tra hoặc thay đổi.
Workaround: có giải pháp tạm thời hay chưa và còn hiệu lực không.
Teams involved: nhóm nội bộ, vendor hoặc bên thứ ba đang tham gia.
Next action: hành động mà ca nhận phải thực hiện tiếp.
Next update: thời điểm phải cập nhật lại cho stakeholder.
SLA/escalation: mốc nào đang đến gần hoặc đã được kích hoạt.
Rủi ro: thao tác nào không nên lặp lại hoặc điều kiện nào cần kiểm tra trước khi thay đổi hệ thống.

Với các ticket ưu tiên cao, việc bàn giao và theo dõi SLA IT Helpdesk cần đi cùng nhau. Ca nhận không chỉ cần biết ticket chưa đóng mà còn cần biết còn bao nhiêu thời gian trước mốc phản hồi, cập nhật hoặc escalation tiếp theo.

Ngoài ticket, nên có một cuộc trao đổi trực tiếp ngắn giữa người giao và người nhận đối với incident nghiêm trọng. Mục tiêu không phải đọc lại toàn bộ ticket, mà để xác nhận người nhận đã hiểu impact, trạng thái và hành động tiếp theo.

SLA IT Helpdesk: Nền tảng cho Uptime 99.9% và vận hành không gián đoạn

Đừng bỏ sót Change và quyền truy cập khi đổi ca

Một lỗi phổ biến là handover chỉ tập trung vào ticket hỗ trợ người dùng trong khi các thay đổi hệ thống đang diễn ra lại không được chuyển giao đầy đủ.

Change hoặc Maintenance đang mở

Nếu một thay đổi kéo dài qua nhiều ca, bản bàn giao nên ghi:

Change ID.
Hệ thống bị tác động.
Thời gian triển khai.
Tình trạng hiện tại.
Kết quả mong đợi.
Bước còn lại.
Người phê duyệt hoặc owner.
Điều kiện rollback.
Đầu mối escalation nếu có vấn đề.

Ví dụ, ca trước vừa triển khai cập nhật ứng dụng lúc 22:00 và cần theo dõi đến 02:00. Ca đêm phải biết tiêu chí nào được xem là bất thường và khi nào cần rollback, thay vì chỉ nhận thông báo “đã deploy xong”.

Quyền truy cập và credential

Handover cũng không nên trở thành nơi lưu mật khẩu.

Không ghi password, API key hoặc thông tin xác thực nhạy cảm trực tiếp vào file checklist, email hoặc nhóm chat bàn giao.

Thay vào đó, chỉ nên ghi:

Quyền nào đang cần.
Ai đã được cấp quyền.
Yêu cầu đang chờ approval hay đã hoàn thành.
Tài khoản hoặc hệ thống nào liên quan.
Người chịu trách nhiệm phê duyệt.
Nơi lưu credential được doanh nghiệp phê duyệt, nếu ca tiếp theo cần sử dụng.

Trong mô hình phối hợp giữa nhiều đội, trách nhiệm cũng cần được xác định trước. Khi doanh nghiệp vừa có nhân sự nội bộ vừa sử dụng đơn vị hỗ trợ bên ngoài, nên phân định rõ ai tiếp nhận, ai xử lý và trường hợp nào cần escalation. Doanh nghiệp có thể tham khảo bài viết Thuê ngoài dịch vụ IT hay tự vận hành IT nội bộ: Doanh nghiệp nên chọn mô hình nào? của IPSIP Việt Nam để có thêm thông tin.

Mẫu checklist bàn giao ca IT Helpdesk

Doanh nghiệp có thể dùng mẫu dưới đây làm cấu trúc ban đầu và tùy chỉnh theo ticketing system, SLA và quy trình escalation đang sử dụng.

Hạng mục	Thông tin cần ghi
Thời gian bàn giao	Ngày, giờ bắt đầu/kết thúc handover
Người bàn giao	Tên hoặc nhóm trực hiện tại
Người nhận	Tên hoặc nhóm trực tiếp theo
Ticket ID	Mã ticket/incident/change
Priority	P1, P2, P3 hoặc mức ưu tiên nội bộ
Impact	User, bộ phận, hệ thống bị ảnh hưởng
Current status	Trạng thái tại thời điểm bàn giao
Actions taken	Các bước quan trọng đã thực hiện
Workaround	Có/không, trạng thái hiện tại
Next action	Việc ca sau phải thực hiện
Owner	Người hoặc team chịu trách nhiệm
SLA/deadline	Mốc phản hồi, cập nhật hoặc xử lý
Dependency	User, vendor, ISP hoặc team khác
Change/Maintenance	Thay đổi liên quan đang diễn ra
Access/Approval	Quyền hoặc phê duyệt đang chờ
Escalation	Đã chuyển cấp cho ai, khi nào
Notes/Risk	Lưu ý đặc biệt cho ca tiếp theo

Trước khi kết thúc bàn giao, người giao có thể kiểm tra nhanh 5 điểm:

Có ticket P1/P2 nào chưa xuất hiện trong handover không?
Mỗi ticket quan trọng đã có next action rõ ràng chưa?
Đã xác định owner của ca tiếp theo chưa?
Có SLA, maintenance hoặc deadline nào xảy ra trong ca tiếp theo không?
Có thông tin nhạy cảm nào đang được lưu sai nơi không?

Nếu 5 câu hỏi đều có câu trả lời rõ ràng, ca nhận có thể bắt đầu công việc mà không phải tái dựng lại bối cảnh.

Từ checklist bàn giao đến quy trình IT Helpdesk liên tục

Checklist không thể thay thế một quy trình Helpdesk tốt.

Nếu ticket được gửi qua nhiều kênh riêng lẻ, priority không thống nhất hoặc không xác định ai chịu trách nhiệm, ngay cả một mẫu handover chi tiết cũng khó ngăn việc bỏ sót công việc.

Một mô hình vận hành ổn định thường cần kết hợp:

Một hệ thống ticket tập trung.
Priority thống nhất.
Trạng thái ticket rõ ràng.
Owner và escalation path.
SLA phù hợp với mức độ ảnh hưởng.
Quy trình change và access control.
Handover giữa các ca khi công việc chưa hoàn thành.

Mô hình dịch vụ IT Helpdesk & IT Support của IPSIP Việt Nam tiếp nhận yêu cầu qua ticket, phân loại theo mức ưu tiên, theo dõi SLA và có thể vận hành toàn bộ Helpdesk hoặc phối hợp với đội IT nội bộ. Phạm vi hỗ trợ có thể bao gồm giờ hành chính, ngoài giờ hoặc 24/7 tùy mô hình dịch vụ đã thống nhất.

ipsip-vietnam — IPSIP Việt Nam - Giải pháp An ninh mạng hơn 15 năm kinh nghiệm từ châu Âu

Tham khảo ngay

Điểm quan trọng không nằm ở việc có bao nhiêu người trực, mà ở khả năng chuyển công việc từ người này sang người khác mà không làm mất bối cảnh, trách nhiệm và thời hạn xử lý.

Doanh nghiệp có thể bắt đầu bằng mẫu checklist trong bài viết này, sau đó chuẩn hóa các trường tương ứng trong ticketing system để giảm phụ thuộc vào email, chat hoặc ghi nhớ cá nhân.

Nguồn tham khảo