Mẫu hợp đồng thiết kế website bất động sản: Khung đầy đủ + phụ lục nghiệm thu

Một hợp đồng thiết kế website bất động sản tốt không cần dài hàng chục trang chỉ để tạo cảm giác “chuyên nghiệp”. Điều quan trọng hơn là hợp đồng phải trả lời rõ những câu hỏi thực tế:

• Bên thiết kế phải làm những gì?
• Những gì không nằm trong phạm vi?
• Khi nào được coi là hoàn thành?
• Ai chịu trách nhiệm cung cấp nội dung?
• Mã nguồn, giao diện và dữ liệu được xử lý thế nào?
• Lead khách hàng được lưu và truy cập ra sao?
• Khi phát sinh tính năng mới thì tính phí thế nào?
• Sau bàn giao ai chịu trách nhiệm khi website lỗi?

Đây chính là những điểm thường gây tranh luận khi một dự án thiết kế website bất động sản đi từ báo giá sang triển khai thực tế.

Bài viết dưới đây cung cấp một mẫu khung hợp đồng thực hành, kèm Scope of Work, Acceptance Criteria, Change Request và Checklist bàn giao. Bạn có thể sử dụng làm cơ sở trao đổi với đơn vị thiết kế, sau đó điều chỉnh theo dự án thực tế và nhờ bộ phận pháp chế hoặc luật sư rà soát trước khi ký.

Lưu ý trước khi sử dụng mẫu

• Đây là mẫu tham khảo, không thay thế ý kiến tư vấn pháp lý cho một giao dịch cụ thể.
• Website môi giới cá nhân, website một dự án và website sàn có phạm vi công việc rất khác nhau.
• Các điều khoản về quyền tác giả, dữ liệu cá nhân, thuế, phạt vi phạm, bồi thường và giải quyết tranh chấp cần được điều chỉnh theo chủ thể và giao dịch thực tế.
• Không nên ký hợp đồng mà phần phạm vi chỉ ghi chung chung như “thiết kế website theo yêu cầu”.

Phần A – Mẫu khung hợp đồng thiết kế website BĐS

HỢP ĐỒNG CUNG CẤP DỊCH VỤ THIẾT KẾ VÀ PHÁT TRIỂN WEBSITE

Số: …/HĐTKWEB/…

Căn cứ nhu cầu và khả năng của các bên, hôm nay, ngày … tháng … năm …, các bên gồm:

Điều 1. Thông tin các bên

1.1. Bên A – Khách hàng

• Tên doanh nghiệp/cá nhân: …
• Mã số thuế/CCCD hoặc thông tin pháp lý phù hợp: …
• Địa chỉ: …
• Người đại diện: …
• Chức vụ: …
• Điện thoại: …
• Email dùng cho giao dịch hợp đồng: …
• Tài khoản ngân hàng: …

1.2. Bên B – Đơn vị cung cấp dịch vụ

• Tên doanh nghiệp/cá nhân: …
• Mã số thuế/CCCD hoặc thông tin pháp lý phù hợp: …
• Địa chỉ: …
• Người đại diện: …
• Chức vụ: …
• Điện thoại: …
• Email dùng cho giao dịch hợp đồng: …
• Tài khoản ngân hàng: …

Khuyến nghị: ghi rõ email hoặc hệ thống nào được coi là kênh xác nhận chính thức đối với duyệt giao diện, Change Request, nghiệm thu và các thông báo quan trọng.

Điều 2. Giải thích thuật ngữ

Để giảm tranh luận trong quá trình triển khai, nên định nghĩa một số thuật ngữ ngay trong hợp đồng.

• Website: hệ thống website thuộc phạm vi của hợp đồng này.
• Production: môi trường website chính thức phục vụ người dùng.
• Staging: môi trường thử nghiệm trước khi đưa thay đổi lên Production.
• Template: mẫu bố cục dùng để hiển thị một loại trang.
• Feature: chức năng được mô tả trong Scope of Work.
• Source Code: phần mã nguồn thuộc phạm vi sản phẩm bàn giao theo thỏa thuận.
• Third-party Component: theme, plugin, thư viện, font, API hoặc dịch vụ do bên thứ ba cung cấp.
• Lead: thông tin người dùng được thu thập qua form hoặc các chức năng thuộc phạm vi website.
• UAT: giai đoạn Bên A kiểm thử chấp nhận sản phẩm.
• Acceptance Criteria: điều kiện dùng để xác định một hạng mục đã hoàn thành.
• Change Request: yêu cầu thay đổi ngoài phạm vi đã được thống nhất.

Điều 3. Mục tiêu dự án

Bên B thực hiện thiết kế và phát triển website BĐS nhằm phục vụ các mục tiêu đã được Bên A thống nhất, ví dụ:

• Giới thiệu thương hiệu;
• Giới thiệu dự án;
• Quản lý danh sách bất động sản;
• Thu lead;
• Hỗ trợ SEO;
• Phục vụ quảng cáo;
• Kết nối CRM;
• Hỗ trợ đội sales.

Nên ghi mục tiêu chính vào hợp đồng vì nó giúp hai bên đánh giá Change Request sau này có nằm trong phạm vi ban đầu hay không.

Điều 4. Phạm vi công việc

Bên B thực hiện các công việc được mô tả chi tiết tại:

Phụ lục 01 – Scope of Work.

Phụ lục phải là một phần không tách rời của hợp đồng.

Scope tối thiểu nên làm rõ:

• Số template;
• Tính năng;
• Responsive;
• CMS;
• Dữ liệu BĐS;
• Form;
• SEO nền tảng;
• Tracking;
• Hosting;
• Nhập liệu;
• Đào tạo;
• Bàn giao.

Điều 5. Hạng mục không bao gồm

Đây là điều khoản rất nên có.

Ví dụ:

• Viết nội dung ngoài số lượng đã thỏa thuận;
• Chụp ảnh/quay video;
• Chi phí quảng cáo;
• Dịch vụ SEO dài hạn;
• CRM license;
• API trả phí;
• Plugin/theme license ngoài danh sách;
• Nhập liệu vượt số lượng quy định;
• Tính năng mới phát sinh sau khi duyệt scope.

Ghi rõ “không bao gồm” thường giảm tranh chấp hiệu quả hơn việc chỉ liệt kê những gì “có”.

Điều 6. Thiết kế UI/UX

Cần quy định:

• Số lượng template được thiết kế;
• Desktop/mobile;
• Wireframe có nằm trong scope không;
• Số phương án thiết kế ban đầu;
• Số vòng chỉnh sửa;
• Thời hạn Bên A phản hồi;
• Cách xác nhận bản thiết kế đã chốt.

Ví dụ:

Bên B thực hiện 06 template giao diện theo Phụ lục 01. Mỗi template bao gồm tối đa 02 vòng chỉnh sửa sau khi gửi phương án đầu tiên. Yêu cầu thay đổi cấu trúc sau khi UI đã được phê duyệt được xem xét theo quy trình Change Request.

Điều 7. Dữ liệu và chức năng đặc thù bất động sản

Nếu website có quản lý dự án hoặc tin đăng, hợp đồng nên chỉ rõ data model.

Ví dụ:

• Tên dự án;
• Khu vực;
• Loại hình;
• Giá;
• Diện tích;
• Trạng thái;
• Pháp lý;
• Chủ đầu tư;
• Vị trí;
• Gallery;
• Mặt bằng.

Nếu có bộ lọc, cần ghi rõ filter nào nằm trong scope.

Ví dụ:

Bộ lọc bao gồm khu vực, loại hình, khoảng giá, diện tích và trạng thái dự án. Các tiêu chí bổ sung ngoài danh sách trên được xem là yêu cầu phát sinh.

Điều 8. Nội dung và nhập liệu

Quy định rõ trách nhiệm từng bên.

Bên A có thể chịu trách nhiệm:

• Cung cấp logo;
• Brand guideline;
• Thông tin doanh nghiệp;
• Thông tin dự án;
• Giá;
• Pháp lý;
• Hình ảnh;
• Tài liệu bán hàng.

Bên B có thể chịu trách nhiệm:

• Nhập … dự án;
• Nhập … bài viết;
• Resize ảnh;
• Định dạng nội dung;
• Thiết lập SEO Meta theo phạm vi.

Đặc biệt cần xác định bên nào chịu trách nhiệm về tính chính xác và quyền sử dụng của nội dung BĐS được cung cấp.

Điều 9. Tiến độ và milestone

Không nên chỉ ghi:

“Thời gian thực hiện 30 ngày.”

Nên chia theo milestone.

Mốc	Sản phẩm	Thời hạn
M1	Yêu cầu + Scope/Wireframe	...
M2	Thiết kế UI	...
M3	Development trên staging	...
M4	UAT	...
M5	Go-live	...
M6	Bàn giao	...

Điều 10. Thời gian phản hồi của Bên A

Tiến độ website thường bị ảnh hưởng bởi thời gian chờ:

• Duyệt UI;
• Cung cấp nội dung;
• Cấp API;
• Gửi tài khoản;
• Phản hồi UAT.

Nên quy định:

Trường hợp Bên A phản hồi hoặc cung cấp dữ liệu chậm hơn thời hạn thống nhất, timeline tương ứng được điều chỉnh theo thời gian chậm và ảnh hưởng thực tế tới các hạng mục liên quan.

