Bỏ qua menu, vào nội dung chính

Helpdesk là gì: bộ phận hỗ trợ IT và cách đọc điều khoản hỗ trợ trong hợp đồng phần mềm

Helpdesk là đầu mối tiếp nhận và xử lý yêu cầu hỗ trợ kỹ thuật. Bài giải thích helpdesk bằng lời thường, cách điều khoản hỗ trợ hiện ra trong hợp đồng phần mềm: giờ hỗ trợ, kênh, mức ưu tiên, thời gian phản hồi khác thời gian xử lý, câu nên hỏi và khi nào không cần gói hỗ trợ cao.

9 phút đọc

Helpdesk là đầu mối tiếp nhận và xử lý yêu cầu hỗ trợ kỹ thuật: nhân viên hay khách hàng gặp sự cố thì báo về một chỗ, mỗi yêu cầu được ghi thành một phiếu (ticket), phân loại, giao người xử lý và theo dõi tới khi xong. Chữ này chỉ cả bộ phận hỗ trợ IT trong công ty lẫn dịch vụ hỗ trợ mà nhà cung cấp phần mềm bán kèm hợp đồng. Nhận định của bài: trong điều khoản hỗ trợ, con số "phản hồi trong 4 giờ" gần như luôn là thời gian trả lời đầu tiên tính theo giờ làm việc của nhà cung cấp, không phải thời gian sửa xong; thứ quyết định công ty được hỗ trợ tốt hay không là định nghĩa mức ưu tiên và lúc đồng hồ bắt đầu chạy.

Bài viết cho người ký hợp đồng phần mềm hoặc hợp đồng thuê ngoài IT: chủ doanh nghiệp, giám đốc vận hành, người phụ trách IT. Bài tập trung vào điều khoản hỗ trợ khi có sự cố; cam kết thời gian hoạt động của hệ thống và mức bồi hoàn là một chủ đề riêng, được bàn trong tập về SLA của series.

Nghĩa bằng lời thường: quầy tiếp nhận có sổ theo dõi

Hình dung một phòng khám. Bệnh nhân không đi thẳng vào phòng bác sĩ mà qua quầy tiếp nhận: ghi tên, triệu chứng, mức độ khẩn cấp, rồi được xếp số. Ca cấp cứu vào trước, ca khám thường chờ theo lượt. Helpdesk là quầy tiếp nhận đó cho sự cố công nghệ. Phiếu hỗ trợ là tờ phiếu khám: có mã số, thời điểm tạo, người báo, mô tả, mức ưu tiên, người đang xử lý và trạng thái.

Helpdesk thường chia tầng. Tầng một nhận yêu cầu, xử lý việc đơn giản như đặt lại mật khẩu, hướng dẫn thao tác. Tầng hai là kỹ thuật viên hiểu sâu hệ thống, xử lý lỗi cấu hình, dữ liệu. Tầng ba là người viết phần mềm hoặc hãng sản xuất, sửa lỗi trong mã. Khi đọc hợp đồng, câu cần hỏi là yêu cầu của công ty được tầng nào nhận, và mất bao lâu để lên tới tầng có thể sửa được.

Phân biệt ba thứ hay bị gọi chung là "hỗ trợ": hỗ trợ khi có sự cố (phần của helpdesk), bảo trì định kỳ như cập nhật, vá lỗi bảo mật, sao lưu (thường là một gói riêng), và phát triển thêm tính năng (không thuộc hỗ trợ, tính theo báo giá riêng). Rất nhiều tranh chấp bắt đầu từ chỗ bên mua tưởng yêu cầu "thêm một cột vào báo cáo" nằm trong gói hỗ trợ.

Điều khoản hỗ trợ trong hợp đồng: năm con số phải có

Một điều khoản hỗ trợ đầy đủ trả lời năm câu: hỗ trợ qua kênh nào, trong giờ nào, yêu cầu được xếp mức ưu tiên ra sao, mỗi mức được phản hồi và xử lý trong bao lâu, và gói bao gồm bao nhiêu yêu cầu hoặc bao nhiêu giờ công. Thiếu một trong năm, điều khoản đó khó dùng khi có tranh chấp.

