IT Support 8x5 và 24x7: Cách chọn khung giờ đúng nhu cầu
Chọn IT Support 8x5, 12x6 hay 24x7 nên dựa trên giờ vận hành thực tế, timezone, mức độ critical của hệ thống và workload ngoài giờ. 8x5 phù hợp khi hoạt động tập trung trong giờ hành chính; 12x6 phù hợp khi cần coverage dài hơn nhưng chưa cần trực liên tục; còn 24x7 chỉ nên chọn khi người dùng hoặc hệ thống thực sự cần hỗ trợ mọi thời điểm. Trong nhiều trường hợp, 8x5 hoặc 12x6 kết hợp on-call cho sự cố P1 có thể hợp lý hơn full 24x7 staffed.
Khi đánh giá một dịch vụ IT Helpdesk, doanh nghiệp thường dễ tập trung vào SLA, số lượng kỹ thuật viên hoặc mức phí hàng tháng. Nhưng một yếu tố có ảnh hưởng trực tiếp tới cả chi phí lẫn khả năng vận hành là khung giờ support.
Nếu coverage quá ngắn, user ngoài giờ có thể phải chờ tới ca tiếp theo. Nếu coverage quá rộng trong khi ticket ngoài giờ rất ít, doanh nghiệp có thể đang trả tiền cho một năng lực gần như không được sử dụng.
Vì vậy, bài toán đúng không phải: “24x7 có tốt hơn 8x5 không?”. Mà là: “Khung giờ nào đủ để bao phủ rủi ro vận hành thực tế mà không tạo staffing dư thừa?”
Nếu doanh nghiệp vẫn đang xác định IT Helpdesk cần chịu trách nhiệm tới đâu, có thể xem trước bài dịch vụ IT Helpdesk & IT Support cho doanh nghiệp để làm rõ phạm vi support trước khi chốt coverage.
IT Support 8x5, 12x6 và 24x7 thực chất khác nhau ở đâu?
Cách viết 8x5, 12x6 hay 24x7 thường mô tả số giờ support mỗi ngày và số ngày support mỗi tuần.
IT Support 8x5
Thông thường là:
8 giờ mỗi ngày × 5 ngày mỗi tuần
Đây là mô hình phù hợp với doanh nghiệp có hoạt động chủ yếu trong giờ hành chính.
Ví dụ:
văn phòng làm việc thứ Hai đến thứ Sáu;
user tập trung trong một timezone;
ít sự cố critical ngoài giờ;
có thể chờ đến ngày làm việc tiếp theo với các request thông thường.
IT Support 12x6
Có thể hiểu là:
12 giờ mỗi ngày × 6 ngày mỗi tuần
Mô hình này phù hợp khi doanh nghiệp có:
giờ làm kéo dài hơn office hours;
hoạt động thứ Bảy;
sales hoặc operation làm ngoài giờ hành chính;
một phần user ở timezone khác;
workload ngoài giờ có thật nhưng chưa liên tục.
IT Support 24x7
Đây là coverage: 24 giờ mỗi ngày × 7 ngày mỗi tuần
Phù hợp khi:
business operation chạy liên tục;
có nhiều ca làm việc;
có user ở nhiều timezone;
hệ thống critical không thể chờ tới sáng hôm sau;
ticket ngoài giờ xuất hiện thường xuyên.
Tuy nhiên, một điểm rất quan trọng là:
24x7 coverage không đồng nghĩa mọi ticket đều có cùng SLA 24x7. Doanh nghiệp vẫn có thể áp target khác nhau theo priority.
Ví dụ, P1 có thể cần response ngay ngoài giờ, trong khi service request thông thường được xử lý trong business hours.
Nếu cần đi sâu hơn về cách thiết kế priority và target, IPSIP Việt Nam có phân tích trong bài SLA IT Helpdesk: nền tảng cho vận hành không gián đoạn.
Bước 1: Bắt đầu từ giờ vận hành thực tế
Doanh nghiệp không nên bắt đầu bằng câu: “Chúng tôi muốn 24x7 để an toàn.”
Nên bắt đầu từ: “Người dùng và hệ thống của chúng tôi thực sự cần support vào những khung giờ nào?”
Các câu hỏi nên làm rõ gồm:
user bắt đầu làm việc từ mấy giờ;
kết thúc lúc mấy giờ;
có ca tối hoặc ca đêm không;
có làm việc cuối tuần không;
có warehouse hoặc production site hoạt động ngoài giờ không;
có nhân sự làm remote ở múi giờ khác không;
có bộ phận nào làm việc sớm hơn hoặc muộn hơn phần còn lại không.
Ví dụ, một doanh nghiệp có 500 user không đồng nghĩa cần 24x7.
Nếu phần lớn user chỉ hoạt động từ 8:00 đến 17:00 và ngoài khung đó gần như không phát sinh support demand, full 24x7 staffed có thể tạo ra capacity dư thừa.
Ngược lại, một doanh nghiệp chỉ có 100 user nhưng vận hành nhà máy theo ba ca lại có thể cần coverage dài hơn nhiều. Số lượng user không đủ để quyết định coverage. Giờ vận hành và business dependency quan trọng hơn.
Bước 2: Tính workload ngoài giờ
Sau operating hours, yếu tố tiếp theo là ticket volume ngoài giờ.
Một model đơn giản có thể bắt đầu bằng:
After-hours Workload = Số ticket ngoài giờ × Thời gian xử lý trung bình
Tuy nhiên, không nên chỉ nhìn tổng số ticket.
Nên tách thêm:
weekday evening;
nighttime;
weekend;
holiday;
P1/P2;
routine request;
escalation;
seasonal peak.
Ví dụ, 20 ticket ngoài giờ mỗi tháng có thể mang hai ý nghĩa rất khác nhau.
Trường hợp 1:
20 ticket đều là password reset hoặc request thông thường.
Trường hợp 2:
20 ticket gồm nhiều production incident hoặc sự cố khiến user ngừng làm việc.
Ticket count giống nhau nhưng business impact hoàn toàn khác.
Có thể chia workload theo ba mức đơn giản:
Low after-hours workloadTicket ngoài giờ hiếm và phần lớn có thể chờ.
Moderate after-hours workloadCó nhu cầu đều đặn vào buổi tối hoặc cuối tuần nhưng chưa đủ để justify full 24x7.
Sustained after-hours workloadTicket phát sinh liên tục ở nhiều khung giờ hoặc nhiều timezone.
Đây là nền tảng để quyết định giữa 8x5, 12x6, on-call hay 24x7 staffed.
Bước 3: Đánh giá criticality trước khi mở rộng coverage
Không phải ticket nào phát sinh lúc 22:00 cũng cần được xử lý ngay lúc 22:00.
Một password reset cho user bắt đầu làm việc lúc 8:00 sáng hôm sau có mức urgency khác hoàn toàn với production system bị down trong ca đêm.
Doanh nghiệp nên tách ít nhất:
critical incident;
high-impact user issue;
normal incident;
routine service request.
Có thể dùng một logic đơn giản:
Business Impact = Số user bị ảnh hưởng × Mức độ gián đoạn × Thời gian có thể chấp nhận
Một sự cố P1 ảnh hưởng toàn bộ operation có thể justify on-call hoặc staffed support ngoài giờ dù volume rất thấp. Ngược lại, nếu hầu hết request ngoài giờ có thể chờ đến ngày hôm sau thì 24x7 staffed có thể không cần thiết.
Vì vậy: Coverage model nên được thiết kế theo business impact, không chỉ theo ticket count.
Bước 4: On-call và staffed support khác nhau thế nào?
Đây là điểm doanh nghiệp nên làm rõ khi nhận proposal.
“Có support ngoài giờ” không phải lúc nào cũng có nghĩa là luôn có một agent ngồi trực.
Có hai mô hình phổ biến.
On-call
On-call phù hợp khi:
volume ngoài giờ thấp;
chủ yếu cần xử lý P1/P2;
sự cố không xảy ra thường xuyên;
không cần full service catalogue ngoài giờ.
Khi có incident đủ điều kiện, on-call engineer được kích hoạt theo escalation rule.
Mô hình này có thể giúp doanh nghiệp có emergency coverage mà không cần duy trì full staffed shift suốt đêm.
Staffed coverage
Staffed support nghĩa là có nhân sự được bố trí chủ động trong ca trực.
Phù hợp khi:
ticket ngoài giờ xuất hiện đều;
user cần hỗ trợ thường xuyên;
business chạy nhiều ca;
nhiều request không thể chờ;
cần xử lý broader scope ngoài giờ.
Staffed support thường cần nhiều nguồn lực hơn on-call vì capacity phải được duy trì ngay cả khi ticket volume thấp tại một số thời điểm.
8x5 + on-call có thể là lựa chọn hợp lý hơn 24x7
Đây là một mô hình rất đáng cân nhắc.
Ví dụ:
8x5 staffedcho toàn bộ request thông thường.
Sau business hours: 24x7 on-call cho P1/P2
Như vậy doanh nghiệp vẫn có khả năng phản ứng với sự cố critical mà không cần duy trì một đội Helpdesk full 24x7 cho tất cả request.
Tương tự, có thể triển khai: 12x6 staffed + emergency on-call ngoài khung đó
Mô hình hybrid này thường phù hợp khi risk ngoài giờ cao nhưng volume lại thấp.
Bước 5: Timezone có thể làm 8x5 trở thành “không đủ”
Một Helpdesk 8x5 chỉ có ý nghĩa khi câu hỏi tiếp theo được trả lời: 8x5 theo timezone nào?
Nếu doanh nghiệp chỉ hoạt động tại Việt Nam, việc xác định business hours khá đơn giản.
Nhưng nếu user nằm ở:
Việt Nam;
Singapore;
Australia;
Europe;
United States;
thì cùng một ca 8x5 tại Việt Nam có thể bỏ trống một phần lớn giờ làm việc của user ở khu vực khác.
Một số lựa chọn có thể gồm:
extended single-region shift;
staggered shifts;
follow-the-sun;
regional support;
vendor + internal IT hybrid.
Không nhất thiết phải chuyển ngay sang 24x7.
Trong một số trường hợp, chỉ cần dịch hoặc mở rộng ca là đủ để cover phần lớn user demand.
Bước 6: Chi phí IT Support 8x5, 12x6 và 24x7 thay đổi theo gì?
Không nên giả định 24x7 luôn có một tỷ lệ giá cố định so với 8x5.
Chi phí thực tế phụ thuộc vào nhiều yếu tố:
tổng số giờ staffed;
số ca cần duy trì;
overlap giữa các ca;
night shift;
weekend;
holiday;
skill level;
SLA;
Remote/Onsite;
ngôn ngữ;
số timezone;
backup coverage;
expected ticket volume.
Yếu tố chi phí | Vì sao ảnh hưởng |
Staffed hours | Coverage càng dài, tổng giờ trực càng tăng |
Số ca | Nhiều ca cần thêm nguồn lực và handover |
Night/weekend | Có thể làm tăng chi phí vận hành |
SLA target | Target chặt hơn có thể cần nhiều capacity hơn |
Remote/Onsite | Onsite thường cần nguồn lực riêng |
Timezone | Multi-timezone có thể cần staggered shift hoặc regional coverage |
Backup coverage | Cần đủ người để duy trì service khi nghỉ phép hoặc vắng mặt |
Một mô hình 24x7 với volume rất thấp nhưng yêu cầu agent luôn available vẫn có staffing cost đáng kể. Ngược lại, một mô hình 12x6 có workload đều và cần nhiều agent đồng thời cũng có thể không rẻ chỉ vì số giờ ít hơn.
Vì vậy, khi so proposal, nên yêu cầu vendor mô tả rõ:
staffed hours;
on-call hours;
response target ngoài giờ;
scope ngoài giờ;
ticket types được hỗ trợ;
escalation;
add-on charge nếu có.
Coverage Matrix: nên chọn 8x5, 12x6 hay 24x7?
Có thể dùng matrix sau như một khung quyết định ban đầu:
Matrix này không phải quy tắc tuyệt đối. Mục đích là giúp doanh nghiệp đặt câu hỏi đúng trước khi chọn coverage.
Khi nào IT Support 8x5 là đủ?
8x5 thường phù hợp khi:
doanh nghiệp làm việc chủ yếu trong office hours;
user tập trung tại một khu vực;
ticket ngoài giờ ít;
critical system có team riêng xử lý;
request thông thường có thể chờ đến ngày hôm sau;
internal IT có emergency escalation nếu cần.
Mô hình này cũng có thể phù hợp với doanh nghiệp đang bắt đầu outsource L1 Helpdesk nhưng vẫn giữ internal IT cho infrastructure và incident critical.
Khi nào 12x6 hợp lý hơn?
12x6 thường là lựa chọn đáng cân nhắc khi 8x5 bắt đầu thiếu nhưng 24x7 vẫn quá rộng.
Ví dụ:
sales team làm tới tối;
warehouse hoạt động dài giờ;
thứ Bảy vẫn có operation;
remote users làm lệch giờ;
ticket ngoài giờ đã xuất hiện đều.
Điểm mạnh của 12x6 là tăng coverage đúng nơi có demand mà chưa cần xây toàn bộ 24x7 operating model.
Khi nào 24x7 thực sự cần thiết?
24x7 hợp lý hơn khi một hoặc nhiều điều kiện sau xuất hiện:
business hoạt động liên tục;
production chạy nhiều ca;
user nằm ở nhiều timezone;
customer-facing service hoạt động 24/7;
critical incident không thể chờ tới business hours;
after-hours workload đủ lớn;
hợp đồng hoặc operating requirement yêu cầu support liên tục.
Điểm quan trọng là phải phân biệt: “Có rủi ro ngoài giờ”và“Cần full staffed 24x7.” Rất nhiều doanh nghiệp thuộc nhóm đầu nhưng không nhất thiết thuộc nhóm sau.
Có IT nội bộ thì coverage nên chia thế nào?
Nếu doanh nghiệp đã có internal IT, không nhất thiết vendor phải cover toàn bộ service 24x7.
Có thể thiết kế nhiều mô hình.
Vendor 8x5 + Internal IT on-call
Vendor xử lý daily Helpdesk.
Internal IT nhận incident critical ngoài giờ.
Vendor 12x6 + Internal escalation
Vendor mở rộng coverage vào buổi tối và thứ Bảy.
Internal IT tiếp tục chịu trách nhiệm L2/L3 hoặc hệ thống critical.
Vendor 24x7 L1 + Internal L2/L3
Vendor nhận ticket liên tục.
Internal specialist chỉ được escalate khi incident đủ điều kiện.
Shared on-call
Vendor và internal IT có escalation tree rõ ràng theo category và ownership. Điều quan trọng nhất là boundary phải rõ. Nếu không, một ticket ngoài giờ có thể bị chuyển qua lại giữa Helpdesk, internal IT và application vendor.
IPSIP Việt Nam có phân tích trong bài có sẵn IT nội bộ có nên thuê ngoài IT Helpdesk? cách hai mô hình có thể phối hợp thay vì thay thế hoàn toàn cho nhau.
Nên chốt những gì trong SLA khi có hỗ trợ ngoài giờ?
Coverage và SLA phải được thiết kế cùng nhau.
Tối thiểu nên làm rõ:
service hours;
timezone;
business day;
holiday calendar;
priority;
response target;
resolution target nếu áp dụng;
on-call activation;
after-hours escalation;
pause condition;
excluded request;
dependency với vendor khác.
Ví dụ, hợp đồng ghi “24x7 support” nhưng không nêu rõ 24x7 áp dụng cho mọi request hay chỉ P1/P2 thì vẫn có thể gây hiểu nhầm.
IPSIP Việt Nam hỗ trợ doanh nghiệp chọn coverage IT Helpdesk như thế nào?
Khung giờ hỗ trợ chỉ hợp lý khi phản ánh đúng môi trường vận hành thực tế. Số user không phải yếu tố duy nhất. Giờ làm việc, timezone, ticket volume ngoài giờ, criticality, onsite requirement và vai trò của internal IT đều có thể làm thay đổi mô hình phù hợp.
Với doanh nghiệp đang cân nhắc IT Helpdesk thuê ngoài, IPSIP Việt Nam có thể cùng rà soát các nhóm thông tin như:
operating hours;
user và site;
timezone;
ticket distribution;
after-hours demand;
critical incident;
Remote/Onsite requirement;
SLA;
escalation;
internal IT boundary.
Từ đó, doanh nghiệp có thể xác định liệu nhu cầu thực tế phù hợp hơn với 8x5, 12x6, on-call hay 24x7 staffed. Doanh nghiệp có thể tham khảo dịch vụ IT Helpdesk & IT Support của IPSIP Việt Nam để hình dung phạm vi dịch vụ trước khi xây coverage model cụ thể.
Trước khi chọn 8x5, 12x6 hay 24x7, doanh nghiệp nên chuẩn hóa giờ vận hành, workload ngoài giờ và mức độ critical. Từ đó mới có thể so sánh coverage và chi phí một cách sát thực tế. Doanh nghiệp có thể tham khảo dịch vụ IT Helpdesk & IT Support của IPSIP Việt Nam hoặc yêu cầu khảo sát để xây phương án phù hợp với nhu cầu hiện tại.
Nguồn tham khảo