Điều 11. Nghiệm thu

Website chỉ nên được nghiệm thu dựa trên Acceptance Criteria cụ thể.

Không nên nghiệm thu theo cảm nhận:

“Website trông ổn.”

Có thể quy định:

Bên B thông báo hoàn thành hạng mục và cung cấp môi trường kiểm thử. Bên A thực hiện kiểm tra theo Phụ lục 02 – Acceptance Criteria và phản hồi các lỗi thuộc phạm vi bằng danh sách tập trung.

Điều 12. Phân loại lỗi khi nghiệm thu

Có thể chia:

Lỗi Critical

• Website không hoạt động;
• Không thể đăng nhập;
• Form chính không nhận lead;
• Dữ liệu quan trọng không hoạt động.

Lỗi Major

• Một chức năng chính hoạt động sai;
• Filter trả kết quả sai;
• Layout mobile lỗi nghiêm trọng.

Lỗi Minor

• Sai khoảng cách;
• Lỗi hiển thị nhỏ;
• Text cần điều chỉnh.

Việc phân loại giúp tránh tình trạng một lỗi nhỏ làm toàn bộ dự án không thể nghiệm thu.

Điều 13. Giá trị hợp đồng

Tổng giá trị hợp đồng:

… VNĐ.

Cần ghi rõ:

• Đã hay chưa bao gồm thuế;
• Có bao gồm license không;
• Có bao gồm hosting/domain không;
• Các khoản phí định kỳ;
• Các dịch vụ bên thứ ba.

Điều 14. Thanh toán theo milestone

Ví dụ tham khảo:

• Đợt 1: …% sau khi ký hợp đồng;
• Đợt 2: …% sau khi nghiệm thu UI;
• Đợt 3: …% sau khi hoàn thành staging/UAT;
• Đợt 4: …% sau go-live và bàn giao.

Tỷ lệ cụ thể do hai bên thỏa thuận.

Nên gắn thanh toán với sản phẩm đầu ra có thể xác định thay vì chỉ gắn với ngày tháng.

Điều 15. Change Request – thay đổi ngoài phạm vi

Đây là một trong những điều khoản quan trọng nhất.

Mọi yêu cầu ngoài Scope of Work được xử lý theo quy trình:

Yêu cầu → Phân tích → Ước tính chi phí/thời gian → Bên A phê duyệt → Triển khai.

Ví dụ:

Bên B không có nghĩa vụ thực hiện Change Request trước khi hai bên xác nhận phạm vi, ảnh hưởng tiến độ và chi phí bổ sung bằng hình thức đã thỏa thuận.

Điều 16. Các thay đổi không được coi là Change Request

Cũng nên quy định chiều ngược lại.

Ví dụ:

• Sửa lỗi khiến chức năng không đúng với Scope;
• Sửa lỗi responsive thuộc template đã nghiệm thu;
• Sửa chức năng không đáp ứng Acceptance Criteria.

Những việc này không nên bị biến thành “phát sinh” nếu vốn đã nằm trong phạm vi hợp đồng.

Điều 17. Mã nguồn, quyền tác giả và thành phần bên thứ ba

Không nên dùng một câu chung:

“Toàn bộ mã nguồn thuộc khách hàng.”

Thực tế website có thể gồm nhiều nhóm tài sản:

1. Code được Bên B viết riêng cho dự án;
2. Framework/code có trước của Bên B;
3. Open-source;
4. Theme/plugin thương mại;
5. Font;
6. Stock image;
7. API bên thứ ba.

Hợp đồng nên quy định riêng từng nhóm.

Ví dụ nguyên tắc

Sau khi Bên A hoàn thành nghĩa vụ thanh toán, quyền sử dụng/chuyển giao đối với phần sản phẩm được phát triển riêng cho dự án được thực hiện theo phạm vi hai bên thỏa thuận. Các thư viện, framework, theme, plugin, font, hình ảnh hoặc tài sản của bên thứ ba tiếp tục tuân theo điều kiện giấy phép tương ứng.

Điều 18. Code có trước của Bên B

Nếu đơn vị thiết kế sử dụng framework hoặc module đã có trước, nên ghi rõ:

• Bên A được quyền sử dụng ở mức nào;
• Có được chỉnh sửa không;
• Có được chuyển sang nhà cung cấp khác không;
• Bên B có tiếp tục được sử dụng framework đó cho khách hàng khác không.

Điều này bảo vệ cả hai bên.

Điều 19. Domain

Nếu domain là thương hiệu của Bên A, hợp đồng nên ưu tiên quyền kiểm soát của Bên A.

Cần xác định:

• Tài khoản đăng ký;
• Email chủ thể;
• Quyền thay đổi DNS;
• Quyền gia hạn;
• Quyền chuyển registrar;
• Trách nhiệm thanh toán gia hạn.