Trang chính sách hỗ trợ công khai của GitLab là một ví dụ viết rõ ràng. Gói Priority Support chia yêu cầu thành bốn mức theo ảnh hưởng: khẩn cấp khi hệ thống không dùng được (phản hồi đầu tiên trong 30 phút, 24 giờ mọi ngày), suy giảm nặng khi tính năng quan trọng không dùng được và không có cách vòng (4 giờ), ảnh hưởng vừa (8 giờ), ảnh hưởng thấp (24 giờ); ba mức sau tính trong khung 24x5. Trang ghi rõ đây là thời gian phản hồi đầu tiên và không được coi là thời gian giải quyết dự kiến.

Bảng Priority Support trên trang GitLab Support: cột Support Impact, First Response Time SLA, Hours, How to submit; Emergency 30 phút 24x7, Highly Degraded 4 giờ 24x5, Medium Impact 8 giờ 24x5, Low Impact 24 giờ 24x5
Mức ưu tiên và thời gian phản hồi đầu tiên trong gói Priority Support của GitLab: 30 phút cho sự cố khẩn cấp (24x7), 4, 8 và 24 giờ cho các mức thấp hơn (24x5). Ảnh chụp support.gitlab.com ngày 26/09/2026.

Đọc bảng đó theo góc người mua ở Việt Nam, có ba điều đáng rút ra. Thứ nhất, mỗi mức ưu tiên có định nghĩa bằng chữ gắn với ảnh hưởng tới công việc, không để bên nào tự gán. Thứ hai, chỉ mức khẩn cấp mới được hỗ trợ ngoài giờ; mọi mức còn lại chờ giờ làm việc. Thứ ba, cam kết là thời gian trả lời, không phải thời gian sửa xong. Hợp đồng của nhà cung cấp trong nước thường ngắn hơn nhiều, nhưng cùng ba câu hỏi đó áp dụng được.

Giờ hỗ trợ: 8x5, 24x5, 24x7 và múi giờ của ai

8x5 là tám giờ mỗi ngày, năm ngày mỗi tuần; 24x5 là cả ngày trong năm ngày làm việc; 24x7 là mọi lúc. Chữ viết tắt chưa đủ: cần ghi múi giờ, ngày bắt đầu và kết thúc tuần, và lịch nghỉ lễ áp dụng. GitLab định nghĩa 24x5 là từ 15 giờ Chủ nhật tới 17 giờ thứ Sáu theo giờ Thái Bình Dương, và giờ làm việc của khu vực châu Á Thái Bình Dương là 09:00 tới 21:00 giờ Brisbane, thứ Hai tới thứ Sáu. Quy ra giờ Việt Nam, khung đó là 06:00 tới 18:00.

Mục Hours of Operation trên trang GitLab Support: định nghĩa 24x5 từ 3 giờ chiều Chủ nhật tới 5 giờ chiều thứ Sáu giờ Thái Bình Dương, 24x7 cho hỗ trợ khẩn cấp; giờ làm việc theo khu vực APAC 09:00 tới 21:00 AEST Brisbane, EMEA 08:00 tới 18:00 CET, AMER 05:00 tới 17:00 PT, thứ Hai tới thứ Sáu
Giờ hỗ trợ được định nghĩa kèm múi giờ: khung APAC của GitLab là 09:00 tới 21:00 giờ Brisbane, tức 06:00 tới 18:00 giờ Việt Nam. Ảnh chụp support.gitlab.com ngày 26/09/2026.

Với nhà cung cấp trong nước, câu hỏi múi giờ không đặt ra, nhưng câu hỏi ngày nghỉ thì có. Một cam kết "xử lý trong 10 ngày làm việc" cho yêu cầu gửi ngày 01/02/2027 sẽ kết thúc vào 19/02/2027, không phải 10/02/2027, vì khoảng đó có năm ngày nghỉ Tết và hai ngày nghỉ bù theo lịch lao động. Công cụ đếm ngày làm việc của ALODEV tính sẵn khoảng này.

Công cụ Tính ngày trên alodev.vn/lab/tinh-ngay, thẻ Ngày làm việc, từ 01/02/2027 tới 19/02/2027, lịch thứ Hai tới thứ Sáu: kết quả 10 ngày làm việc, tổng số ngày 19, ngày lễ Tết 5, nghỉ bù hoán đổi 2; ngày lễ trong khoảng 04/02 tới 08/02/2027
Mười ngày làm việc tính từ 01/02/2027 kéo tới 19/02/2027 vì kỳ nghỉ Tết: 19 ngày lịch, 5 ngày lễ Tết, 2 ngày nghỉ bù. Ảnh chụp alodev.vn/lab/tinh-ngay ngày 26/09/2026, dữ liệu ví dụ.

