25 câu hỏi xác định yêu cầu dịch vụ IT Helpdesk trước khi xin báo giá
Trước khi xin báo giá IT Helpdesk, doanh nghiệp nên xác định rõ ít nhất 7 nhóm yêu cầu: người dùng và địa điểm, giờ hỗ trợ, phạm vi hệ thống, SLA, nhu cầu onsite, bảo mật và cách báo cáo. Brief càng rõ, vendor càng dễ đề xuất đúng phạm vi dịch vụ và báo giá sát nhu cầu; đồng thời doanh nghiệp cũng dễ so sánh các phương án trên cùng một cơ sở thay vì chỉ nhìn vào mức giá cuối cùng.
Một trong những lý do khiến báo giá IT Helpdesk khó so sánh là đầu vào giữa các vendor không giống nhau.
Một nhà cung cấp có thể đang tính cho business hours và remote support. Một bên khác đã bao gồm onsite, hỗ trợ ngoài giờ, escalation hoặc một số hệ thống đặc thù. Khi scope đầu vào khác nhau, mức giá cuối cùng cũng sẽ khác, nhưng chưa thể kết luận phương án nào thực sự phù hợp hơn.
Vì vậy, trước khi gửi báo giá yêu cầu dịch vụ IT Helpdesk, doanh nghiệp nên chuẩn hóa một bộ câu hỏi chung để làm rõ nhu cầu vận hành.
Vì sao nên chuẩn hóa yêu cầu trước khi xin báo giá yêu cầu dịch vụ IT Helpdesk?
Mục tiêu của một IT Helpdesk requirements checklist không phải để doanh nghiệp tự thiết kế toàn bộ dịch vụ thay cho nhà cung cấp.
Mục tiêu là giúp buyer và vendor bắt đầu từ cùng một baseline.
Khi những yếu tố như scope, coverage, hệ thống cần hỗ trợ, SLA, onsite, security boundary và reporting chưa rõ, mỗi vendor có thể tự đưa ra một bộ assumption khác nhau. Khi đó, hai proposal nhìn giống nhau ở tên dịch vụ nhưng thực tế lại đang định giá hai phạm vi khác nhau.
Một brief được chuẩn hóa giúp doanh nghiệp giảm việc bỏ sót scope quan trọng, nhìn rõ các assumption trong proposal, xác định phần nào là included hoặc optional và so sánh các nhà cung cấp trên cùng một nền yêu cầu.
👉 Nếu doanh nghiệp chưa xác định rõ Helpdesk nên chịu trách nhiệm đến đâu, có thể tham khảo trước bài dịch vụ IT Helpdesk & IT Support cho doanh nghiệp để hình dung phạm vi hỗ trợ trước khi hoàn thiện questionnaire.
Nhóm 1: Người dùng và địa điểm cần hỗ trợ
1. Doanh nghiệp có bao nhiêu người dùng cần hỗ trợ?
Không nên mặc định số user bằng tổng số nhân sự.
Doanh nghiệp cần xác định ai thực sự nằm trong phạm vi Helpdesk: toàn bộ nhân viên, chỉ khối văn phòng, nhân sự tại một số site hay một nhóm người dùng cụ thể.
Số user là một dữ liệu đầu vào quan trọng, nhưng không nên dùng riêng số này để suy ra staffing vì workload còn phụ thuộc loại request, ticket volume và mức độ phức tạp.
2. Người dùng làm việc tại bao nhiêu văn phòng hoặc địa điểm?
Nếu dịch vụ có onsite, thông tin địa điểm đặc biệt quan trọng.
Brief nên ghi rõ số office/site, khu vực hoặc thành phố, địa điểm nào thường cần onsite và địa điểm nào chủ yếu được hỗ trợ từ xa.
3. Có người dùng remote hoặc hybrid không?
Nếu có, cần xác định tỷ lệ user remote/hybrid, cách họ truy cập hệ thống, loại thiết bị sử dụng và việc Helpdesk có được phép remote vào endpoint hay không.
4. Có nhóm người dùng nào cần mức hỗ trợ khác biệt không?
Ví dụ:
executive users;
sales team;
nhân sự làm việc theo ca;
production users;
nhóm sử dụng ứng dụng đặc thù.
Không phải mọi user đều cần cùng một support model.
Nhóm 2: Giờ hỗ trợ và kênh tiếp nhận
5. Doanh nghiệp cần hỗ trợ trong khung giờ nào?
Cần ghi rõ business hours hay extended coverage, chẳng hạn 8x5, 12x5 hoặc 24x7.
Khung giờ hỗ trợ càng rộng thì cách tổ chức nguồn lực và escalation càng khác.
6. Có cần hỗ trợ cuối tuần hoặc ngày lễ không?
Đây là yếu tố không nên để vendor tự suy đoán.
Nếu doanh nghiệp vẫn vận hành cuối tuần, ngày lễ hoặc ngoài giờ, cần xác định rõ nhóm issue nào phải được xử lý trong các khung thời gian này.
7. Người dùng sẽ gửi yêu cầu qua những kênh nào?
Có thể gồm portal, email, hotline, chat hoặc kênh cộng tác nội bộ.
Atlassian đưa các yếu tố như customer channels, SLA, reporting và permissions vào checklist đánh giá service desk của họ. Đây không phải một chuẩn bắt buộc cho mọi Helpdesk, nhưng là một ví dụ thực tế cho thấy channel và cách tiếp nhận yêu cầu cần được xác định ngay từ thiết kế dịch vụ. Atlassian
8. Có nhóm user hoặc loại sự cố nào cần hotline ưu tiên không?
Ví dụ P1 incident, executive support hoặc production outage.
Câu hỏi này giúp xác định cách intake và escalation thay vì để mọi request đi qua một luồng giống nhau.
Nhóm 3: Hệ thống và phạm vi kỹ thuật cần hỗ trợ
Một yêu cầu kiểu “support toàn bộ IT” thường quá rộng để vendor có thể estimate chính xác.
9. Helpdesk cần hỗ trợ những loại endpoint nào?
Có thể bao gồm desktop, laptop, mobile device, printer, scanner, meeting-room device hoặc thiết bị chuyên dụng.
10. Những hệ điều hành nào đang được sử dụng?
Windows, macOS hay môi trường hỗn hợp đều có thể ảnh hưởng tới tooling và kỹ năng cần thiết.
Nếu có Linux hoặc thiết bị đặc thù, nên ghi riêng thay vì để vendor tự mặc định.
11. Những ứng dụng và dịch vụ nào nằm trong scope?
Ví dụ:
Microsoft 365;
Outlook;
Teams;
VPN;
browser;
CRM;
ERP client;
collaboration tools;
line-of-business applications.
Không cần liệt kê mọi phần mềm cài trên máy, nhưng cần xác định những hệ thống Helpdesk thực sự phải hỗ trợ.
12. Helpdesk có cần hỗ trợ account, access và onboarding/offboarding không?
Cần làm rõ Helpdesk có quyền thực hiện những thao tác nào như reset password, unlock account, tạo user, cấp quyền hoặc phối hợp onboarding/offboarding.
13. Những hệ thống nào phải escalate sang IT nội bộ hoặc vendor khác?
Đây là câu hỏi xác định responsibility boundary.
Ví dụ Helpdesk có thể xử lý Level 1 cho một ứng dụng nhưng issue backend phải chuyển vendor ứng dụng; security incident có thể phải chuyển SOC; network core có thể vẫn thuộc internal IT.
👉 Nếu doanh nghiệp đã có đội IT riêng, bài có sẵn IT nội bộ có nên thuê ngoài IT Helpdesk? phân tích rõ hơn cách chia trách nhiệm giữa hai bên.
Nhóm 4: SLA và mức độ ưu tiên
14. Doanh nghiệp muốn phân loại ticket theo mức độ ưu tiên nào?
Có thể sử dụng P1/P2/P3/P4, Critical/High/Medium/Low hoặc taxonomy riêng.
Quan trọng là priority phải phản ánh impact và urgency thay vì chỉ là nhãn kỹ thuật.
15. Response target mong muốn là bao lâu?
Response target có thể khác nhau theo priority hoặc loại request.
16. Resolution target có cần cam kết hay chỉ theo dõi?
Một số ticket phụ thuộc vendor khác, user availability, approval hoặc hardware replacement. Vì vậy, doanh nghiệp nên phân biệt rõ đâu là mục tiêu mà Helpdesk có thể chịu trách nhiệm trực tiếp và đâu là phần coordination.
17. Khi SLA có nguy cơ breach, escalation cần diễn ra như thế nào?
Cần xác định ai được thông báo, khi nào chuyển Level 2/Level 3, có cảnh báo trước breach hay không và ai là owner cuối cùng.
Trong Jira Service Management, SLA được cấu hình thông qua mục tiêu thời gian cùng các điều kiện và calendar; SLA goals cũng có thể áp dụng khác nhau theo các điều kiện như priority. Đây là ví dụ cho thấy khi brief SLA, doanh nghiệp không nên chỉ ghi “cần SLA tốt” mà phải xác định rõ target và điều kiện áp dụng. Atlassian Support
👉 Nếu cần đi sâu hơn về response target, resolution target và cách thiết kế SLA, có thể tham khảo chi tiết trong bài SLA IT Helpdesk.
Nhóm 5: Nhu cầu onsite
18. Những trường hợp nào bắt buộc phải onsite?
Không nên chỉ ghi “onsite khi cần”.
Cần xác định trigger cụ thể, chẳng hạn hardware issue, meeting-room problem, user không thể remote, network issue tại site hoặc onboarding hardware.
19. Doanh nghiệp cần onsite cố định hay dispatch theo yêu cầu?
Có thể là resident engineer, scheduled visit, on-demand dispatch hoặc mô hình kết hợp.
20. Thời gian onsite mong muốn là bao lâu?
Ví dụ same day, next business day hoặc theo priority.
Càng xác định rõ nhu cầu onsite, vendor càng dễ phân biệt effort thường xuyên với dispatch phát sinh.
Nhóm 6: Bảo mật và quyền truy cập
Đây là phần brief không nên để đến sau khi ký hợp đồng mới bàn.
21. Helpdesk được phép sử dụng công cụ remote nào?
Nếu doanh nghiệp đã có remote-support tool hoặc policy bắt buộc, nên ghi rõ từ đầu.
Microsoft khuyến nghị khi lập kế hoạch Remote Help cần xem xét platform/device support, tenant configuration, Conditional Access, RBAC, network requirements và các giới hạn liên quan. Microsoft Learn
22. Có yêu cầu nào về MFA, privileged access hoặc logging không?
Không nên mặc định kỹ thuật viên Helpdesk được toàn quyền trên endpoint.
Tài liệu Microsoft Remote Help khuyến nghị áp dụng least privilege, dùng RBAC để giới hạn mức quyền của helper và có thể yêu cầu MFA hoặc compliant device thông qua Conditional Access cho tài khoản hỗ trợ. Microsoft cũng lưu thông tin phiên remote nhất định và cung cấp audit-related information cho hoạt động hỗ trợ. Microsoft Learn
Vì vậy, brief có thể làm rõ:
Helpdesk dùng account cá nhân hay shared account?
L1 được view-only hay full control?
Khi nào được elevation?
MFA có bắt buộc không?
Có yêu cầu audit/logging hay không?
23. Có hệ thống hoặc dữ liệu nào Helpdesk không được phép truy cập không?
Ví dụ payroll, finance system, security console, privileged infrastructure hoặc một số file share nhạy cảm.
Security boundary càng rõ từ đầu, khả năng vendor và doanh nghiệp hiểu khác nhau về quyền hỗ trợ càng thấp.
Nhóm 7: Báo cáo và quản trị dịch vụ
24. Doanh nghiệp muốn nhận những báo cáo nào và với tần suất bao lâu?
Có thể gồm:
SLA/KPI;
backlog;
top issues;
recurring problems;
monthly service report;
incident summary;
action tracker.
Không cần đưa tất cả vào scope nếu doanh nghiệp không sử dụng. Quan trọng là biết report nào phục vụ quyết định nào.
25. Ai sẽ tham gia service review và những quyết định nào cần được theo dõi sau mỗi kỳ?
Cần xác định:
ai nhận report;
ai review;
ai phê duyệt action;
ai làm owner cho recurring issue;
action kỳ trước được follow-up như thế nào.
Mẫu brief IT Helpdesk sau khi trả lời 25 câu hỏi sẽ trông như thế nào?
Sau khi hoàn thành questionnaire, doanh nghiệp chưa cần viết một tài liệu kỹ thuật dài hàng chục trang.
Có thể gom câu trả lời thành một brief ngắn như sau:
Nhóm thông tin | Nội dung cần chốt |
Người dùng | Số user, user đặc biệt, remote/hybrid |
Địa điểm | Office/site, khu vực cần onsite |
Coverage | Giờ hỗ trợ, cuối tuần, ngoài giờ |
Hệ thống | Endpoint, OS, ứng dụng, account |
SLA | Priority, response, resolution, escalation |
Onsite | Trigger, mô hình, thời gian đáp ứng |
Security | Remote access, privilege, restriction |
Reporting | KPI, monthly report, service review |
Đây chính là phần thông tin doanh nghiệp có thể gửi cho các vendor để họ cùng dựa trên một baseline khi khảo sát và xây proposal.
25 câu hỏi này giúp doanh nghiệp so sánh vendor tốt hơn như thế nào?
Khi tất cả vendor cùng nhận một bộ đầu vào, khác biệt giữa các proposal sẽ dễ nhìn hơn.
Doanh nghiệp có thể kiểm tra vendor nào hiểu đúng scope, onsite có được tính hay không, outside-hours support có nằm trong proposal không, SLA có cùng định nghĩa không, hệ thống nào vendor trực tiếp xử lý và hệ thống nào chỉ coordinate hoặc escalate.
Điều tương tự cũng áp dụng cho reporting, security và responsibility boundary.
Hai proposal chỉ thực sự dễ so sánh khi scope, coverage, SLA và trách nhiệm giữa các bên đủ tương đồng.
👉 Vì vậy, bài viết này không phải bài báo giá. Mục tiêu là giúp doanh nghiệp chuẩn hóa đầu vào trước khi bước sang quá trình định giá.
IPSIP Việt Nam hỗ trợ doanh nghiệp xác định yêu cầu IT Helpdesk như thế nào?
Trước khi xây một phương án IT Helpdesk, doanh nghiệp không nhất thiết phải tự trả lời toàn bộ 25 câu hỏi ở mức kỹ thuật. Quan trọng hơn là xác định được hiện trạng vận hành, nhóm người dùng cần hỗ trợ, hệ thống chính, giờ coverage và những vấn đề doanh nghiệp đang muốn cải thiện.
Từ các thông tin ban đầu đó, IPSIP Việt Nam có thể cùng doanh nghiệp rà soát phạm vi hỗ trợ, ranh giới với IT nội bộ, nhu cầu Remote/Onsite, SLA, escalation, security boundary và cách reporting cần được tổ chức.
Trường hợp doanh nghiệp đã có đội IT nội bộ, Helpdesk thuê ngoài cũng không nhất thiết thay thế nguồn lực hiện tại. Scope có thể được phân chia theo hướng đối tác tiếp nhận Level 1 hoặc các request lặp lại, trong khi internal IT tiếp tục tập trung vào hạ tầng, ứng dụng, security và các vấn đề chuyên sâu.
👉 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 hỗ trợ trước khi hoàn thiện requirements checklist.
Nếu đang chuẩn bị xin báo giá IT Helpdesk, doanh nghiệp có thể bắt đầu bằng việc hoàn thành questionnaire trong bài hoặc dùng nó làm checklist trong buổi khảo sát nhu cầu. Khi scope, coverage, SLA và responsibility boundary đã rõ hơn, IPSIP Việt Nam có thể cùng doanh nghiệp xây dựng phương án và báo giá dựa trên mô hình vận hành thực tế thay vì áp một scope cố định cho mọi trường hợp.
Với doanh nghiệp đang ở giai đoạn chuẩn bị mua dịch vụ, IT Helpdesk requirements checklist vì vậy không chỉ là tài liệu thu thập thông tin. Nó là bước đầu để biến nhu cầu vận hành thành một scope có thể khảo sát, đánh giá, so sánh và triển khai.
Nguồn tham khảo