Điều 20. Hosting và hạ tầng

Nếu hosting nằm trong hợp đồng, ghi rõ:

• Thời hạn;
• Cấu hình;
• Dung lượng;
• Backup;
• SSL;
• Quyền truy cập;
• Chi phí gia hạn;
• Điều kiện chuyển hosting;
• Trách nhiệm quản trị server.

Không nên chỉ ghi:

“Tặng hosting 1 năm.”

Điều 21. Tài khoản và credential

Danh sách có thể gồm:

• Website admin;
• Domain;
• Hosting;
• CDN;
• Analytics;
• Search Console;
• Tag Manager;
• Maps API;
• Email;
• CRM;
• Repository.

Hợp đồng nên xác định:

• Tài khoản nào do Bên A sở hữu;
• Bên B được cấp quyền ở mức nào;
• Khi kết thúc hợp đồng, quyền của Bên B được thu hồi thế nào.

Điều 22. Dữ liệu lead và dữ liệu cá nhân

Thông tin như họ tên, số điện thoại, email và các dữ liệu khác thu từ form có thể là dữ liệu cá nhân.

Thay vì chỉ ghi:

“Lead thuộc sở hữu Bên A.”

hợp đồng nên làm rõ:

• Mục đích Bên B được phép xử lý dữ liệu;
• Loại dữ liệu;
• Hệ thống nào được phép truy cập;
• Ai quyết định mục đích và phương tiện xử lý;
• Bên B có vai trò xử lý dữ liệu như thế nào;
• Thời gian truy cập;
• Biện pháp bảo vệ;
• Bên thứ ba được sử dụng;
• Quy trình xử lý sự cố;
• Hoàn trả/xóa dữ liệu khi kết thúc dịch vụ;
• Trách nhiệm phối hợp khi có yêu cầu liên quan tới dữ liệu.

Với website có CRM, chatbot, email marketing, analytics hoặc dịch vụ cloud, phụ lục dữ liệu nên liệt kê cả các hệ thống liên quan.

Điều 23. Giới hạn quyền sử dụng dữ liệu

Có thể sử dụng nguyên tắc:

Bên B chỉ xử lý dữ liệu cá nhân trong phạm vi cần thiết để thực hiện dịch vụ đã thỏa thuận và không tự ý sử dụng dữ liệu cho mục đích marketing, bán hàng, xây tệp khách hàng hoặc mục đích khác của Bên B.

Điều 24. Sự cố dữ liệu và bảo mật

Hợp đồng nên xác định ít nhất:

• Kênh thông báo sự cố;
• Người liên hệ;
• Thời hạn thông báo nội bộ giữa hai bên;
• Nội dung thông tin cần cung cấp;
• Biện pháp containment;
• Phối hợp điều tra;
• Khôi phục dữ liệu;
• Nghĩa vụ pháp lý của từng bên theo trường hợp cụ thể.

Không nên ghi một cam kết tuyệt đối kiểu:

“Bên B đảm bảo website không bao giờ bị hack.”

Nên mô tả biện pháp, trách nhiệm và quy trình xử lý.

Điều 25. Backup và khôi phục

Nếu backup thuộc scope, ghi rõ:

• Backup file hay database;
• Tần suất;
• Retention;
• Nơi lưu;
• Ai có quyền restore;
• Restore có tính phí không;
• RPO/RTO nếu dự án có yêu cầu.

Điều 26. SEO nền tảng

Nếu hợp đồng có cụm từ “website chuẩn SEO”, phải biến nó thành checklist.

Ví dụ:

• URL có thể cấu hình;
• SEO Title;
• Meta Description;
• Heading;
• Canonical;
• XML sitemap;
• Robots;
• Breadcrumb;
• Alt ảnh;
• Internal link foundation;
• Quy tắc index đối với category/filter nếu có.

Không nên coi “chuẩn SEO” là cam kết thứ hạng.

Chi tiết có thể đối chiếu với hệ thống SEO website bất động sản.

Điều 27. Không cam kết thứ hạng nếu không có thỏa thuận SEO riêng

Có thể ghi:

Hạng mục SEO nền tảng trong hợp đồng là việc thiết lập các chức năng và cấu trúc kỹ thuật theo Scope of Work, không đồng nghĩa với cam kết website đạt thứ hạng cụ thể trên công cụ tìm kiếm, trừ khi hai bên có thỏa thuận dịch vụ SEO riêng.

Điều 28. Tracking và Analytics

Nếu nằm trong scope, ghi rõ:

• Công cụ nào được cài;
• Ai tạo tài khoản;
• Event nào được cấu hình;
• CTA nào được track;
• Form event nào được track;
• Có lưu UTM không;
• Ai nghiệm thu dữ liệu.

