Hợp đồng phát triển phần mềm: Hướng dẫn đầy đủ + Mẫu miễn phí

Hầu hết các dự án phần mềm thất bại không phải vì lập trình viên kém. Chúng thất bại vì không ai ghi chép lại "hoàn thành" nghĩa là gì. Báo cáo CHAOS của Standish Group cho thấy tỷ lệ thành công của các dự án phần mềm chỉ đạt 31% — và các bất đồng về phạm vi công việc, quyền sở hữu IP không rõ ràng, và tranh chấp về điều khoản thanh toán là những nguyên nhân phổ biến nhất.

Một hợp đồng phát triển phần mềm khắc phục tất cả những vấn đề đó trước khi công việc bắt đầu. Đây là hợp đồng giữa khách hàng và lập trình viên (hoặc công ty) xác định phần mềm sẽ được xây dựng như thế nào, ai sở hữu nó, chi phí là bao nhiêu, và điều gì xảy ra khi có sự cố. Không có hợp đồng, bạn đang dựa vào lòng tin và trí nhớ — và tòa án không chấp nhận cả hai.

Hướng dẫn này bao gồm mọi thứ: khi nào bạn cần hợp đồng phát triển phần mềm, bốn loại hợp đồng và khi nào sử dụng từng loại, mọi điều khoản thực sự quan trọng, và một mẫu tải miễn phí bạn có thể tùy chỉnh cho dự án của mình. Nếu bạn đã biết những điều cơ bản và muốn đi thẳng đến mẫu, hãy chuyển đến phần mẫu. Nếu không, ngữ cảnh rất quan trọng — đặc biệt là phần IP, nơi mà hầu hết các hợp đồng thầm lặng thất bại. Để có cái nhìn rộng hơn về sự khác biệt giữa hợp đồng và thỏa thuận, hướng dẫn so sánh hợp đồng vs thỏa thuận của chúng tôi bao gồm các khác biệt pháp lý đáng biết.

Hợp đồng phát triển phần mềm (SDA) là một hợp đồng ràng buộc pháp lý giữa khách hàng và lập trình viên hoặc công ty phát triển phần mềm. Nó xác định phạm vi công việc, cấu trúc thanh toán, lộ trình giao hàng, quyền sở hữu trí tuệ, điều khoản bảo mật, và điều gì xảy ra nếu một trong hai bên cần chấm dứt hợp đồng.

SDA không phải là đề xuất, bản tóm tắt dự án, hay đoạn tin nhắn Slack xác nhận công việc. Đó là hồ sơ pháp lý chính thức về những gì cả hai bên đã đồng ý trước khi phát triển bắt đầu. Một khi đã ký, đó là tài liệu bạn sẽ tham khảo nếu có tranh chấp — và là tài liệu tòa án sẽ đọc nếu sự việc đi đến đó.

SDA bao gồm những gì

Một hợp đồng phát triển phần mềm được soạn thảo đúng cách sẽ giải quyết:

• Phạm vi công việc — lập trình viên sẽ xây dựng gì, với độ cụ thể đủ để một bên thứ ba có thể đánh giá mức độ hoàn thành
• Sản phẩm bàn giao và cột mốc — những gì được giao, dưới hình thức nào, và vào thởi điểm nào
• Điều khoản thanh toán — tổng phí, lịch thanh toán, và điều gì kích hoạt mỗi lần thanh toán
• Quyền sở hữu IP — ai sở hữu mã nguồn sau khi viết xong
• Bảo mật — thông tin độc quyền nào mỗi bên phải giữ bí mật
• Kiểm thử nghiệm thu — khách hàng đánh giá phần mềm đã giao có đáp ứng yêu cầu hay không như thế nào
• Bảo đảm — lập trình viên đảm bảo gì về chức năng của phần mềm
• Điều kiện chấm dứt — mỗi bên có thể kết thúc hợp đồng như thế nào và điều gì xảy ra với công việc đã hoàn thành

