Due diligence nhà cung cấp IT Helpdesk: 12 bằng chứng cần kiểm tra trước khi ký hợp đồng

3 ngày trước

11 phút đọc

Ba nhà cung cấp cùng vào vòng cuối. Báo giá không chênh nhau nhiều. Cả ba đều có SLA, hệ thống ticket, đội ngũ kỹ thuật nhiều cấp và cam kết hỗ trợ khi có sự cố.

Trên giấy, rất khó tìm ra khác biệt.

Sự khác biệt thường chỉ xuất hiện khi doanh nghiệp bắt đầu hỏi sâu hơn: Ai thực sự tiếp nhận ticket? Khi kỹ sư chính nghỉ phép thì ai thay? SLA được tính từ thời điểm nào? Quyền administrator được cấp cho từng cá nhân hay dùng chung? Nếu xảy ra sự cố ngoài giờ, ai là người chịu trách nhiệm giữ ticket đến khi vấn đề được xử lý?

Đến lúc đó, quá trình lựa chọn không còn là đọc proposal, mà chuyển sang xác minh cách dịch vụ sẽ vận hành trong thực tế. Đó là vai trò của due diligence (thẩm định chuyên sâu) nhà cung cấp IT Helpdesk.

Dưới đây là 12 nhóm bằng chứng doanh nghiệp có thể sử dụng để kiểm tra năng lực vendor trước khi đi đến hợp đồng.

Due diligence IT Helpdesk khác gì với checklist chọn nhà cung cấp?

Checklist lựa chọn vendor thường giúp doanh nghiệp xác định một nhà cung cấp có những năng lực nào. Due diligence đi thêm một bước: xác minh các năng lực đó có thực sự tồn tại và có khả năng vận hành trong phạm vi dịch vụ mà doanh nghiệp sắp mua hay không.

Có thể phân biệt đơn giản:

Vendor tuyên bố	Due diligence cần kiểm tra
Có đội ngũ kỹ thuật nhiều cấp	Ai thuộc L1, L2, L3? Khi nào ticket được escalation?
Có hệ thống ticket	Ticket ghi nhận những dữ liệu gì? Ai sở hữu ticket sau khi chuyển cấp?
Có SLA	SLA tính từ thời điểm nào? Response và resolution khác nhau ra sao?
Bảo mật nghiêm ngặt	Quyền quản trị được cấp, ghi log và thu hồi như thế nào?
Có đội ngũ dự phòng	Ai thay thế engineer chính khi người đó nghỉ hoặc quá tải?
Có kinh nghiệm	Có reference hoặc phạm vi triển khai tương đồng để kiểm chứng không?

Trước bước này, doanh nghiệp nên xác định rõ phạm vi IT Helpdesk gồm những hạng mục nào và công việc nào phải tách riêng. Nếu scope chưa rõ, doanh nghiệp rất khó đánh giá một vendor có thực sự đáp ứng yêu cầu hay chỉ đưa ra một danh sách năng lực rộng.

Nói cách khác, scope trả lời “vendor phải làm gì”; due diligence trả lời “bằng chứng nào cho thấy vendor có khả năng làm điều đó”.

1–2. Kiểm chứng đội ngũ thực sự vận hành dịch vụ

Một proposal có thể liệt kê hàng chục kỹ sư hoặc nhiều chứng chỉ kỹ thuật. Tuy nhiên, tổng số nhân sự của công ty chưa chắc phản ánh nguồn lực sẽ trực tiếp phục vụ hợp đồng.

1. Cơ cấu L1/L2/L3 và escalation matrix

Doanh nghiệp nên yêu cầu vendor mô tả hoặc cung cấp sơ đồ thể hiện:

Nhóm nào tiếp nhận yêu cầu ban đầu.
Loại ticket nào được xử lý ở L1.
Khi nào phải chuyển sang L2 hoặc L3.
Ai có quyền thực hiện thay đổi trên hệ thống.
Trường hợp nào cần approval của khách hàng.
Khi chuyển ticket sang nhóm khác, ai tiếp tục giữ trách nhiệm theo dõi.