“Cài Analytics” không đồng nghĩa với “tracking toàn bộ funnel”.

Điều 29. Tích hợp CRM/API

Nên mô tả:

• API nào;
• Field mapping;
• Authentication;
• Lead được tạo ở đâu;
• Xử lý khi API lỗi;
• Retry có hay không;
• Logging;
• Trách nhiệm nếu API bên thứ ba thay đổi.

Điều 30. Hiệu năng

Nếu có cam kết hiệu năng, không nên chỉ ghi:

“Website chạy nhanh.”

Cần xác định:

• Template được test;
• Thiết bị;
• Hosting;
• Dữ liệu mẫu/thật;
• Third-party script;
• Điều kiện test.

Nếu sử dụng chỉ số hoặc ngưỡng cụ thể, hãy mô tả phương pháp đo.

Phần kỹ thuật có thể tham khảo quy trình tăng tốc website BĐS.

Điều 31. Bảo hành

Bảo hành nên được hiểu là sửa lỗi thuộc sản phẩm đã bàn giao.

Ví dụ phạm vi:

• Lỗi code custom;
• Feature không hoạt động như Acceptance Criteria;
• Lỗi responsive thuộc template đã bàn giao.

Thời hạn:

… tháng kể từ ngày nghiệm thu/go-live theo thỏa thuận.

Điều 32. Các trường hợp có thể không thuộc bảo hành

Ví dụ:

• Bên A hoặc bên thứ ba tự sửa source;
• Phát triển tính năng mới;
• API bên ngoài thay đổi;
• Hosting do bên khác quản trị gặp lỗi;
• License bên thứ ba hết hạn;
• Nội dung do người dùng nhập sai;
• Yêu cầu thiết kế mới ngoài Scope.

Từng ngoại lệ phải được viết hợp lý theo mô hình thực tế.

Điều 33. Bảo trì

Bảo trì không nên bị đồng nhất với bảo hành.

Dịch vụ bảo trì có thể gồm:

• Update CMS;
• Update plugin/theme;
• Backup;
• Monitoring;
• Kiểm tra bảo mật;
• Kiểm tra form;
• Khắc phục lỗi vận hành.

Nếu có phí định kỳ, cần ghi riêng.

Điều 34. SLA hỗ trợ

Nếu dự án cần SLA, có thể chia mức độ:

Mức	Ví dụ	Phản hồi mục tiêu
P1	Website down, form chính toàn hệ thống lỗi	...
P2	Một chức năng chính lỗi	...
P3	Lỗi hiển thị nhỏ	...

Phân biệt:

• Thời gian phản hồi;
• Thời gian bắt đầu xử lý;
• Thời gian mục tiêu khôi phục.

Không nên dùng ba khái niệm này như một.

Điều 35. Trách nhiệm của Bên A

Bên A có trách nhiệm theo phạm vi thỏa thuận:

• Cung cấp nội dung đúng hạn;
• Cung cấp thông tin chính xác;
• Có quyền sử dụng hình ảnh/tài liệu cung cấp;
• Phản hồi thiết kế đúng timeline;
• Cấp các credential cần thiết;
• Thanh toán đúng thỏa thuận;
• Chỉ định người có quyền phê duyệt.

Điều 36. Trách nhiệm của Bên B

Bên B có trách nhiệm:

• Triển khai theo Scope;
• Bảo mật thông tin;
• Thông báo rủi ro ảnh hưởng tiến độ;
• Khắc phục lỗi thuộc trách nhiệm;
• Không tự ý dùng dữ liệu ngoài phạm vi;
• Bàn giao đúng nội dung đã cam kết.

Điều 37. Nhà thầu phụ

Nếu Bên B sử dụng nhà thầu phụ cho:

• Hosting;
• Thiết kế;
• Lập trình;
• Cloud;
• Email;

hợp đồng có thể quy định:

• Phạm vi được thuê ngoài;
• Trách nhiệm của Bên B;
• Yêu cầu bảo mật;
• Yêu cầu xử lý dữ liệu nếu có.

Điều 38. Chậm tiến độ

Cần phân biệt:

• Chậm do Bên A;
• Chậm do Bên B;
• Chậm do Change Request;
• Chậm do bên thứ ba;
• Trường hợp bất khả kháng.

Nếu áp dụng phạt hoặc bồi thường, tỷ lệ và cách tính cần được các bên thống nhất và rà soát theo pháp luật áp dụng cho giao dịch cụ thể.

Điều 39. Giới hạn trách nhiệm và bồi thường

Đây là điều khoản cần được luật sư/pháp chế rà soát kỹ.

Có thể cần làm rõ:

• Loại thiệt hại;
• Điều kiện phát sinh trách nhiệm;
• Nghĩa vụ chứng minh;
• Các trường hợp loại trừ;
• Giới hạn trách nhiệm nếu được thỏa thuận hợp pháp.

Không nên copy một giới hạn trách nhiệm từ hợp đồng nước ngoài rồi áp dụng máy móc.

Điều 40. Tạm ngừng thực hiện hợp đồng

Có thể quy định các trường hợp như:

• Chậm thanh toán;
• Không cung cấp dữ liệu cần thiết;
• Yêu cầu có nguy cơ vi phạm pháp luật;
• Sự cố an toàn thông tin cần tạm dừng triển khai.

Quy trình thông báo cũng cần rõ.

Điều 41. Chấm dứt hợp đồng

Quy định:

• Trường hợp được chấm dứt;
• Thời hạn thông báo;
• Khối lượng được thanh toán;
• Công việc đang thực hiện;
• Dữ liệu;
• Tài khoản;
• Source;
• License;
• Backup;
• Credential;
• Nghĩa vụ bảo mật tiếp tục sau chấm dứt.

Điều 42. Exit Plan – kế hoạch chuyển giao khi ngừng hợp tác

Đây là điều khoản đặc biệt hữu ích với website vận hành lâu dài.

Có thể quy định Bên B hỗ trợ bàn giao:

• Source code thuộc phạm vi;
• Database export;
• Media;
• DNS record;
• Danh sách third-party services;
• Thông tin cấu hình;
• Backup;
• Tài liệu;
• Repository;
• Quyền tài khoản.

Nếu việc migration sang đơn vị khác có tính phí, cần nêu nguyên tắc tính phí.

Điều 43. Giao dịch và xác nhận bằng phương tiện điện tử

Nếu hai bên sử dụng email, hệ thống quản lý công việc, chữ ký điện tử hoặc nền tảng ký hợp đồng điện tử, nên xác định:

• Kênh nào được coi là chính thức;
• Ai có thẩm quyền xác nhận;
• Tài liệu nào bắt buộc ký;
• Change Request được duyệt bằng hình thức nào;
• Thời điểm một thông báo được coi là đã nhận.

Điều 44. Bất khả kháng

Điều khoản này nên được điều chỉnh theo giao dịch cụ thể và quy định:

• Trường hợp được coi là bất khả kháng;
• Nghĩa vụ thông báo;
• Nghĩa vụ giảm thiểu thiệt hại;
• Ảnh hưởng tới timeline;
• Quyền chấm dứt nếu kéo dài.

Điều 45. Giải quyết tranh chấp

Có thể quy định trình tự:

1. Đầu mối dự án thương lượng;
2. Đại diện có thẩm quyền thương lượng;
3. Hòa giải nếu các bên thống nhất;
4. Tòa án hoặc trọng tài theo thỏa thuận phù hợp.

Nên xác định rõ cơ chế giải quyết cuối cùng thay vì ghi cả “tòa án hoặc trọng tài” nhưng không xác định cách lựa chọn.

Điều 46. Hiệu lực

Ghi rõ:

• Ngày có hiệu lực;
• Thời hạn;
• Phụ lục là bộ phận của hợp đồng;
• Thứ tự ưu tiên nếu hợp đồng và phụ lục mâu thuẫn;
• Cách sửa đổi hợp đồng;
• Số bản hoặc hình thức điện tử.

Phần B – Phụ lục 01: Scope of Work mẫu

Hạng mục	Phạm vi	Số lượng	Tiêu chí
Wireframe	Trang chủ + template chính	...	Phê duyệt trước UI
UI	Desktop + mobile	... template	... vòng chỉnh sửa
Trang dự án	Template dữ liệu dự án	01 template	Theo field đã thống nhất
Danh mục	Danh sách dự án	...	Pagination/sort...
Filter	Khu vực, loại hình, giá...	01 module	Theo danh sách field
Form	Bảng giá, đặt lịch...	...	Validation + success
CRM	Webhook/API	...	Field mapping
SEO nền tảng	Meta, sitemap, canonical...	01 gói	Theo checklist
Tracking	CTA + form...	...	Theo event list
Nhập liệu	Dự án/bài viết	...	Bên ... cung cấp dữ liệu
Đào tạo	Quản trị website	... buổi	Online/offline

Phần C – Phụ lục 02: Acceptance Criteria mẫu

1. Giao diện

• [ ] Đúng template đã duyệt;
• [ ] Desktop đúng phạm vi trình duyệt cam kết;
• [ ] Mobile không cuộn ngang ngoài chủ đích;
• [ ] Menu hoạt động;
• [ ] CTA không che nội dung.

2. Trang dự án

