Giải pháp phần mềm cho doanh nghiệp đọc hợp đồng SLA trước khi ký cần chú ý những gì? Đây là câu hỏi chúng tôi gặp rất thường xuyên khi làm việc với khách hàng. Phần lớn hợp đồng SLA nằm ở trang cuối trong bộ hồ sơ nhà cung cấp gửi qua. Không ít chủ doanh nghiệp ký ngay mà chưa đọc kỹ.
Nhiều người coi đây chỉ là một thủ tục đi kèm. Vì vậy điều khoản này thường bị xem nhẹ hơn giá cả hay danh sách tính năng. Thực tế, SLA mới là phần quyết định bạn được bảo vệ đến đâu khi hệ thống gặp sự cố. Một bản cam kết mơ hồ có thể khiến bạn mất doanh thu mà không có cách nào đòi lại.
Chúng tôi từng tư vấn cho một khách hàng vận hành chuỗi cửa hàng thời trang. Phần mềm quản lý kho của họ bị treo đúng mùa cao điểm cuối năm. Đơn hàng dồn ứ, nhân viên không kiểm được tồn kho thực tế. Nhà cung cấp im lặng gần hai ngày mới cử người xử lý.
Lúc đó khách hàng mới lục lại hợp đồng để xem mức bồi thường ra sao. Họ nhận ra bản hợp đồng đã ký từ đầu gần như không bảo vệ được gì cho mình. Đó là bài học đắt giá mà chúng tôi luôn nhắc lại với mọi khách hàng sau này.
SLA Là Gì Và Vì Sao Phần Mềm Nào Cũng Đi Kèm Điều Khoản Này
SLA là viết tắt của Service Level Agreement, hiểu đơn giản là bản cam kết mức dịch vụ giữa hai bên. Văn bản này ghi rõ nhà cung cấp hứa điều gì với khách hàng. Nó cũng nêu họ phải chịu trách nhiệm ra sao nếu không làm đúng cam kết.
Với hầu hết giải pháp phần mềm cho doanh nghiệp hiện nay, SLA gần như luôn đi kèm hợp đồng chính. Đây là chuẩn chung của ngành, không phải dấu hiệu nghi ngờ nhà cung cấp. Vấn đề nằm ở chỗ nội dung cụ thể có đủ bảo vệ bạn hay không.
Phần này lại là phần ít người đọc kỹ nhất. Ngôn ngữ trong đó khá kỹ thuật nên dễ khiến người đọc nản. Thêm vào đó là tâm lý muốn ký nhanh cho xong thủ tục, bởi ai cũng sốt ruột muốn triển khai hệ thống ngay.
Điều khó là doanh nghiệp thường không biết điều khoản nào cần dừng lại để hỏi thêm. Đội pháp lý bên cung cấp soạn hợp đồng theo hướng có lợi cho họ trước, đó là chuyện bình thường trong ngành. Nhưng nếu bên mua không nắm rõ luật chơi, phần thiệt gần như luôn rơi về phía doanh nghiệp.
Một dấu hiệu chúng tôi luôn để ý là nhà cung cấp mới thành lập. Loại này thường chưa có khách hàng tham chiếu rõ ràng để hỏi thăm. Với trường hợp đó, chúng tôi khuyên nên xin liên hệ của ít nhất hai khách cũ và trao đổi trước khi ký.
Trước cả bước đó, doanh nghiệp cần xác định đúng phần mềm mình thực sự cần. Chúng tôi từng phân tích khá kỹ điều này trong bài về việc doanh nghiệp nhỏ nên số hóa từ phần mềm nào trước. Chọn sai công cụ ngay từ đầu thì đọc SLA kỹ đến đâu cũng khó cứu vãn, vì vấn đề vận hành về sau vẫn sẽ phát sinh.
SaaS Thuê Bao Và Phần Mềm Đặt Riêng: SLA Không Giống Nhau
Doanh nghiệp nên phân biệt rõ hai loại này. SLA của phần mềm thuê bao theo tháng thường khác khá nhiều so với phần mềm đặt làm riêng. Với SaaS, nhà cung cấp phục vụ hàng trăm khách cùng lúc trên một hạ tầng chung, nên mức cam kết thường cố định và ít chỗ để đàm phán riêng.
Ngược lại, với phần mềm đặt làm riêng, doanh nghiệp có nhiều dư địa hơn để yêu cầu điều chỉnh. Quy mô và ngân sách của từng bên sẽ quyết định mức cam kết nào là phù hợp. Một gói SLA nâng cao thường cộng thêm khoảng 10–20% giá trị hợp đồng mỗi năm. Không phải doanh nghiệp nào cũng cần mức cao nhất ngay từ đầu.
Quan trọng là biết mình đang trả thêm tiền để đổi lấy điều gì cụ thể. Đừng chọn gói chỉ vì tên gọi nghe có vẻ an tâm hơn. Hãy hỏi thẳng: nếu sự cố xảy ra, gói này bảo vệ bạn ở đâu, và bạn nhận được gì bằng tiền?
Đọc Kỹ Hợp Đồng SLA Giúp Doanh Nghiệp Tránh Rủi Ro Nào
Nhiều người nghĩ SLA chỉ có ý nghĩa khi sự cố xảy ra. Thực ra nó quyết định cách hai bên làm việc với nhau mỗi ngày. Đọc kỹ phần này trước khi ký giúp doanh nghiệp hiểu chính xác mình đang cam kết những gì, và đâu là phần mình được bảo vệ.
Lý do đầu tiên là bảo vệ quyền lợi khi nhà cung cấp không làm đúng lời hứa. Hãy hình dung phần mềm bán hàng sập đúng giờ cao điểm cuối tuần. Việc này gây mất doanh thu thật sự cho cửa hàng. Nếu hợp đồng không quy định rõ mức bồi thường, doanh nghiệp gần như chịu thiệt một mình.
Lý do thứ hai nằm ở những điều khoản bất lợi giấu trong phụ lục dài. Có hợp đồng ghi uptime 99%, đọc vào nghe rất yên tâm. Nhưng phần phụ lục lại loại trừ khá nhiều trường hợp như bảo trì theo lịch, sự cố mạng của bên thứ ba, hay lỗi phát sinh từ dữ liệu do khách tự nhập. Cộng dồn lại, con số 99% trên giấy có thể khác xa thực tế vận hành.
Vì vậy chúng tôi luôn khuyên khách hàng đọc phần phụ lục kỹ hơn cả phần nội dung chính. Rủi ro thường nằm ở những dòng chữ nhỏ chứ không phải điều khoản in đậm. Khi đàm phán, bạn hoàn toàn có thể yêu cầu nhà cung cấp bỏ bớt các điều khoản loại trừ không hợp lý. Nhiều đơn vị sẵn sàng điều chỉnh nếu khách hỏi đúng chỗ.
Việc đàm phán cũng sẽ dễ hơn nhiều nếu doanh nghiệp đã xác định rõ nhu cầu thật sự từ trước. Bên mình từng phân tích thời điểm doanh nghiệp nhỏ thực sự cần đầu tư phần mềm CRM. Logic tương tự áp dụng khi cân nhắc mức cam kết dịch vụ nào là vừa đủ dùng.
Những Điều Khoản Đáng Đọc Chậm Nhất Trong Hợp Đồng SLA
Đây là phần chúng tôi khuyên đọc chậm nhất. Một số nhóm điều khoản dưới đây thường quyết định phần lớn rủi ro về sau, và cũng là chỗ dễ bị bỏ sót nhất khi đọc vội để kịp ký.
- Thời gian uptime cam kết: tỷ lệ hệ thống hoạt động ổn định mỗi tháng, kèm danh sách các trường hợp không tính là gián đoạn. Phần loại trừ này quan trọng hơn con số in đậm.
- Thời gian phản hồi hỗ trợ: thường chia theo mức độ sự cố, từ lỗi nhẹ cho tới sự cố làm sập cả hệ thống. Hãy hỏi thẳng quy trình xử lý ticket trong thực tế.
- Mức bồi thường khi vi phạm: phần lớn tính bằng phần trăm giảm phí của tháng đó, hiếm khi hoàn tiền mặt.
- Quyền chấm dứt hợp đồng sớm: thường áp dụng khi nhà cung cấp vi phạm liên tục, chẳng hạn từ ba tháng liên tiếp trở lên.
- Quy trình leo thang khi sự cố kéo dài: có đơn vị chỉ định quản lý cấp cao trực tiếp tiếp nhận nếu đội hỗ trợ thông thường không xử lý kịp.
- Thời điểm bắt đầu tính downtime: có hợp đồng chỉ tính từ lúc khách báo lỗi, chứ không tính từ lúc hệ thống thật sự ngừng hoạt động.
Sai lầm chúng tôi gặp nhiều nhất là doanh nghiệp chỉ nhìn con số uptime rồi bỏ qua phần loại trừ phía dưới. Một hợp đồng ghi 99,9% nghe rất chắc chắn, nhưng nếu phần loại trừ liệt kê cả chục trường hợp thì con số đó gần như mất hết ý nghĩa.
Hãy coi phần loại trừ như một phần của chính cam kết. Trước khi ký, bạn nên tự hỏi: nếu sự cố xảy ra vì một trong những lý do bị loại trừ, ai sẽ chịu trách nhiệm? Câu trả lời ấy mới cho biết hợp đồng thực sự bảo vệ bạn đến đâu.
Một Lần Bỏ Qua SLA Khiến Khách Hàng Của Chúng Tôi Phải Trả Giá
Chúng tôi muốn kể thêm một tình huống thực tế, vì nó minh hoạ rõ nhất những điều vừa nói. Khách hàng này kinh doanh thời trang, vừa có cửa hàng offline vừa bán online. Họ thuê một đơn vị nhỏ viết phần mềm quản lý đơn hàng riêng, giá khá mềm so với mặt bằng chung.
Hợp đồng SLA lúc ký chỉ vỏn vẹn nửa trang, ghi chung chung rằng hệ thống sẽ hoạt động ổn định. Không có con số uptime cụ thể, cũng không có mức bồi thường rõ ràng khi có sự cố. Khách lúc đó không để ý, vì tin vào mối quan hệ quen biết với bên cung cấp. Họ nghĩ có chuyện gì thì nhắn một tiếng là được xử lý ngay.
Đến giữa năm, hệ thống gặp lỗi đồng bộ dữ liệu giữa kho offline và kênh online. Đơn hàng bị trùng, có lúc báo hết hàng dù kho thực tế vẫn còn. Khách nhận đơn xong không giao được hàng và phàn nàn liên tục trên fanpage. Vì hợp đồng không ràng buộc trách nhiệm, bên cung cấp chỉ hứa khắc phục sớm mà không đưa ra mốc thời gian nào.
Sự việc kéo dài gần một tuần mới ổn định. Uy tín cửa hàng bị ảnh hưởng nặng hơn nhiều so với khoản tiền thuê phần mềm. Sau đó bên mình được mời vào đánh giá lại toàn bộ hệ thống, và việc đầu tiên chúng tôi đề nghị là soạn lại hợp đồng SLA cho rõ ràng. Bài học khá đơn giản: giá rẻ không phải vấn đề, vấn đề là hợp đồng không bảo vệ được doanh nghiệp khi có chuyện.
Trước Khi Ký, Chúng Tôi Thường Khuyên Khách Hàng Làm Điều Này
Hợp đồng SLA không phải văn bản để ký cho có. Đây là công cụ bảo vệ doanh nghiệp khi mọi thứ không suôn sẻ như kỳ vọng. Chúng tôi luôn khuyên dành riêng một buổi để rà lại phần này trước khi ký chính thức.
Tốt nhất nên có người phụ trách kỹ thuật ngồi cùng buổi rà soát đó. Người này thường nhìn ra những điều khoản mơ hồ mà người làm kinh doanh dễ bỏ qua, ví dụ cách tính thời gian downtime, hay ai là người xác nhận sự cố đã được khắc phục. Nếu công ty chưa có nhân sự kỹ thuật riêng, có thể nhờ một bên tư vấn độc lập xem giúp.
Bên mình cũng đã tổng hợp các bước cụ thể trong checklist kỹ thuật khi thuê ngoài dự án phần mềm. Phần lớn các bước đó áp dụng được khi rà soát điều khoản SLA. Có doanh nghiệp ngại tốn thêm chi phí thuê người xem lại hợp đồng, nhất là khi giá trị không lớn. Nhưng hãy so với thiệt hại nếu hệ thống sập giữa mùa cao điểm mà không đòi được bồi thường.
Nếu thấy điều khoản nào còn mơ hồ, hãy mạnh dạn hỏi lại bằng văn bản và giữ lại câu trả lời, vì nó có thể trở thành bằng chứng hữu ích nếu tranh chấp xảy ra. Một hợp đồng SLA rõ ràng ngay từ đầu giúp cả hai bên làm việc thoải mái hơn. Quan trọng hơn, nó giúp doanh nghiệp tránh được không ít rắc rối đúng lúc cần hệ thống ổn định nhất. Hãy dành thời gian đọc kỹ trước khi ký, bởi chi phí của việc đọc vội thường lớn hơn bạn nghĩ.