Điều cần kiểm tra không phải tên gọi L1/L2/L3, mà là ranh giới trách nhiệm và quyền hạn giữa các cấp.

Một vendor có quy trình escalation rõ thường có thể giải thích cụ thể điều gì xảy ra từ lúc người dùng gửi yêu cầu đến lúc ticket được đóng, thay vì chỉ nói rằng “sự cố phức tạp sẽ được chuyển cho chuyên gia”.

2. Hồ sơ năng lực của những vai trò chủ chốt

Không nhất thiết phải yêu cầu CV của toàn bộ nhân sự. Doanh nghiệp nên tập trung vào các role ảnh hưởng trực tiếp đến dịch vụ, chẳng hạn:

Service Delivery Manager.
Team Lead.
Kỹ sư phụ trách escalation.
Kỹ sư onsite nếu hợp đồng có onsite.
Chuyên gia phụ trách các hệ thống đặc thù.

Nếu vendor dựa nhiều vào chứng chỉ, cần kiểm tra chứng chỉ đó có liên quan trực tiếp đến phạm vi dịch vụ hay không.

Một câu hỏi hữu ích là:

“Nếu kỹ sư đang phụ trách tài khoản của chúng tôi nghỉ phép một tuần, ai có thể tiếp quản mà không làm gián đoạn hỗ trợ?”

Câu trả lời sẽ giúp đánh giá vendor đang vận hành dựa trên một đội ngũ có khả năng thay thế lẫn nhau hay phụ thuộc vào một vài cá nhân.

3–4. Yêu cầu vendor chứng minh quy trình bằng ticket và báo cáo thực tế

“Có quy trình IT Helpdesk” là một tuyên bố khó kiểm chứng nếu chỉ nhìn vào sơ đồ trên proposal. Hệ thống ticket và báo cáo vận hành thường cho doanh nghiệp cái nhìn cụ thể hơn.

3. Demo workflow của một ticket thực tế

Doanh nghiệp có thể đề nghị vendor demo một ticket giả lập từ đầu đến cuối.

Ví dụ: một nhân viên không thể đăng nhập Microsoft 365.

Cần quan sát:

Yêu cầu được tiếp nhận qua kênh nào.
Ticket được tự động hay thủ công phân loại.
Priority được xác định dựa trên tiêu chí nào.
Ai nhận trách nhiệm xử lý.
Khi nào ticket được escalation.
Các trao đổi và thao tác có được ghi nhận hay không.
Người dùng xác nhận kết quả theo cách nào.
Điều kiện nào cho phép đóng ticket.

Mục tiêu không phải đánh giá giao diện phần mềm đẹp hay hiện đại, mà là kiểm tra quy trình có đủ khả năng tạo accountability và traceability hay không.

4. Mẫu báo cáo dịch vụ định kỳ

Doanh nghiệp nên yêu cầu một mẫu report đã loại bỏ thông tin nhận diện khách hàng.

Một báo cáo IT Helpdesk hữu ích có thể thể hiện:

Số ticket phát sinh.
Phân loại theo priority hoặc nhóm vấn đề.
Response time.
Resolution time.
Tỷ lệ đạt SLA.
Ticket tồn đọng.
Ticket được mở lại.
Các vấn đề lặp lại.
Sự cố cần escalation.
Các khuyến nghị cải tiến nếu có.

it-helpdesk-report-thang — Mẫu báo cáo dịch vụ định kỳ IT Helpdesk

Nếu vendor chỉ cung cấp tổng số ticket đã đóng nhưng không thể cho biết thời gian xử lý, tình trạng tồn đọng hoặc nguyên nhân ticket lặp lại, doanh nghiệp sẽ khó đánh giá chất lượng dịch vụ sau khi hợp đồng bắt đầu.

5–6. SLA: đừng chỉ kiểm tra con số, hãy kiểm tra cách đo