• [ ] Các field hiển thị đúng;
• [ ] Gallery hoạt động;
• [ ] Mặt bằng hoạt động;
• [ ] Map theo scope;
• [ ] Dự án liên quan đúng logic.

3. Search/Filter

• [ ] Khu vực đúng;
• [ ] Loại hình đúng;
• [ ] Khoảng giá đúng;
• [ ] Reset hoạt động;
• [ ] Zero-result được xử lý;
• [ ] Mobile filter hoạt động.

4. Form và lead

• [ ] Required fields;
• [ ] Validation;
• [ ] Submit thành công;
• [ ] Lead được lưu/gửi đúng scope;
• [ ] CRM nhận đúng field nếu có;
• [ ] Context dự án đúng;
• [ ] UTM đúng nếu nằm trong scope;
• [ ] Chống spam hoạt động.

5. SEO nền tảng

• [ ] Title/Meta có thể quản trị;
• [ ] H1 đúng template;
• [ ] Canonical;
• [ ] Sitemap;
• [ ] Robots;
• [ ] Breadcrumb theo scope;
• [ ] URL đúng cấu trúc.

6. Bảo mật và vận hành

• [ ] HTTPS;
• [ ] Tài khoản quản trị;
• [ ] Backup theo scope;
• [ ] Quyền truy cập đúng;
• [ ] Không để staging public ngoài chủ đích.

Phần D – Phụ lục 03: Timeline và Payment Milestones

Mốc	Điều kiện hoàn thành	Ngày dự kiến	Thanh toán
M1	Ký hợp đồng + kickoff	...	...%
M2	Duyệt UI	...	...%
M3	Staging hoàn thành	...	...%
M4	UAT hoàn thành	...	...%
M5	Go-live + bàn giao	...	...%

Phần E – Mẫu Change Request

Mã CR: CR-...

• Người yêu cầu: …
• Ngày yêu cầu: …
• Mô tả thay đổi: …
• Lý do: …
• Hạng mục bị ảnh hưởng: …
• Chi phí bổ sung: …
• Ảnh hưởng timeline: …
• Rủi ro/phụ thuộc: …
• Người phê duyệt Bên A: …
• Ngày phê duyệt: …

Chỉ triển khai sau khi Change Request được xác nhận theo kênh đã quy định.

Phần F – Checklist bàn giao cuối dự án

Website

• [ ] Production hoạt động;
• [ ] Source theo phạm vi;
• [ ] Database export;
• [ ] Media;
• [ ] Backup.

Tài khoản

• [ ] CMS Admin;
• [ ] Domain;
• [ ] Hosting;
• [ ] CDN;
• [ ] Analytics;
• [ ] Search Console;
• [ ] Tag Manager;
• [ ] API/CRM theo phạm vi.

License

• [ ] Theme;
• [ ] Plugin;
• [ ] Font;
• [ ] Stock asset;
• [ ] Ngày gia hạn;
• [ ] Người chịu phí gia hạn.

Tài liệu

• [ ] Hướng dẫn quản trị;
• [ ] Cấu trúc dữ liệu;
• [ ] Danh sách tích hợp;
• [ ] Backup/restore;
• [ ] Support contact;
• [ ] Thời hạn bảo hành.

12 lỗi thường gặp khi ký hợp đồng thiết kế website BĐS

• 1. Scope chỉ ghi “theo yêu cầu”: gần như không thể xác định phát sinh.
• 2. Không phân biệt page và template: hai bên hiểu khác số lượng công việc.
• 3. Không có Acceptance Criteria: nghiệm thu bằng cảm tính.
• 4. Không quy định số vòng chỉnh sửa: dự án kéo dài.
• 5. Không có Change Request: mọi yêu cầu mới đều trở thành tranh luận.
• 6. Ghi “toàn bộ source thuộc khách hàng” nhưng không tách third-party: dễ mâu thuẫn với license.
• 7. Chỉ ghi “dữ liệu lead thuộc Bên A”: chưa đủ để xác định trách nhiệm xử lý dữ liệu.
• 8. “Chuẩn SEO” nhưng không có checklist: không nghiệm thu được.
• 9. “Tốc độ cao” nhưng không có điều kiện test: khó xác định vi phạm.
• 10. Không ghi trách nhiệm nhập liệu: phát sinh khối lượng lớn cuối dự án.
• 11. Không có Exit Plan: khó chuyển nhà cung cấp.
• 12. Bảo hành và bảo trì bị trộn làm một: dễ tranh cãi sau bàn giao.

Checklist trước khi ký hợp đồng