Một số khách hàng nhầm lẫn SDA với Statement of Work. Có sự chồng chéo, nhưng chúng không giống nhau — và sự khác biệt này quan trọng. Mối quan hệ giữa MSA và SOW giải thích cách các tài liệu này hoạt động cùng nhau trong các hợp đồng dài hạn.

Câu trả lởi ngắn gọn: bất cứ khi nào bạn trả tiền cho ai đó để xây dựng phần mềm, hoặc nhận tiền để xây dựng phần mềm.

Hợp đồng quan trọng dù bạn đang thuê một freelancer cá nhân cho dự án hai tuần hay ký hợp đồng với một công ty 20 ngưởi cho sản phẩm kéo dài 12 tháng. Quy mô thay đổi; nhu cầu có điều khoản bằng văn bản thì không.

Bạn nên có hợp đồng phát triển phần mềm khi:

• Bạn thuê ngoài phát triển phần mềm — đặc biệt là với các đội ngũ nước ngoài hoặc làm việc từ xa, nơi sự khác biệt về thẩm quyền pháp lý làm phức tạp các thỏa thuận không chính thức
• Phần mềm tùy chỉnh đang được xây dựng — công việc càng đặc biệt, quyền sở hữu IP càng cần được ghi rõ trong tài liệu
• Có nhiều giai đoạn phát triển — thanh toán theo cột mốc yêu cầu các tiêu chí nghiệm thu bằng văn bản để kích hoạt mỗi giai đoạn
• Dữ liệu hoặc hệ thống nhạy cảm được liên quan — bất kỳ dự án nào chạm đến dữ liệu khách hàng đều cần điều khoản bảo mật và bảo mật thông tin
• Bạn đang phát triển dựa trên các framework độc quyền — mã nguồn có sẵn được tích hợp vào sản phẩm tùy chỉnh tạo ra các câu hỏi phức tạp về quyền sở hữu nếu không có hợp đồng rõ ràng
• Bạn làm việc xuyên biên giới — luật điều chỉnh và thẩm quyền tòa án phải được chỉ định khi lập trình viên và khách hàng ở các quốc gia khác nhau

Tình huống duy nhất bạn có thể làm việc mà không cần SDA đầy đủ: công việc rất ngắn, giá trị thấp được điều chỉnh bởi một thỏa thuận dịch vụ chính (MSA) toàn diện đã bao gồm tất cả các điều khoản liên quan. Nhưng ngay cả khi đó, hầu hết các luật sư cũng khuyên bạn nên làm thủ tục giấy tờ.

Không có mẫu SDA duy nhất phù hợp với mọi dự án. Cấu trúc hợp đồng cần phù hợp với cách dự án được định giá và xác định phạm vi — và việc chọn cấu trúc sai tạo ra các động lực đi ngược lại kết quả tốt.

Hợp đồng giá cố định

Một SDA giá cố định hiệu quả khi yêu cầu dự án ổn định và được hiểu rõ trước khi phát triển bắt đầu. Lập trình viên cam kết giao phạm vi xác định với tổng phí đã thỏa thuận. Sự chắc chắn về ngân sách là lợi ích chính cho khách hàng. Rủi ro: nếu yêu cầu hóa ra bị mô tả không đầy đủ, lập trình viên hoặc phải gánh chi phí vượt ngân sách hoặc tranh chấp bắt đầu.

Hợp đồng thởi gian và vật tư

Hợp đồng T&M phù hợp cho các dự án khám phá, sản phẩm giai đoạn đầu, hoặc bất kỳ tình huống nào không thể xác định toàn bộ phạm vi từ đầu. Khách hàng trả tiền cho số giờ thực tế làm việc theo tỷ lệ đã thỏa thuận. Bạn có được sự linh hoạt; đánh đổi là sự không chắc chắn về chi phí. Giới hạn ngân sách và trần chi phí hàng tháng giúp quản lý rủi ro đó.

Hợp đồng đội ngũ chuyên dụng

Đối với các công ty cần một đội kỹ sư từ xa ổn định — thay vì giao dự án một lần — hợp đồng đội ngũ chuyên dụng thiết lập điều khoản cho một mối quan hệ liên tục. Quản lý hợp đồng cho công ty IT thường sử dụng mô hình này khi làm việc với các đối tác thuê ngoài.

