Tóm tắt nhanh: Mẫu SLA IT Support cho doanh nghiệp nên quy định rõ mức ưu tiên P1/P2/P3/P4, thời gian phản hồi, thời gian xử lý mục tiêu, kênh tiếp nhận, phạm vi bao gồm/không bao gồm, điều kiện loại trừ SLA, cách escalation, báo cáo tháng và tiêu chí nghiệm thu. SLA tốt không chỉ là “hỗ trợ nhanh”, mà là cam kết đo được và có dữ liệu để cải tiến.
Mẫu SLA IT Support nên có những mục nào?
Nên có 9 mục: phạm vi hỗ trợ, đối tượng áp dụng, mức ưu tiên, thời gian phản hồi, thời gian xử lý mục tiêu, kênh báo lỗi, escalation, báo cáo nghiệm thu và điều kiện loại trừ. Nếu thiếu một trong các mục này, doanh nghiệp rất dễ hiểu nhầm “đã phản hồi” là “đã xử lý xong”.
Bài này là mẫu thực hành, bổ sung cho bài giải thích SLA IT Support là gì và phù hợp khi doanh nghiệp đang chọn hoặc đàm phán dịch vụ IT Support.
Vì sao doanh nghiệp cần SLA thay vì chỉ gọi hỗ trợ khi có lỗi?
Nếu không có SLA, mỗi bên sẽ hiểu “nhanh” theo một cách khác nhau. Người dùng muốn xử lý ngay, quản lý muốn không gián đoạn vận hành, còn đội kỹ thuật cần phân loại mức độ ưu tiên. SLA giúp thống nhất ngôn ngữ: lỗi nào là khẩn cấp, lỗi nào xử lý trong ngày, lỗi nào lên lịch, ai có quyền xác nhận hoàn tất và báo cáo chất lượng ra sao.
Với doanh nghiệp có nhiều người dùng, nhiều chi nhánh hoặc hệ thống email/server/firewall, SLA giúp tránh tình trạng mọi yêu cầu đều được xem là gấp. Khi mọi thứ đều khẩn cấp, thực ra không có gì được ưu tiên đúng. SLA tốt giúp tập trung nguồn lực vào sự cố ảnh hưởng vận hành trước, đồng thời vẫn quản lý các yêu cầu nhỏ bằng ticket và báo cáo.
Bảng mẫu mức ưu tiên SLA IT Support
| Mức ưu tiên | Ví dụ sự cố | Phản hồi mục tiêu | Xử lý mục tiêu | Ghi chú vận hành |
|---|---|---|---|---|
| P1 – Khẩn cấp | Mất mạng toàn công ty/chi nhánh, server/email dùng chung ngưng, sự cố bảo mật nghiêm trọng | 15-30 phút | 2-4 giờ hoặc theo hiện trường | Cập nhật liên tục đến khi ổn định |
| P2 – Cao | Một phòng ban bị ảnh hưởng, nhiều máy không dùng được, máy in/kho/POS gián đoạn | 30-60 phút | Trong ngày làm việc | Có hướng xử lý tạm nếu chưa xong |
| P3 – Trung bình | Một người dùng, một máy, lỗi phần mềm văn phòng, yêu cầu cấu hình thông thường | 2-4 giờ làm việc | 1-2 ngày làm việc | Xử lý theo hàng đợi |
| P4 – Thấp | Tư vấn, cài đặt không gấp, yêu cầu thay đổi nhỏ | 1 ngày làm việc | Theo lịch đã thống nhất | Gom theo đợt để tối ưu chi phí |
Phân biệt thời gian phản hồi và thời gian xử lý
Nhiều hợp đồng IT Support bị mơ hồ vì chỉ ghi “hỗ trợ trong 30 phút”. Doanh nghiệp cần tách hai khái niệm. Thời gian phản hồi là lúc đội IT xác nhận đã nhận yêu cầu, phân loại và bắt đầu xử lý. Thời gian xử lý là thời gian để khôi phục dịch vụ, xử lý tạm hoặc hoàn tất yêu cầu tùy mức độ.
Ví dụ, sự cố mất internet toàn chi nhánh có thể phản hồi trong 15 phút, nhưng xử lý phụ thuộc nhà mạng, thiết bị, onsite và linh kiện. Vì vậy SLA nên ghi rõ “thời gian xử lý mục tiêu” và điều kiện loại trừ, thay vì hứa một mốc tuyệt đối không kiểm soát được.
Phạm vi SLA: bao gồm, có điều kiện và không bao gồm
| Nhóm phạm vi | Ví dụ | Cách ghi trong hợp đồng |
|---|---|---|
| Bao gồm | Hỗ trợ người dùng, máy tính, máy in, email, Wi-Fi, VPN, tài khoản, ticket, báo cáo | Nên ghi rõ số user/thiết bị/chi nhánh |
| Có điều kiện | Onsite ngoài giờ, xử lý server/firewall phức tạp, migration, khôi phục dữ liệu | Cần SLA riêng hoặc báo giá riêng |
| Không bao gồm | Mua thiết bị, license phần mềm, sửa phần cứng thay linh kiện, lỗi do nhà mạng/nhà cung cấp thứ ba | Nêu rõ bên chịu chi phí |
| Loại trừ SLA | Thiếu quyền admin, chờ phê duyệt, chờ vendor thứ ba, mất điện/đường truyền diện rộng | Không tính vào thời gian vi phạm SLA |
Kênh tiếp nhận yêu cầu và quy tắc đo SLA
SLA chỉ đo được khi yêu cầu đi qua kênh được thống nhất. Nếu người dùng nhắn riêng kỹ thuật viên, gọi số cá nhân hoặc nhờ miệng, rất khó xác định thời điểm bắt đầu SLA. Vì vậy mẫu SLA nên ghi rõ kênh chính, kênh khẩn cấp và quy tắc tạo ticket sau các cuộc gọi hotline.
| Kênh | Dùng khi nào | Quy tắc SLA |
|---|---|---|
| Ticket/form | Yêu cầu thông thường và theo dõi SLA | Bắt buộc có người yêu cầu, mức ảnh hưởng, ảnh lỗi nếu có |
| Hotline | Sự cố P1/P2 cần phản hồi nhanh | Sau cuộc gọi vẫn tạo ticket để ghi nhận |
| Zalo/Teams/Email | Trao đổi bổ sung, gửi ảnh/video, xác nhận lịch | Không thay thế ticket chính |
| Báo cáo tháng | Đánh giá SLA, ticket, lỗi lặp lại, khuyến nghị | Dùng để nghiệm thu dịch vụ |
Escalation: khi nào chuyển L2/L3 hoặc onsite?
Không phải ticket nào L1 cũng xử lý xong. SLA nên quy định khi nào ticket được chuyển L2/L3: lỗi lặp lại, liên quan server/firewall/VPN, ảnh hưởng nhiều người, cần thay đổi cấu hình hoặc có dấu hiệu bảo mật. Với onsite, cần nêu điều kiện: không xử lý được từ xa, cần kiểm tra thiết bị vật lý, sự cố tại chi nhánh hoặc yêu cầu có lịch hẹn.
Điểm quan trọng là escalation không được làm mất dấu trách nhiệm. Ticket cần ghi người nhận tiếp theo, lý do chuyển, thời điểm chuyển và cập nhật cho người yêu cầu. Nếu không, người dùng chỉ nghe “đã chuyển kỹ thuật” nhưng không biết ai đang chịu trách nhiệm.
Báo cáo SLA hàng tháng nên gồm những chỉ số nào?
| Chỉ số | Cách đọc | Ý nghĩa quản trị |
|---|---|---|
| Tổng ticket | Số ticket mở/đóng/tồn theo tháng | Cho thấy tải hỗ trợ |
| SLA đạt/không đạt | Tỷ lệ phản hồi và xử lý đúng hạn | Đo chất lượng cam kết |
| Lỗi lặp lại | Thiết bị/người dùng/chi nhánh phát sinh nhiều lần | Đề xuất cải tiến |
| Onsite/escalation | Số ca cần onsite hoặc L2/L3 | Đánh giá độ phức tạp |
| Khuyến nghị | Thiết bị cần thay, license cần tối ưu, rủi ro cần xử lý | Tạo hành động sau báo cáo |
Điều khoản loại trừ SLA cần ghi rõ
SLA không nên biến đội IT thành bên chịu trách nhiệm cho mọi thứ ngoài tầm kiểm soát. Các trường hợp thường cần loại trừ gồm: mất điện diện rộng, đứt cáp nhà mạng, chờ phê duyệt mua thiết bị, thiếu quyền admin, vendor phần mềm thứ ba chưa phản hồi, người dùng không cung cấp thông tin, hoặc lỗi phát sinh từ thay đổi không báo trước.
Tuy vậy, “loại trừ” không có nghĩa là bỏ mặc. Đội IT vẫn cần ghi nhận, phối hợp và cập nhật trạng thái. Điểm khác là thời gian chờ bên thứ ba hoặc chờ quyết định của doanh nghiệp không nên tính là vi phạm SLA của đội IT Support.
Mẫu câu điều khoản SLA có thể đưa vào phụ lục
Doanh nghiệp có thể viết ngắn gọn như sau: “Thời gian phản hồi được tính từ khi yêu cầu được ghi nhận qua kênh ticket/hotline chính thức và có đủ thông tin tối thiểu. Thời gian xử lý mục tiêu phụ thuộc mức ưu tiên, quyền truy cập, điều kiện onsite và phản hồi của bên thứ ba. Các khoảng thời gian chờ phê duyệt, chờ nhà mạng, chờ nhà cung cấp phần mềm hoặc thiếu quyền quản trị không tính là vi phạm SLA.”
Một câu khác nên có: “Mọi yêu cầu khẩn cấp báo qua hotline phải được tạo ticket bổ sung sau khi tiếp nhận để phục vụ báo cáo và nghiệm thu.” Điều này giúp doanh nghiệp không mất dữ liệu vận hành chỉ vì sự cố được xử lý qua điện thoại.
Chọn mức SLA theo quy mô doanh nghiệp
Doanh nghiệp 10-30 người thường chỉ cần SLA gọn: giờ hành chính, phản hồi P1 trong 30-60 phút, báo cáo tháng và onsite theo lịch. Doanh nghiệp 30-100 người nên có phân nhóm P1/P2/P3/P4 rõ hơn, ticket bắt buộc và báo cáo lỗi lặp lại. Doanh nghiệp nhiều chi nhánh hoặc vận hành 7 ngày/tuần nên cân nhắc hotline khẩn cấp, onsite ưu tiên, theo dõi thiết bị quan trọng và báo cáo theo chi nhánh.
Không nên mua SLA quá cao nếu quy trình nội bộ chưa sẵn sàng. Ví dụ, nếu doanh nghiệp chưa có người duyệt mua thiết bị, chưa có tài khoản admin thuộc quyền công ty hoặc người dùng không báo lỗi qua ticket, SLA cao cũng khó đạt. Trước khi nâng SLA, nên chuẩn hóa kênh báo lỗi và dữ liệu bàn giao trước.
Cách nghiệm thu SLA cuối tháng
Nghiệm thu SLA nên dựa trên dữ liệu ticket, không chỉ cảm giác. Cuối tháng, hai bên nên xem số ticket, tỷ lệ phản hồi đúng hạn, tỷ lệ xử lý đúng hạn, ticket tồn, ticket lặp lại, số ca onsite, số ca escalation và khuyến nghị cải tiến. Nếu có ticket vi phạm SLA, cần phân tích nguyên nhân: thiếu người, thiếu quyền, thiếu thiết bị, do bên thứ ba hay do phân loại sai.
Bài mẫu báo cáo IT Support hàng tháng có thể dùng làm nền để nghiệm thu. Quan trọng là sau báo cáo phải có hành động: thay thiết bị lỗi, chuẩn hóa Wi-Fi, bổ sung license, đào tạo người dùng hoặc điều chỉnh SLA cho phù hợp hơn.
IT Systems đề xuất mẫu SLA như thế nào?
IT Systems thường bắt đầu bằng khảo sát số user, thiết bị, chi nhánh, giờ làm việc, hệ thống quan trọng và lịch sử sự cố. Từ đó phân nhóm P1/P2/P3/P4, kênh hỗ trợ, onsite/remote, báo cáo tháng và phạm vi loại trừ. Với doanh nghiệp nhỏ, SLA có thể gọn. Với doanh nghiệp nhiều chi nhánh hoặc có server/email quan trọng, SLA cần chi tiết hơn.
Mục tiêu của SLA không phải là tạo hợp đồng dày, mà là giúp doanh nghiệp biết lúc nào cần kỳ vọng phản hồi, lúc nào cần xử lý, lúc nào cần dự án riêng và lúc nào cần báo cáo cho quản lý.
Câu hỏi thường gặp
SLA có đảm bảo mọi lỗi đều xử lý xong trong vài giờ không?
Không. SLA nên cam kết phản hồi, phân loại, xử lý mục tiêu và cập nhật trạng thái. Một số lỗi phụ thuộc nhà mạng, linh kiện, vendor phần mềm hoặc quyết định mua sắm.
Có cần SLA cho doanh nghiệp nhỏ không?
Có. SLA có thể đơn giản hơn nhưng vẫn cần quy định kênh báo lỗi, mức ưu tiên, thời gian phản hồi và báo cáo cơ bản.
SLA có áp dụng cho yêu cầu ngoài giờ không?
Chỉ khi hợp đồng có phạm vi ngoài giờ. Nếu không, nên ghi rõ yêu cầu ngoài giờ là gói riêng hoặc tính phí phát sinh.
Đọc tiếp trong cụm IT Support và SLA
Cần xây SLA IT Support rõ ràng cho doanh nghiệp?
IT Systems có thể giúp thiết kế SLA, kênh ticket, escalation và báo cáo tháng để dịch vụ IT Support đo được, nghiệm thu được và cải tiến được.