Một trong những lỗi phổ biến khi đánh giá IT Helpdesk là nhìn vào một con số như “phản hồi trong 15 phút” rồi xem đó là bằng chứng dịch vụ tốt.

SLA cần được đọc trong toàn bộ ngữ cảnh.

ISO/IEC 20000-1:2018 hiện là tiêu chuẩn ISO về các yêu cầu đối với hệ thống quản lý dịch vụ, nhấn mạnh cách tổ chức thiết lập, triển khai, duy trì và cải tiến hệ thống quản lý dịch vụ thay vì chỉ dựa vào một chỉ số thời gian đơn lẻ.

5. SLA matrix

Vendor nên có khả năng cung cấp một SLA matrix thể hiện tối thiểu:

Cách xác định mức Priority.
Response target.
Resolution target hoặc restoration target nếu áp dụng.
Khung giờ dịch vụ.
Điều kiện escalation.
Trường hợp thời gian SLA được tạm dừng.
Trách nhiệm của khách hàng trong quá trình xử lý.
Cách xử lý ticket phụ thuộc bên thứ ba.

Đặc biệt cần phân biệt response time với resolution time. Vendor phản hồi trong 15 phút không có nghĩa sự cố sẽ được giải quyết trong 15 phút.

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

6. Mẫu dữ liệu chứng minh cách SLA được đo

Nếu vendor nói có thể báo cáo SLA hàng tháng, hãy yêu cầu xem một mẫu report hoặc dashboard.

Các câu hỏi nên đặt ra gồm:

Thời điểm bắt đầu tính SLA là lúc email được gửi hay khi ticket được tạo?
Ticket chờ người dùng phản hồi có tiếp tục tính thời gian không?
Ticket chuyển sang nhà cung cấp Internet hoặc phần mềm thứ ba được tính thế nào?
Ticket được mở lại có ảnh hưởng đến resolution metric không?
Ngoài tỷ lệ đạt SLA, vendor có phân tích lý do vi phạm SLA không?

Due diligence không nhằm tìm một vendor có “SLA đẹp nhất”, mà nhằm xác định các chỉ số có được định nghĩa đủ rõ để hai bên cùng hiểu và kiểm chứng hay không.

7–8. Bảo mật: kiểm tra cách vendor quản lý quyền truy cập

IT Helpdesk có thể cần quyền truy cập vào máy tính người dùng, tài khoản Microsoft 365, hệ thống quản trị, VPN hoặc các nền tảng doanh nghiệp khác.

Vì vậy, bảo mật không nên dừng ở việc vendor ký NDA.

ISO/IEC 27001:2022 là phiên bản ISO hiện hành về hệ thống quản lý an toàn thông tin và đặt việc quản trị rủi ro, chính sách và kiểm soát bảo mật trong một hệ thống quản lý có cấu trúc.

Trong due diligence IT Helpdesk, doanh nghiệp nên chuyển nguyên tắc bảo mật thành các câu hỏi vận hành cụ thể.

7. Quy trình cấp, thay đổi và thu hồi quyền

Có thể yêu cầu vendor mô tả:

Ai phê duyệt quyền truy cập.
Engineer sử dụng account cá nhân hay shared account.
Có yêu cầu MFA hay không.
Quyền admin được cấp cố định hay theo nhu cầu.
Engineer nghỉ việc hoặc chuyển dự án thì quyền được thu hồi khi nào.
Ai thực hiện review quyền định kỳ.

Một red flag đáng chú ý là vendor yêu cầu một tài khoản administrator dùng chung cho nhiều kỹ sư nhưng không có cơ chế xác định ai đã thực hiện thao tác nào.

8. Bằng chứng về logging, dữ liệu và bảo mật vận hành

Tùy phạm vi hợp đồng, doanh nghiệp có thể kiểm tra:

NDA và nghĩa vụ bảo mật.
Quy định về remote access.
Chính sách lưu trữ thông tin xác thực.
Logging hoạt động quản trị.
Quy định xử lý dữ liệu của khách hàng.
Cách vendor quản lý thiết bị hoặc công cụ dùng để truy cập hệ thống.

Không phải mọi doanh nghiệp đều cần yêu cầu một bộ tài liệu bảo mật đồ sộ. Mức kiểm tra nên tỷ lệ thuận với dữ liệu, hệ thống và quyền mà vendor sẽ được tiếp cận.

9–10. BCP: điều gì xảy ra khi người hoặc công cụ của vendor không sẵn sàng?

Một Helpdesk có thể hoạt động tốt trong điều kiện bình thường nhưng gặp vấn đề khi engineer chủ chốt nghỉ việc, số ticket tăng đột biến hoặc xảy ra sự cố ngoài giờ.

Đây là lúc doanh nghiệp cần kiểm tra tính liên tục của mô hình vận hành.

9. Kế hoạch nhân sự backup và bàn giao

Vendor nên giải thích được:

Có bao nhiêu người có thể thay thế engineer chính.
Tài liệu khách hàng được lưu ở đâu.
Kiến thức về hệ thống được bàn giao thế nào.
Ticket đang xử lý được chuyển giao ra sao.
Ai chịu trách nhiệm khi workload tăng đột biến.

Nếu toàn bộ thông tin về khách hàng chỉ nằm trong đầu của một kỹ sư, doanh nghiệp vẫn đang đối mặt với single point of failure dù đã thuê một công ty có nhiều nhân viên.

10. Quy trình major incident và escalation ngoài giờ

Hãy thử đặt một tình huống:

7 giờ tối, nhiều người dùng cùng không truy cập được hệ thống quan trọng. Điều gì xảy ra tiếp theo?

Vendor cần mô tả được:

Người dùng liên hệ qua đâu.
Ai tiếp nhận.
Ai có quyền nâng Priority.
Ai được gọi khi L1 không xử lý được.
Khi nào quản lý hai bên được thông báo.
Vendor nào khác cần tham gia.
Ai giữ ownership của sự cố.

Nếu doanh nghiệp đã có đội IT nội bộ, mô hình phối hợp cũng phải xác định rõ bên nào xử lý L1, bên nào phụ trách hệ thống và bên nào có quyền thực hiện thay đổi. Bài thuê ngoài IT hay kết hợp với đội IT nội bộ sẽ đem đến những phân tích chi tiết hơn mô hình co-managed IT và cách phân chia trách nhiệm.

11–12. Reference và hồ sơ thương mại: kiểm chứng khả năng thực hiện hợp đồng

Hai bằng chứng cuối không nằm trực tiếp trong hệ thống ticket, nhưng giúp doanh nghiệp kiểm tra liệu vendor có đủ nền tảng để thực hiện những gì đã cam kết hay không.

11. Khách hàng tham chiếu hoặc tình huống tương đồng

Một reference hữu ích không nhất thiết phải đến từ doanh nghiệp cùng ngành. Quan trọng hơn là mức độ tương đồng về:

Số lượng người dùng.
Số địa điểm.
Remote hay onsite.
Khung giờ hỗ trợ.
Hệ thống đang vận hành.
Yêu cầu SLA.
Mức độ phức tạp của escalation.

Khi thực hiện reference check, đừng chỉ hỏi “Dịch vụ có tốt không?”.

Các câu hỏi cụ thể hơn gồm:

Vendor phản ứng thế nào khi ticket bị chậm?
Có thường phải escalation lên quản lý không?
Báo cáo định kỳ có đủ minh bạch không?
Khi thay engineer, quá trình bàn giao diễn ra thế nào?
Vendor có chủ động phát hiện vấn đề lặp lại hay chỉ đóng từng ticket?

12. Hồ sơ pháp lý, hợp đồng và cơ chế bàn giao