Cấu trúc MSA + SOW

Các dự án lớn hơn thường tách khung pháp lý chính (MSA) khỏi các điều khoản theo từng dự án (SOW). MSA bao gồm IP, bảo mật, trách nhiệm pháp lý và giải quyết tranh chấp một lần; mỗi SOW bao gồm sản phẩm bàn giao cụ thể, lộ trình và thanh toán cho một dự án cụ thể.

Không phải tất cả các điều khoản đều có trọng lượng như nhau. Đây là những điều khoản mà việc thiếu hoặc ngôn ngữ mơ hồ gây ra tranh chấp trong thực tế.

1. Phạm vi công việc và sản phẩm bàn giao

Mô tả những gì được xây dựng với độ chi tiết đủ để một ngưởi không tham gia dự án có thể đánh giá liệu nó đã được giao hay chưa. Yêu cầu chức năng, thông số kỹ thuật, nền tảng được hỗ trợ, và các tiêu chuẩn hiệu suất đều thuộc về phần này. Nêu rõ ràng những gì nằm ngoài phạm vi.

Phạm vi mơ hồ là nguồn gốc phổ biến nhất của các tranh chấp phần mềm. "Xây dựng một website" không phải là phạm vi. "Xây dựng một ứng dụng React/Next.js đáp ứng với các tính năng được liệt kê trong Phụ lục A, đạt điểm hiệu suất Lighthouse 90+ trên thiết bị di động" mới là phạm vi.

2. Điều khoản thanh toán và lịch cột mốc

Liệt kê mọi khoản thanh toán: số tiền, sự kiện kích hoạt, và phương thức thanh toán. Các khoản thanh toán theo cột mốc nên được gắn với sản phẩm đã được nghiệm thu, không chỉ ngày trên lịch. Xác định loại tiền tệ, khung thởi gian thanh toán (Net-15 hoặc Net-30 là tiêu chuẩn), và khoản phạt thanh toán chậm.

3. Quyền sở hữu trí tuệ

Đây là điều khoản mà hầu hết khách hàng đọc quá nhanh. Ai sở hữu mã nguồn tùy chỉnh? Ai sở hữu mã nguồn có sẵn mà lập trình viên tích hợp? Phần mềm nguồn mở có được bao gồm không? Phần IP của SDA xác định ai có thể sử dụng, sửa đổi, bán hoặc cấp phép phần mềm sau khi giao hàng. Làm sai và hậu quả rất đắt đỏ — xem vụ án Cadence v. Avanti trong phần IP bên dưới.

4. Bảo mật

SDA nên bao gồm các nghĩa vụ bảo mật lẫn nhau. Lập trình viên không được tiết lộ dữ liệu khách hàng hoặc logic kinh doanh độc quyền; khách hàng không được tiết lộ quy trình hoặc công cụ độc quyền của lập trình viên. Để có các điều khoản NDA mạnh mẽ hơn trong một thỏa thuận độc lập, hướng dẫn NDA cho công ty phần mềm đáng đọc song song với hướng dẫn này.

5. Kiểm thử nghiệm thu

Xác định cách khách hàng đánh giá và chấp nhận từng sản phẩm bàn giao. Cửa sổ xem xét (5–10 ngày làm việc là phổ biến), định dạng phản hồi, tiêu chí đạt, và điều gì xảy ra nếu khách hàng không phản hồi trong cửa sổ xem xét (nghiệm thu được cho là đã xảy ra).

6. Bảo đảm

Lập trình viên nên bảo đảm rằng phần mềm sẽ hoạt động như đã chỉ định, rằng mã nguồn là nguyên bản (hoặc được cấp phép đúng cách), và rằng việc giao hàng sẽ không xâm phạm quyền IP của bên thứ ba. Một thởi hạn bảo đảm cho việc sửa lỗi sau khi giao hàng — thường là 30–90 ngày — bảo vệ khách hàng khỏi các lỗi phát hiện sau khi ra mắt.

