Bài này không thay thế ý kiến luật sư. Nó là danh sách những chỗ mà chúng tôi thấy hợp đồng phần mềm ở Việt Nam hay bỏ trống — và mỗi chỗ bỏ trống sau này đều thành một cuộc tranh luận không có bên nào sai rõ ràng.
1. Phạm vi viết bằng câu kiểm tra được
Phụ lục phạm vi nên là danh sách việc hệ thống làm được, mô tả từ phía người dùng: "kế toán xuất được báo cáo công nợ theo tuổi nợ, lọc theo nhóm khách hàng, tải về Excel". Câu nào không thể kiểm tra bằng cách bấm thử thì viết lại.
Song song, nên có mục ngoài phạm vi liệt kê rõ những gì KHÔNG làm. Mục này bảo vệ cả hai bên và thường bị bỏ vì ngại.
2. Tiêu chí nghiệm thu và thời hạn phản hồi
Ai nghiệm thu, dựa trên kịch bản nào, trong bao nhiêu ngày? Và điều quan trọng không kém: nếu bên mua không phản hồi trong thời hạn thì coi như thế nào?
Thiếu điều khoản này, dự án dễ treo vô thời hạn ở đợt nghiệm thu cuối vì người phụ trách bận — và bên làm không có cơ sở để đóng dự án.
3. Quyền sở hữu mã nguồn và thư viện bên thứ ba
Ghi rõ: mã nguồn do đội phát triển viết cho dự án thuộc về bên mua sau khi thanh toán đủ. Đồng thời ghi rõ những thành phần không thuộc về bên mua — thư viện mã nguồn mở, các dịch vụ thuê bao — và giấy phép của chúng.
Bỏ vế thứ hai là chỗ hay gây hiểu lầm: bên mua tưởng mình sở hữu mọi thứ, kể cả nền tảng dùng chung của bên bán.
4. Dữ liệu là của ai và lấy ra thế nào
Điều khoản này quan trọng hơn cả điều khoản mã nguồn với hầu hết doanh nghiệp. Cần ghi:
- Dữ liệu vận hành thuộc quyền của bên mua, không giới hạn.
- Bên mua yêu cầu xuất toàn bộ dữ liệu bất kỳ lúc nào, dưới định dạng chuẩn đọc được (ví dụ CSV hoặc bản sao lưu cơ sở dữ liệu), trong bao nhiêu ngày làm việc.
- Sau khi chấm dứt hợp đồng, bên bán xoá dữ liệu trong bao lâu và xác nhận bằng văn bản.
5. Bảo hành: bao lâu và gồm những gì
"Bảo hành 12 tháng" là câu chưa đủ. Cần phân biệt rõ ba loại việc và cách xử lý từng loại:
| Loại | Ví dụ | Thuộc bảo hành? |
|---|---|---|
| Lỗi | Tính sai công nợ, không in được hoá đơn | Có, sửa miễn phí |
| Thay đổi yêu cầu | Thêm một trường mới vào biểu mẫu | Không, báo giá riêng |
| Hỗ trợ sử dụng | Hướng dẫn nhân viên mới thao tác | Tuỳ thoả thuận, nên ghi rõ số giờ |
Kèm theo nên có cam kết thời gian phản hồi theo mức nghiêm trọng: lỗi chặn toàn bộ nghiệp vụ phản hồi trong bao lâu, lỗi nhỏ trong bao lâu.
6. Hỗ trợ sau bảo hành
Ghi trước mức phí hỗ trợ hằng năm hoặc đơn giá giờ công sau khi hết bảo hành. Không ghi thì một năm sau bạn đàm phán ở vị thế yếu, vì lúc đó chỉ có đúng một đơn vị hiểu hệ thống.
7. Điều kiện chấm dứt và chuyển giao
Điều khoản không ai muốn dùng nhưng cần có: nếu hợp tác không tiếp tục, hai bên xử lý thế nào? Nên có tối thiểu ba điểm:
- 1Thanh toán cho phần công việc đã hoàn thành và được nghiệm thu tới thời điểm dừng.
- 2Bàn giao mã nguồn, tài liệu và dữ liệu ở trạng thái hiện tại trong bao nhiêu ngày.
- 3Một giai đoạn chuyển giao có trả phí, đủ để đội mới tiếp nhận — thường 2–4 tuần.
Điều khoản chấm dứt tốt là điều khoản khiến cả hai bên yên tâm ký, chứ không phải điều khoản khiến một bên sợ rời đi.
Ở SealCore, các điểm về mã nguồn, dữ liệu và bàn giao là điều khoản mặc định trong hợp đồng chứ không phải tuỳ chọn tính thêm phí — lý do đầy đủ ở bài Bàn giao mã nguồn.
Cần bàn cụ thể?
SealCore khảo sát tại doanh nghiệp bạn và báo giá trọn gói sau buổi đầu tiên — kể cả khi kết luận là bạn chưa cần viết phần mềm riêng.