Trước khi ký hợp đồng, doanh nghiệp nên xác minh pháp nhân ký kết và kiểm tra các điều khoản ảnh hưởng trực tiếp đến khả năng vận hành.

Một số điểm cần làm rõ:

Phạm vi trách nhiệm của hai bên.
Có sử dụng subcontractor hay không.
Ai sở hữu tài liệu vận hành.
Quyền truy cập phải được thu hồi thế nào khi hợp đồng kết thúc.
Dữ liệu và lịch sử ticket được bàn giao ở định dạng nào.
Thời gian hỗ trợ chuyển đổi sang vendor mới.
Các nghĩa vụ còn hiệu lực sau khi kết thúc hợp đồng.

Điều khoản termination thường ít được chú ý khi doanh nghiệp đang bắt đầu một hợp tác mới. Nhưng đây lại là bằng chứng quan trọng cho thấy vendor đã nghĩ đến toàn bộ vòng đời dịch vụ, không chỉ giai đoạn bán hàng.

Checklist 12 bằng chứng giúp doanh nghiệp due diligence IT Helpdesk

Doanh nghiệp có thể tổng hợp due diligence thành một checklist đơn giản:

STT	Bằng chứng cần kiểm tra	Câu hỏi chính
1	Cơ cấu L1/L2/L3 và escalation matrix	Ai xử lý và khi nào phải chuyển cấp?
2	Năng lực role chủ chốt	Ai thực sự tham gia vào dự án?
3	Demo ticket workflow	Một yêu cầu đi qua hệ thống thế nào?
4	Mẫu service report	Doanh nghiệp sẽ nhìn thấy dữ liệu gì mỗi tháng?
5	SLA matrix	Priority, response và resolution được định nghĩa thế nào?
6	Mẫu báo cáo SLA	Vendor đo và chứng minh SLA bằng gì?
7	Access management process	Ai được quyền truy cập hệ thống nào?
8	Logging và data-handling evidence	Hoạt động quản trị có được kiểm soát và truy vết không?
9	Backup staffing plan	Ai thay thế người phụ trách khi họ không sẵn sàng?
10	Major incident procedure	Sự cố nghiêm trọng được chuyển cấp thế nào?
11	Reference tương đồng	Vendor đã vận hành môi trường tương tự chưa?
12	Legal/exit/handover documentation	Khi bắt đầu hoặc kết thúc hợp đồng, trách nhiệm được chuyển giao thế nào?

Không phải mọi nhà cung cấp đều cần xây một data room phức tạp. Với doanh nghiệp nhỏ và phạm vi Helpdesk cơ bản, nhiều bằng chứng có thể được xác minh qua một buổi technical meeting, demo ticketing và bộ tài liệu hợp đồng.

Ngược lại, nếu vendor sẽ được cấp quyền quản trị hệ thống quan trọng, hỗ trợ nhiều địa điểm hoặc chịu trách nhiệm ngoài giờ, mức due diligence nên sâu hơn.

Một quy trình due diligence tốt chuyển từng cam kết thành câu hỏi có thể kiểm chứng:

Ai thực hiện?
Quy trình nào được sử dụng?
Hệ thống ghi nhận yêu cầu ở đâu?
Chỉ số được đo như thế nào?
Và bằng chứng nào cho thấy điều đó thực sự đang vận hành?

12 nhóm bằng chứng về đội ngũ, ticketing, báo cáo, SLA, quyền truy cập, bảo mật, BCP, reference và trách nhiệm hợp đồng giúp doanh nghiệp giảm khoảng cách giữa những gì vendor trình bày trong giai đoạn bán hàng và những gì sẽ diễn ra sau khi dịch vụ bắt đầu.

Nếu doanh nghiệp đã xác định phạm vi hỗ trợ và đang đánh giá phương án thuê ngoài, có thể tham khảo dịch vụ IT Helpdesk của IPSIP Việt Nam để trao đổi phạm vi, mô hình Remote/Onsite, SLA và yêu cầu vận hành trước khi nhận đề xuất dịch vụ.