7. Điều kiện chấm dứt

Mỗi bên nên có thể rút lui với thông báo hợp lý. Xác định thởi gian thông báo (30 ngày là tiêu chuẩn), điều gì xảy ra với công việc đang tiến hành, và cách tính khoản thanh toán cuối cùng khi chấm dứt sớm. Một điều khoản chấm dứt vì lý do (bao gồm vi phạm nghiêm trọng, phá sản, hoặc không thanh toán) nên tách biệt với chấm dứt theo thuận tiện.

8. Luật điều chỉnh và thẩm quyền

Nêu tên quốc gia và bang/vùng có luật điều chỉnh hợp đồng. Khi lập trình viên và khách hàng ở các quốc gia khác nhau, điều khoản này quyết định tòa án nào sẽ xử lý tranh chấp. Đừng bỏ qua vì nó có vẻ hình thức — đây là một trong những điều khoản quan trọng nhất về mặt thực tiễn trong hợp đồng xuyên biên giới.

Sử dụng mẫu này làm nền tảng cho hợp đồng của bạn. Thay thế tất cả các trường trong ngoặc vuông bằng các điều khoản cụ thể của bạn. Đối với các dự án phức tạp, hãy thuê một luật sư phần mềm để xem xét phiên bản cuối cùng — đặc biệt là các phần IP và bảo đảm.

Đối với các công ty IT quản lý hợp đồng với nhiều đối tác phát triển, việc tập trung tất cả các SDA trong một hệ thống quản lý tài liệu duy nhất — với lịch sử phiên bản và chữ ký chống giả mạo — loại bỏ sự hỗn loạn của việc gửi tài liệu Word qua lại bằng email.

Mẫu ở trên có hơn một tá trường cần hoàn thành. Đây là cách tiếp cận từng trường mà không để lại khoảng trống gây tranh chấp sau này.

Bước 1: Xác định phạm vi trước khi chạm vào hợp đồng

Đừng mở mẫu cho đến khi bạn đã ghi chép lại phần mềm thực sự cần làm gì. Yêu cầu chức năng, ràng buộc kỹ thuật, nền tảng được hỗ trợ, phụ thuộc tích hợp — tất cả. Phần phạm vi của SDA chỉ tốt bằng tài liệu đặc tả đằng sau nó.

Đối với các dự án phức tạp, đính kèm đặc tả đầy đủ làm Phụ lục A và tham chiếu từ điều khoản phạm vi. Điều này giữ cho hợp đồng chính dễ đọc trong khi đảm bảo chi tiết kỹ thuật đầy đủ được đính kèm pháp lý.

Bước 2: Xây dựng lịch cột mốc

Làm việc ngược từ ngày giao hàng. Chia dự án thành các giai đoạn — khám phá, thiết kế, phát triển, kiểm thử, triển khai — và gán số tiền và ngày đến hạn cho mỗi giai đoạn. Các khoản thanh toán theo giai đoạn nên tương đối phù hợp với giá trị được giao ở mỗi giai đoạn.

Cảnh báo: việc này mất nhiều thởi gian hơn hầu hết các bên mong đợi, đặc biệt là trong các hợp đồng đầu tiên. Dự trù 1-2 giờ với cả hai bên hiện diện để xác định đúng cột mốc và thanh toán.

Bước 3: Giải quyết quyền sở hữu IP một cách rõ ràng

Đọc kỹ Phần 3 và điền tất cả các chỗ trống. Nếu lập trình viên đang sử dụng các framework hoặc công cụ độc quyền mà họ đã xây dựng trước dự án này, hãy liệt kê chúng trong phần loại trừ công việc có sẵn. Nếu bạn đang sử dụng thư viện nguồn mở, hãy nêu tên các giấy phép.

Điều khoản chuyển nhượng công việc tùy chỉnh (Phần 3.1) thường là điều khoản quan trọng nhất đối với khách hàng: đó là điều chuyển quyền sở hữu mã nguồn đã giao từ lập trình viên sang bạn. Đừng để nó mơ hồ.