Đồng hồ chạy từ lúc nào và dừng lúc nào

Thời gian phản hồi chỉ có nghĩa khi hợp đồng ghi rõ đồng hồ bắt đầu khi nào: lúc gửi email, lúc gọi điện, hay lúc phiếu được tạo trên cổng hỗ trợ. Nhiều nhà cung cấp chỉ tính yêu cầu gửi qua cổng phiếu; một tin nhắn Zalo cho kỹ thuật viên quen không làm đồng hồ chạy. Nếu công ty quen báo lỗi qua điện thoại, cần thống nhất ai sẽ tạo phiếu cho cuộc gọi đó.

Đồng hồ cũng có thể tạm dừng khi phiếu chuyển sang trạng thái "chờ khách hàng", ví dụ khi kỹ thuật viên hỏi thêm ảnh chụp màn hình. Điều đó hợp lý, nhưng nên có giới hạn và thông báo rõ ràng, để phiếu không nằm im ở trạng thái chờ mà bên mua không biết mình đang được chờ.

Sau thời gian phản hồi còn hai mốc đáng ghi vào hợp đồng hơn: thời gian đưa ra cách khắc phục tạm để công việc chạy lại, và thời gian sửa triệt để hoặc có kế hoạch sửa. Với sự cố làm dừng bán hàng, mốc khắc phục tạm mới là thứ quyết định công ty mất bao nhiêu doanh thu.

Câu nên hỏi nhà cung cấp về điều khoản hỗ trợ

  1. Mức ưu tiên được định nghĩa thế nào, bằng ví dụ cụ thể từ phần mềm của chúng tôi? Khi hai bên không đồng ý về mức, ai quyết định?
  2. Thời gian cam kết là phản hồi đầu tiên, khắc phục tạm hay sửa xong? Mỗi mức ưu tiên có mấy mốc?
  3. Giờ hỗ trợ là 8x5, 24x5 hay 24x7? Ngày lễ, Tết Việt Nam tính thế nào? Sự cố khẩn cấp ngoài giờ gọi ai?
  4. Kênh nào làm đồng hồ bắt đầu chạy: cổng phiếu, email, điện thoại? Tin nhắn qua ứng dụng chat có được tính không?
  5. Gói bao gồm bao nhiêu phiếu hoặc bao nhiêu giờ công mỗi tháng? Vượt thì tính giá nào? Yêu cầu nào bị coi là phát triển thêm?
  6. Hằng tháng chúng tôi có nhận báo cáo số phiếu, thời gian phản hồi thật, phiếu quá hạn không?
  7. Khi nhà cung cấp trễ cam kết nhiều lần, hợp đồng có chế tài hoặc quyền chấm dứt không?

Bài đàm phán retainer bảo trì với nhà cung cấp liệt kê thêm các điều khoản về phạm vi, số giờ và gia hạn cho hợp đồng bảo trì trọn gói; hai bài đọc cùng nhau cho một bức tranh đủ hơn về phần hậu mãi của hợp đồng phần mềm.

Khi nào không cần gói hỗ trợ cao

  • Phần mềm không nằm trên đường doanh thu: công cụ nội bộ ít người dùng, dừng một ngày không ai mất tiền. Gói 8x5 với thời gian phản hồi một ngày làm việc là đủ, gói 24x7 là trả tiền cho sự yên tâm không cần thiết.
  • Công ty có người nội bộ xử lý được tầng một và tầng hai: chỉ cần mua hỗ trợ tầng ba cho lỗi trong mã, rẻ hơn gói trọn.
  • Dịch vụ phổ thông có sẵn trang trạng thái và cộng đồng lớn: với phần mềm văn phòng đại trà, gói hỗ trợ cao cấp hiếm khi làm sự cố được sửa nhanh hơn, vì sự cố chung của mọi khách hàng được hãng xử lý như nhau.