• [ ] Đúng pháp nhân và người có thẩm quyền;
• [ ] Scope of Work đính kèm;
• [ ] Template và feature có số lượng;
• [ ] Hạng mục loại trừ rõ;
• [ ] Timeline phụ thuộc Bên A/Bên B rõ;
• [ ] Acceptance Criteria;
• [ ] Payment milestone;
• [ ] Change Request;
• [ ] Code custom và third-party được tách;
• [ ] Domain/hosting/tài khoản được xác định;
• [ ] Điều khoản xử lý dữ liệu cá nhân;
• [ ] Backup và security scope;
• [ ] Bảo hành;
• [ ] Bảo trì;
• [ ] SLA nếu cần;
• [ ] Điều kiện chấm dứt;
• [ ] Exit Plan;
• [ ] Cơ chế tranh chấp;
• [ ] Pháp chế/luật sư rà soát các điều khoản quan trọng.

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

Hợp đồng thiết kế website có bắt buộc phải bàn giao toàn bộ mã nguồn không?

Không nên mặc định. Phạm vi bàn giao cần được hai bên thỏa thuận rõ. Website có thể chứa code viết riêng, framework có trước, open-source và thành phần thương mại của bên thứ ba với các giấy phép khác nhau.

Dữ liệu lead có nên ghi là “thuộc sở hữu của khách hàng” không?

Không nên chỉ dừng ở một câu như vậy. Lead có thể chứa dữ liệu cá nhân, vì vậy hợp đồng cần xác định mục đích và phạm vi xử lý, vai trò của các bên, quyền truy cập, biện pháp bảo vệ, việc sử dụng bên thứ ba và cách hoàn trả/xóa dữ liệu khi kết thúc dịch vụ.

Có nên ghi cam kết PageSpeed cụ thể trong hợp đồng?

Có thể nếu hai bên thực sự cần, nhưng phải nêu rõ trang được test, công cụ, thiết bị, hosting, dữ liệu và third-party script. Không nên cam kết một điểm chung chung cho mọi tình huống.

Website chuẩn SEO có đồng nghĩa với cam kết lên Top Google không?

Không. SEO foundation và dịch vụ SEO dài hạn là hai phạm vi khác nhau. Nếu chỉ thiết kế website, nên nghiệm thu các hạng mục kỹ thuật/onpage cụ thể thay vì thứ hạng.

Thế nào là một Change Request?

Là thay đổi vượt khỏi Scope of Work đã chốt. Ví dụ scope chỉ có filter khu vực và giá nhưng sau đó bổ sung bản đồ đồng bộ filter, lưu tìm kiếm và gửi thông báo tự động thì có thể là phạm vi mới.

Nên thanh toán trước bao nhiêu phần trăm?

Không có một tỷ lệ phù hợp cho mọi hợp đồng. Nên chia thanh toán theo milestone và sản phẩm đầu ra, đồng thời xem xét quy mô, thời gian, mức custom và chính sách của hai bên.

Có cần hợp đồng riêng cho bảo trì website không?

Có thể dùng hợp đồng/phụ lục riêng nếu bảo trì kéo dài và có nhiều nghĩa vụ định kỳ. Điều quan trọng là phân biệt rõ sửa lỗi bảo hành với hoạt động vận hành, cập nhật và phát triển mới.

Hợp đồng điện tử có dùng được không?

Các bên có thể cân nhắc giao kết và quản lý hồ sơ bằng phương tiện điện tử phù hợp quy định áp dụng. Hợp đồng nên xác định kênh, người có thẩm quyền và cách xác nhận tài liệu để tránh tranh luận về việc một email hoặc tin nhắn có được coi là phê duyệt hay không.

Kết luận

Một hợp đồng thiết kế website BĐS chuyên nghiệp không được đo bằng số trang của hợp đồng mà bằng mức độ rõ ràng của dự án.

5 nhóm nội dung quan trọng nhất là:

Scope → Acceptance → Ownership/License → Data → Change & Exit.

Nếu năm phần này rõ, phần lớn tranh luận về “đã bao gồm hay chưa”, “website đã hoàn thành chưa”, “ai giữ source”, “lead được dùng thế nào” và “ngừng hợp tác bàn giao ra sao” đều dễ xử lý hơn.

Đối với dự án chuẩn bị ký hợp đồng, nên kết hợp mẫu này với khung chi phí và đối tác thiết kế website BĐS để xác định scope, đồng thời tham khảo checklist đánh giá gói thiết kế website BĐS trọn gói trước khi chốt nhà cung cấp.

Lưu ý cuối: đây là mẫu khung phục vụ chuẩn hóa dự án và đàm phán. Những điều khoản liên quan tới quyền sở hữu trí tuệ, dữ liệu cá nhân, phạt vi phạm, bồi thường, chấm dứt và giải quyết tranh chấp nên được luật sư hoặc pháp chế điều chỉnh theo giao dịch cụ thể trước khi ký.