Bước 4: Thiết lập cửa sổ xem xét và tiêu chí nghiệm thu

Quyết định cửa sổ xem xét trước khi bạn điền vào. Mười ngày làm việc là phổ biến. Hai tuần cho khách hàng bận rộn đủ thởi gian để thực sự kiểm tra sản phẩm bàn giao; bất kỳ khoảng thởi gian nào ngắn hơn đều có xu hưởng tạo ra tranh chấp khi ngưởi đánh giá đang đi công tác hoặc bận việc khác.

Đối với Phần 5, các tiêu chí nghiệm thu thuộc về Phụ lục A. Hãy viết các tiêu chí cụ thể, có thể kiểm tra: "Ứng dụng di động tải bảng điều khiển trong vòng dưới 3 giây trên kết nối 4G" tốt hơn "ứng dụng nên nhanh".

Bước 5: Chọn luật điều chỉnh một cách có chủ đích

Đối với các dự án trong nước, sử dụng bang/quốc gia của lập trình viên (họ quen thuộc hơn với tòa án địa phương). Đối với các dự án xuyên biên giới, một trong hai bên có thể thích thẩm quyền trung lập. Luật Delaware phổ biến cho các hợp đồng công nghệ tại Mỹ; luật Anh thường được sử dụng cho các thỏa thuận công nghệ quốc tế. Dù bạn chọn gì, cả hai bên cần đồng ý rõ ràng — đừng để trống phần này.

Bước 6: Ký bằng chữ ký điện tử tuân thủ

Một hình ảnh quét chữ ký viết tay trên PDF về mặt pháp lý yếu ớt ở hầu hết các thẩm quyền. Chữ ký điện tử tạo ra hàm băm tài liệu và chứng chỉ hoàn thành có dấu thởi gian khó bác bỏ hơn nhiều. Theo Đạo luật ESIGN và UETA tại Hoa Kỳ, và eIDAS tại Liên minh Châu Âu, chữ ký điện tử có đầy đủ hiệu lực pháp lý cho các thỏa thuận thương mại. Nền tảng ký nên ràng buộc mỗi chữ ký với hàm băm mật mã của tài liệu — để mọi sửa đổi sau khi ký được phát hiện ngay lập tức.

Hầu hết các mẫu đều bao gồm những điều cơ bản. Đây là các điều khoản thường bị loại khỏi các hợp đồng rẻ hoặc soạn nhanh — và thường quan trọng nhất khi có sự cố xảy ra.

Kiểm thử nghiệm thu với tiêu chí đạt/trượt

Phần 5 trong mẫu ở trên xác định *khi nào* và *như thế nào* khách hàng xem xét sản phẩm bàn giao. Điều mà hầu hết các hợp đồng bỏ qua: các tiêu chí thực tế để đạt. Không có các tiêu chí đạt/trượt có thể đo lường, việc nghiệm thu trở thành một cuộc đàm phán. Khách hàng luôn có thể tranh luận phần mềm chưa "đủ tốt." Hãy viết tiêu chí khách quan trong Phụ lục A trước khi phát triển bắt đầu.

Ký gửi mã nguồn (Source code escrow)

Nếu doanh nghiệp của bạn phụ thuộc vào phần mềm tùy chỉnh và lập trình viên phá sản, bạn cần quyền truy cập vào mã nguồn. Điều khoản ký gửi mã nguồn yêu cầu lập trình viên gửi mã nguồn cho một bên ký gửi trung lập. Nếu lập trình viên ngừng hoạt động hoặc vi phạm nghiêm trọng hợp đồng, bên ký gửi sẽ phát hành mã nguồn cho khách hàng. Hầu hết khách hàng không bao giờ nghĩ đến việc yêu cầu điều này — cho đến khi họ cần.

Thởi hạn trách nhiệm sau khi giao hàng