Ngược lại, phần mềm bán hàng, thanh toán, chấm công tính lương, hay bất kỳ hệ thống nào mà dừng một buổi là mất doanh thu hoặc sai lương, đáng được trả thêm cho mức khẩn cấp có hỗ trợ ngoài giờ và mốc khắc phục tạm rõ ràng. Mức ưu tiên cao nhất chỉ có giá trị khi định nghĩa của nó khớp đúng với tình huống thật làm công ty mất tiền.

Câu hỏi thường gặp

Helpdesk và service desk khác nhau thế nào?

Helpdesk thường chỉ đầu mối xử lý sự cố và yêu cầu hỗ trợ. Service desk rộng hơn, là điểm liên lạc chung cho mọi yêu cầu dịch vụ IT như cấp tài khoản, cấp thiết bị, thay đổi hệ thống. Trong hợp đồng ở Việt Nam, hai chữ thường được dùng thay nhau, nên cần đọc phạm vi cụ thể.

Ticket là gì?

Ticket (phiếu hỗ trợ) là bản ghi của một yêu cầu: mã số, thời điểm tạo, người báo, mô tả, mức ưu tiên, người xử lý và trạng thái. Nhờ có phiếu, cả hai bên đo được thời gian phản hồi và xử lý thật.

Thời gian phản hồi và thời gian xử lý khác nhau thế nào?

Thời gian phản hồi là từ lúc gửi yêu cầu tới lúc nhà cung cấp trả lời lần đầu. Thời gian xử lý là tới lúc sự cố được khắc phục. Nhiều hợp đồng chỉ cam kết phản hồi; GitLab ghi rõ thời gian cam kết của họ không phải thời gian giải quyết dự kiến.

Hỗ trợ 24x7 có cần thiết không?

Chỉ cần cho hệ thống mà dừng ngoài giờ gây thiệt hại thật, như bán hàng online, thanh toán, vận hành ca đêm. Nhiều gói chỉ hỗ trợ 24x7 cho mức khẩn cấp, còn yêu cầu thường chờ giờ làm việc.

Helpdesk khác SLA ở đâu?

Điều khoản helpdesk nói về cách tiếp nhận và xử lý yêu cầu hỗ trợ: kênh, giờ, mức ưu tiên, thời gian phản hồi. SLA thường rộng hơn, gồm cả cam kết thời gian hoạt động của hệ thống và mức bồi hoàn khi không đạt.

Từ điển công nghệ cho chủ doanh nghiệp10 phút đọc

Mã QR là gì: QR thanh toán, QR tĩnh, QR động và VietQR cho doanh nghiệp

Mã QR là cách đóng gói một đoạn dữ liệu (đường link, số tài khoản, nội dung chuyển khoản) thành hình vuông chấm đen trắng để máy quét đọc trong một giây. Bài giải thích QR tĩnh khác QR động ở đâu, VietQR vận hành thế nào, và câu nên hỏi trước khi dùng QR để thu tiền khách.

Từ điển công nghệ cho chủ doanh nghiệp9 phút đọc

OCR là gì: đọc chữ từ ảnh hoá đơn, chứng từ, và chỗ máy hay đọc sai

OCR là công nghệ nhận dạng ký tự trong ảnh rồi biến thành văn bản gõ được. Bài giải thích OCR bằng lời thường, cách nó hiện ra trong báo giá phần mềm kế toán, vì sao vẫn cần OCR dù đã có hoá đơn điện tử, chỗ máy hay đọc sai, câu nên hỏi nhà cung cấp, và khi nào không cần.

Từ điển công nghệ cho chủ doanh nghiệp10 phút đọc

Phần mềm đóng gói (SaaS) hay viết theo yêu cầu: so chi phí ba năm, không chỉ giá tháng đầu

So sánh đúng giữa SaaS đóng gói và phần mềm viết theo yêu cầu không phải giá tháng đầu, mà là tổng chi phí trong ba năm. Bài dùng một ví dụ số hoàn toàn giả định để chỉ ra các khoản chi phí hai bên hay giấu, và câu nên hỏi trước khi chọn đường nào cho doanh nghiệp.

Nhận bài mới

Để lại email để nhận bài mới của series Từ điển công nghệ cho chủ doanh nghiệp, hoặc theo dõi bằng RSS.

RSS Từ điển công nghệ cho chủ doanh nghiệp

Email chỉ dùng để gửi bài mới, xem Chính sách bảo mật.

Trao đổi về dự án

Cần tư vấn?