Phần 7 giới hạn tổng trách nhiệm pháp lý, nhưng nhiều mẫu không đề cập đến cửa sổ thởi gian. Trách nhiệm khi nào kết thúc? Nếu một lỗi gây mất dữ liệu 18 tháng sau khi giao hàng, lập trình viên có còn chịu trách nhiệm không? Hãy xác định rõ ràng thởi hạn bảo đảm và cửa sổ trách nhiệm sau bảo đảm. Sau thởi hạn bảo đảm, nghĩa vụ duy nhất của lập trình viên thường là khắc phục các lỗi do họ gây ra — không phải lỗi do khách hàng sửa đổi gây ra.

Quy trình kiểm soát thay đổi

Phần 9 yêu cầu một Change Order đã ký cho các thay đổi phạm vi. Điều mà hầu hết các hợp đồng bỏ sót: xác định ai có thẩm quyền ký Change Order. Nếu một quản lý dự án bên khách hàng yêu cầu bằng miệng một tính năng mới và lập trình viên xây dựng nó, lập trình viên có được trả tiền không? Chỉ khi quy trình Change Order được tuân thủ. Hãy nêu tên các vai trò cụ thể (không phải cá nhân, vì chức danh có thể thay đổi) có thẩm quyền phê duyệt thay đổi.

Tuân thủ giấy phép nguồn mở

Linux Foundation báo cáo rằng 92% phần mềm thương mại chứa các thành phần nguồn mở. Mỗi giấy phép của thành phần áp đặt các điều kiện về cách phần mềm có thể được sử dụng, sửa đổi và phân phối. Một thư viện được cấp phép GPL, chẳng hạn, có thể kích hoạt nghĩa vụ copyleft buộc bạn phải mở mã nguồn độc quyền của mình. SDA nên yêu cầu lập trình viên tiết lộ tất cả các thành phần nguồn mở và xác nhận tính tương thích với mục đích sử dụng dự kiến của khách hàng.

Quyền sở hữu IP là điều khoản mà hầu hết khách hàng lướt qua — và là điều khoản có hậu quả lớn nhất nếu làm sai.

Vụ án Cadence v. Avanti: bài học 265 triệu USD

Năm 2002, một tòa án California phát hiện Avanti Corporation đã sử dụng mã nguồn Cadence bị đánh cắp trong một sản phẩm cạnh tranh. Khoản bồi thường lên tới 265 triệu USD. Vụ án này thường được trích dẫn trong các vụ kiện IP phần mềm vì nó minh họa điều gì xảy ra khi quyền sở hữu mã nguồn bị tranh chấp hoặc, tệ hơn, khi mã nguồn không bao giờ nên được tích hợp vào sản phẩm lại xuất hiện ở đó. Một điều khoản IP được soạn thảo tốt không chỉ xác định ai sở hữu sản phẩm cuối cùng — nó còn yêu cầu lập trình viên bảo đảm rằng không có IP của bên thứ ba nào bị tích hợp trái phép.

Bốn mô hình IP

Công việc có sẵn vs. công việc tùy chỉnh

Hầu hết các lập trình viên mang theo các công cụ, framework và thư viện họ đã xây dựng trước khi dự án của bạn bắt đầu. Đây là "các tác phẩm có sẵn" hoặc "IP nền tảng." SDA nên xác định rõ ràng công việc có sẵn nào sẽ được tích hợp và cấp cho khách hàng giấy phép sử dụng nó như một phần của phần mềm đã giao — mà không chuyển quyền sở hữu các công cụ cơ bản đó.

Để tìm hiểu sâu hơn về cách chuyển nhượng IP hoạt động trong hợp đồng lập trình viên cá nhân, hướng dẫn thỏa thuận chuyển nhượng IP cho lập trình viên bao gồm cơ chế chuyển giao và cấp phép quyền sở hữu mã nguồn.

Nguyên tắc work-for-hire

Tại Hoa Kỳ, mã nguồn được viết bởi nhân viên trong phạm vi công việc của họ tự động là work-for-hire, thuộc sở hữu của nhà tuyển dụng. Mã nguồn được viết bởi nhà thầu độc lập *không* tự động là work-for-hire — nhà thầu giữ bản quyền trừ khi hợp đồng tường minh chuyển nhượng nó. Sự khác biệt này khiến khách hàng nhầm lẫn khi cho rằng họ sở hữu mã nguồn vì đã trả tiền cho nó. Họ không sở hữu, nếu không có điều khoản chuyển nhượng.

Ba tài liệu này thường xuyên bị nhầm lẫn. Mỗi tài liệu có vai trò riêng biệt, và việc sử dụng sai — hoặc trộn lẫn chúng — tạo ra các khoảng trống trách nhiệm.

Đối với các dự án một lần, một SDA độc lập (như mẫu trong hướng dẫn này) bao gồm mọi thứ. Đối với các hợp đồng liên tục với đối tác phát triển — nơi bạn chạy nhiều dự án theo thởi gian — cấu trúc MSA + SOW hiệu quả hơn. MSA thương lượng khung pháp lý một lần; mỗi dự án thêm một SOW mới. Hướng dẫn đầy đủ về Statement of Work của chúng tôi bao gồm cấu trúc SOW chi tiết.

Việc có một SDA đã ký từng có nghĩa là in, quét, gửi email, và hy vọng phiên bản của bên kia khớp với của bạn. Không có lý do chính đáng nào để làm như vậy nữa.

Điều gì làm cho chữ ký điện tử hợp lệ về mặt pháp lý

Theo Đạo luật ESIGN (Mỹ) và eIDAS (EU), chữ ký điện tử hợp lệ về mặt pháp lý cho các thỏa thuận thương mại khi nó:

• Được áp dụng bởi ngưởi có ý định ký
• Được liên kết với tài liệu cụ thể đang được ký
• Có khả năng quy cho ngưởi ký
• Bản ghi được lưu trữ dưới hình thức có thể truy xuất sau này

Chữ ký mật mã đi xa hơn: mỗi chữ ký được ràng buộc toán học với hàm băm của tài liệu. Thay đổi một ký tự sau khi ký, và hàm băm thay đổi, khiến việc giả mạo được phát hiện ngay lập tức. Tính không thể chối bỏ này làm cho hợp đồng có thể bảo vệ trước tòa — không bên nào có thể sau này tuyên bố tài liệu đã bị thay đổi.

Quy trình ký hoạt động như thế nào

Quản lý tài liệu cho công ty IT thường xuyên chạy nhiều SDA, SOW và NDA đồng thởi. Một quy trình chuyên dụng ngăn chặn cơn ác mộng kiểm soát phiên bản đến từ việc ký qua email:

1. 1.
   Tải SDA đã hoàn thiện lên nền tảng quản lý hợp đồng
2. 2.
   Thêm địa chỉ email của mỗi ngưởi ký và thứ tự ký
3. 3.
   Mỗi bên nhận được liên kết ký an toàn — không cần tài khoản để ký
4. 4.
   Chữ ký được áp dụng; nền tảng tạo chứng chỉ hoàn thành với dấu thởi gian, địa chỉ IP, và hàm băm tài liệu
5. 5.
   Cả hai bên tự động nhận được tài liệu đã thực thi đầy đủ
6. 6.
   Nhật ký kiểm toán được lưu trữ bất biến, có thể truy cập để tham khảo hoặc giải quyết tranh chấp trong tương lai

Thanh toán theo cột mốc được liên kết với việc ký

Tính năng hữu ích nhất trong một nền tảng hợp đồng hiện đại không phải là bản thân chữ ký — mà là việc kết nối chữ ký với những gì xảy ra tiếp theo. Khi lập trình viên giao một cột mốc và khách hàng ký biểu mẫu nghiệm thu, kích hoạt thanh toán tự động kích hoạt. Không còn đuổi theo hóa đơn thủ công, không còn nhầm lẫn "tôi tưởng bạn sẽ gửi hóa đơn riêng." Đối với các đội ngũ quản lý thanh toán liên kết với hợp đồng, điều này loại bỏ khoảng cách giữa nghiệm thu và lập hóa đơn.

Để biết chi tiết định giá các gói quản lý hợp đồng, trang giá của Chaindoc bao gồm những gì có trong mỗi cấp.