Cách Báo Giá Dự Án Thiết Kế: Scope, Revision, License, Rush Fee Và Điều Khoản Thanh Toán

Báo giá thiết kế không chỉ là chọn một con số “vừa đủ để khách đồng ý”. Một báo giá tốt phải mô tả rõ thứ khách hàng sẽ nhận, phạm vi công việc, số vòng chỉnh sửa, quyền sử dụng, thời hạn và cách xử lý khi yêu cầu thay đổi. Nếu các phần này mơ hồ, cả designer lẫn khách hàng đều dễ thất vọng dù mức giá ban đầu có vẻ hợp lý.

Bài viết này hướng dẫn xây báo giá cho logo, nhận diện thương hiệu, social media, landing page, illustration, key visual và các dự án sáng tạo tương tự. Nội dung mang tính vận hành nghề nghiệp, không thay thế tư vấn pháp lý hoặc thuế.

1. Đừng báo giá trước khi làm rõ brief

Trước khi đưa con số, hãy hỏi:

• Sản phẩm cuối là gì và dùng ở đâu?
• Ai là người duyệt cuối?
• Có guideline hoặc asset sẵn không?
• Cần bao nhiêu concept?
• Deadline thực và các mốc review?
• Định dạng file bàn giao?
• Phạm vi sử dụng: nội bộ, social, quảng cáo, in ấn, bán lại?
• Có yêu cầu giữ bí mật, bàn giao source hoặc exclusivity?

Nếu khách chưa rõ, đề xuất một discovery phase có phí thay vì cố đoán toàn bộ scope.

2. Chọn mô hình định giá

Mô hình	Phù hợp	Rủi ro
Theo giờ/ngày	Scope khó đoán, support, production	Khách khó dự báo tổng chi phí
Fixed project	Deliverable và quy trình rõ	Scope creep nếu mô tả yếu
Value-based	Dự án tác động kinh doanh lớn, có dữ liệu	Cần discovery và khả năng chứng minh giá trị
Retainer	Nhu cầu đều hàng tháng	Dễ biến thành “không giới hạn” nếu thiếu quota

Freelancer mới thường dễ quản lý bằng fixed project có scope rõ, cộng rate ngoài phạm vi. Không nên dùng value-based chỉ như cách nhân giá tùy ý; cần hiểu mục tiêu và rủi ro của khách.

3. Tính giá sàn từ chi phí và công suất

Một cách đơn giản:

Doanh thu mục tiêu năm
+ chi phí kinh doanh
+ quỹ dự phòng
= doanh thu cần đạt

Doanh thu cần đạt / số ngày có thể bán
= day rate tối thiểu

Không chia cho toàn bộ 365 ngày. Freelancer còn có ngày bán hàng, quản trị, học tập, nghỉ phép và thời gian không có dự án.

4. Phân rã scope thành deliverable

Thay vì “thiết kế nhận diện”, hãy liệt kê:

• Discovery workshop 90 phút.
• Research và moodboard.
• Hai hướng concept.
• Một logo chính và biến thể.
• Palette, typography, spacing.
• Năm template social.
• Brand guideline 20 trang.
• File bàn giao được nêu rõ.

Mỗi deliverable có số lượng, định dạng và điều kiện nghiệm thu.

5. Revision khác change request

Revision là điều chỉnh trong hướng đã duyệt: đổi màu, sửa typography, tinh chỉnh bố cục. Change request là thay đổi brief, đối tượng, concept hoặc thêm deliverable.

Proposal cần ghi:

• Số vòng revision.
• Mỗi vòng được gom phản hồi trong một danh sách.
• Ai có quyền gửi phản hồi cuối.
• Thời gian phản hồi tối đa.
• Rate hoặc cách báo giá ngoài phạm vi.

6. Quy trình change request

1. Designer mô tả yêu cầu mới và ảnh hưởng.
2. Ước tính thêm chi phí và thời gian.
3. Khách xác nhận bằng văn bản.
4. Cập nhật timeline và invoice.
5. Chỉ bắt đầu sau khi được duyệt.

Không tiếp tục làm rồi tranh luận chi phí sau.

7. License và quyền sử dụng

Giá thiết kế và quyền sử dụng có thể là hai phần khác nhau. Cần xác định:

• Khu vực địa lý.
• Thời hạn.
• Kênh: organic, paid ads, broadcast, packaging.
• Quy mô doanh nghiệp hoặc campaign.
• Độc quyền hay không.
• Có được sửa, bán lại hoặc sublicensing?

Với logo, khách thường cần quyền rộng sau khi thanh toán đầy đủ; với illustration cho chiến dịch, license có thể giới hạn theo thời gian và kênh. Font, stock, mockup và asset bên thứ ba vẫn theo license riêng; designer không thể chuyển quyền mình không sở hữu.

8. Source file có nằm trong giá không?

Ghi rõ file bàn giao:

• File final: PNG, JPG, PDF, SVG.
• File editable: AI, PSD, Figma, After Effects.
• Font và plugin có được kèm không.
• Link asset bên thứ ba.
• Cấu trúc layer có được làm sạch để handoff.

Nếu source file làm tăng khả năng chỉnh sửa và tái sử dụng, có thể tính như deliverable riêng, nhưng phải minh bạch từ đầu.

9. Rush fee

Dự án gấp thường yêu cầu đổi lịch, làm ngoài giờ hoặc từ chối việc khác. Rush fee không phải hình phạt; nó bù chi phí cơ hội và rủi ro. Chỉ nhận khi deadline khả thi. Ghi rõ:

• Mức phụ phí.
• Điều kiện khách phản hồi đúng giờ.
• Phạm vi bị rút gọn nếu cần.
• Không đảm bảo deadline khi khách trễ feedback hoặc asset.

10. Lịch thanh toán

Cấu trúc phổ biến:

• 30–50% deposit để giữ lịch.
• Một milestone sau khi duyệt concept.
• Phần còn lại trước khi bàn giao file final/source.

Với dự án dài, chia theo tháng hoặc milestone. Ghi ngày đến hạn, phương thức, thuế/phí và late fee nếu phù hợp pháp luật.

11. Kill fee và tạm dừng dự án

Nếu khách hủy sau khi công việc đã bắt đầu, designer cần được thanh toán cho thời gian và deliverable đã thực hiện. Hợp đồng nên nêu deposit có hoàn lại hay không, cách tính kill fee, thời gian archive và phí restart.

12. Proposal nên có gì?

1. Bối cảnh và mục tiêu.
2. Scope và deliverable.
3. Quy trình, milestone, timeline.
4. Vai trò và trách nhiệm hai bên.
5. Revision và change request.
6. Giá, thuế, lịch thanh toán.
7. License và file bàn giao.
8. Điều khoản hủy, trì hoãn, bảo mật.
9. Thời hạn hiệu lực của báo giá.

13. Ví dụ cấu trúc báo giá

Hạng mục	Phạm vi
Discovery	Workshop, audit, brief đã xác nhận
Concept	2 hướng, trình bày rationale
Development	1 hướng được chọn, 2 vòng revision
Deliverables	Logo suite, guideline, 5 social templates
License	Quyền dùng thương mại của khách sau thanh toán
Out of scope	Naming, copywriting, packaging, animation

14. Khi khách nói “ngân sách thấp hơn”

Không tự động giảm giá mà giữ nguyên scope. Chọn:

• Giảm số concept.
• Giảm deliverable.
• Giảm số revision.
• Kéo dài timeline.
• Chia thành phase.
• Đề xuất package nhỏ hơn.

Giữ tiêu chuẩn cốt lõi; không bỏ research hoặc QA nếu điều đó làm dự án thất bại.

15. Sai lầm thường gặp

• Báo giá từ cảm giác hoặc nhìn giá người khác.
• Không ghi out-of-scope.
• Revision “đến khi hài lòng”.
• Không xác định người duyệt.
• Bàn giao source trước khi thanh toán.
• Không lưu phản hồi và phê duyệt bằng văn bản.
• Không tính thời gian họp, quản trị và export.

16. Checklist trước khi gửi

• Brief đủ rõ?
• Deliverable có số lượng/format?
• Timeline có phụ thuộc phía khách?
• Revision và change request tách biệt?
• License rõ?
• Source file rõ?
• Deposit, milestone và final payment rõ?
• Có điều khoản hủy/tạm dừng?
• Báo giá có thời hạn hiệu lực?

Kết luận

Báo giá chuyên nghiệp không phải cố đoán mức tối đa khách sẵn sàng trả. Nó là bản đồ của dự án: giá phản ánh scope, thời gian, quyền sử dụng, rủi ro và trách nhiệm. Khi scope thay đổi, giá và timeline cũng phải thay đổi có xác nhận.

Trước khi gửi proposal, hãy đảm bảo portfolio của bạn chứng minh đúng loại công việc. Đọc thêm bài Cách làm portfolio Digital Artist.

Nguồn tham khảo

• Freelancers Union Contract Creator

Phần mở rộng: khung vận hành báo giá thiết kế

Bắt đầu từ nhu cầu thật

Hãy mô tả vấn đề người dùng đang gặp trước khi chọn công cụ cho báo giá thiết kế. Một quy trình tốt bắt đầu từ đầu ra cần đạt, người chịu trách nhiệm và tiêu chí kiểm chứng. Đừng coi một bảng tính, template hay dashboard là sản phẩm chỉ vì nó trông hoàn chỉnh. Hãy phỏng vấn người dùng, ghi lại bước họ đang làm thủ công, điểm dễ sai và thời điểm họ sẵn sàng trả tiền hoặc quay lại. Những ghi chú này trở thành baseline để đánh giá thay đổi sau này.

Xác định phạm vi

Phạm vi rõ giúp báo giá thiết kế không phình to. Viết phần có trong phiên bản hiện tại, phần chưa làm, dữ liệu cần và điều kiện bàn giao. Khi có yêu cầu mới, đặt nó vào backlog thay vì âm thầm thêm vào cam kết cũ. Mỗi mục nên có owner, deadline tương đối và bằng chứng hoàn thành. Cách này bảo vệ chất lượng, thời gian và niềm tin với người dùng.

Thiết kế trải nghiệm

Trải nghiệm của báo giá thiết kế cần ít ma sát nhưng vẫn minh bạch. Người dùng phải biết họ đang ở bước nào, nhận được gì, giới hạn nào áp dụng và làm gì khi có lỗi. Dùng ngôn ngữ cụ thể, ví dụ thật và trạng thái rỗng có hướng dẫn. Kiểm tra trên màn hình nhỏ, mạng chậm và tài khoản không có quyền đặc biệt; đó là những tình huống thường tạo ra khiếu nại nhất.

Dữ liệu và cấu trúc

Với phạm vi, định giá, quyền sử dụng, milestone và thanh toán, hãy thống nhất tên trường, định dạng ngày, mã phiên bản và cách xử lý dữ liệu thiếu. Không dùng một cột tự do cho nhiều ý nghĩa. Tách dữ liệu người dùng nhập khỏi dữ liệu hệ thống, lưu lịch sử khi cần và đặt quy tắc xóa hoặc lưu giữ. Cấu trúc rõ làm việc tìm kiếm, xuất báo cáo và chuyển giao cho người khác ít rủi ro hơn.

Kiểm chứng trước khi phát hành

Trước khi đưa báo giá thiết kế đến khách hàng, tạo một checklist kiểm chứng gồm happy path, dữ liệu biên, quyền sai, lỗi mạng và trường hợp thanh toán hoặc hoàn tiền nếu có. Nhờ một người không tham gia xây dựng làm thử theo hướng dẫn. Các điểm họ dừng hoặc hỏi lại thường là lỗi nội dung, không phải lỗi kỹ thuật, và cần sửa trước khi quảng bá.

Định giá và giá trị

Giá của báo giá thiết kế nên phản ánh kết quả và mức hỗ trợ, không chỉ số lượng file hay số giờ làm. Ghi rõ khách hàng nhận gì, cập nhật trong bao lâu, kênh hỗ trợ nào có và điều kiện gia hạn. Nếu có nhiều gói, mỗi gói cần khác nhau về quyền hoặc mức độ đồng hành; tránh tạo ba tên gọi cho cùng một lợi ích.

Quyền và cấp phép

Hãy ghi giấy phép, quyền sử dụng, giới hạn chuyển nhượng và cách ghi công cho mọi tài sản liên quan báo giá thiết kế. Không giả định một asset tìm thấy trên Internet là được phép dùng thương mại. Lưu URL nguồn, ngày truy cập, tác giả và phiên bản. Khi không chắc, thay bằng nguồn có điều khoản rõ hoặc xin phép bằng văn bản.

Quy trình cập nhật

Một báo giá thiết kế tốt cần lịch cập nhật. Đặt chu kỳ xem lại nội dung, kiểm tra link hỏng, thay ảnh lỗi thời và ghi changelog. Mỗi bản cập nhật nên có số phiên bản, ngày phát hành và mô tả thay đổi. Người dùng cũ cần biết họ nhận được gì; người dùng mới cần thấy sản phẩm còn được chăm sóc.

Hỗ trợ và phản hồi

Tạo một kênh phản hồi duy nhất, phân loại câu hỏi và cam kết thời gian trả lời thực tế. Ghi lại lỗi lặp lại, yêu cầu tính năng và lý do hoàn tiền. Dữ liệu hỗ trợ giúp cải thiện báo giá thiết kế tốt hơn nhiều so với đoán ý qua lượt xem. Khi một vấn đề được sửa, thông báo lại cho người đã báo để đóng vòng tin cậy.

Đo lường chất lượng

Đừng chỉ nhìn doanh thu hoặc lượt tải. Theo dõi tỷ lệ hoàn thành, thời gian đến giá trị, số lần cần hỗ trợ, tỷ lệ quay lại, lỗi và churn. Với báo giá thiết kế, mỗi chỉ số phải có định nghĩa, nguồn dữ liệu và người sở hữu. Một dashboard ít chỉ số nhưng chính xác hữu ích hơn bảng lớn chứa số liệu không ai hành động.

An toàn và riêng tư

Thu thập dữ liệu tối thiểu, giải thích mục đích và giới hạn quyền truy cập. Không đưa thông tin cá nhân vào ảnh chụp, log hoặc tài liệu công khai. Kiểm tra quyền tải xuống, chia sẻ liên kết và xóa tài khoản. Nếu dùng bên thứ ba, đọc điều khoản lưu trữ và chuẩn bị phương án xuất dữ liệu khi cần.

Bàn giao

Tài liệu bàn giao của báo giá thiết kế cần có cấu trúc, nguồn, quyết định đã chốt, việc còn mở và cách khôi phục khi có lỗi. Ghi cả những điều không nên làm. Một người mới phải có thể tiếp quản bằng tài liệu và quyền được cấp, không cần hỏi lại người tạo. Đây là thước đo quan trọng của một hệ thống trưởng thành.

Thử nghiệm có kiểm soát

Khi thử giá, nội dung hoặc luồng mới cho báo giá thiết kế, chỉ thay đổi một biến và đặt thời gian đánh giá. Chia nhóm hợp lý, ghi giả thuyết trước khi chạy và tránh kết luận từ vài lượt xem. Nếu kết quả xấu, rollback và ghi nguyên nhân; nếu tốt, cập nhật quy trình chính thức thay vì để thành mẹo truyền miệng.

Kế hoạch rủi ro

Liệt kê rủi ro có xác suất và tác động cao: mất dữ liệu, nguồn bị gỡ, thanh toán lỗi, người dùng hiểu sai, chi phí tăng hoặc người phụ trách vắng mặt. Với mỗi rủi ro, ghi dấu hiệu sớm, hành động giảm thiểu và người có quyền quyết định. Kế hoạch ngắn nhưng cụ thể giúp báo giá thiết kế không bị động khi sự cố xảy ra.

Kết luận thực hành

Hãy bắt đầu báo giá thiết kế bằng một phiên bản nhỏ, có nguồn rõ, lời hứa vừa sức và cách đo cụ thể. Sau mỗi vòng, dùng phản hồi thật để sửa nội dung, cấu trúc và hỗ trợ. Tốc độ chỉ có ý nghĩa khi chất lượng, quyền sử dụng và khả năng duy trì cùng tăng. Quy trình này tạo nền tảng để mở rộng mà không đánh đổi sự tin cậy.

Kiểm soát scope trước và sau khi báo giá

Brief cần ghi mục tiêu, người xem, kênh, số lượng đầu ra, kích thước, định dạng, deadline, người duyệt và tiêu chí hoàn thành. Hãy tách yêu cầu bắt buộc, thông tin cần xác nhận và phần có thể tối ưu sau. Mọi giả định ảnh hưởng đến công sức phải nằm trong báo giá, không để trong trao đổi miệng.

Revision cần có định nghĩa cụ thể: một vòng gồm bao nhiêu lượt phản hồi, ai tổng hợp, thời hạn gửi feedback và thay đổi nào được xem là scope change. Thêm kênh, thêm đối tượng, đổi chiến lược hoặc đổi deadline không nên bị gọi là chỉnh sửa nhỏ. Một đầu mối phản hồi giúp giảm ý kiến mâu thuẫn và thời gian tổng hợp.

License phải nêu nơi dùng, thời hạn, phạm vi, số thương hiệu, quyền sửa và quyền chuyển giao. Font, ảnh, mockup và plugin bên thứ ba có điều khoản riêng. Rush fee bù cho việc ưu tiên lịch hoặc làm ngoài lead time, không phải khoản phạt. Trước khi nhận rush, kiểm tra công suất và rủi ro chất lượng. Báo giá tốt là tài liệu quản trị kỳ vọng, không chỉ là một con số.

Mẫu cấu trúc báo giá dễ kiểm tra

Một báo giá nên có phần tóm tắt mục tiêu, phạm vi trong/ngoài, deliverable, lịch, số vòng revision, trách nhiệm mỗi bên, phí, mốc thanh toán, license, bàn giao source, bảo mật và điều kiện kết thúc. Đặt các giả định ngay cạnh hạng mục liên quan. Nếu một phần phụ thuộc vào nội dung khách cung cấp, ghi ngày nhận và tác động khi trễ.

Trước khi gửi, đọc tài liệu như người chưa tham gia cuộc gọi. Họ có biết sản phẩm cuối là gì, bao nhiêu lần được góp ý, khi nào được dùng và khoản nào phát sinh không? Nếu câu trả lời chưa rõ, sửa văn bản thay vì hy vọng cuộc họp sau sẽ giải thích. Lưu phiên bản và xác nhận phần được duyệt để tránh hai bên dùng hai báo giá khác nhau.

Xác nhận trước khi bắt đầu

Chỉ khởi động khi brief, phạm vi, người duyệt, mốc thanh toán và điều khoản sử dụng đã được xác nhận bằng văn bản. Nếu còn điểm chưa rõ, ghi thành giả định hoặc hạng mục discovery. Việc này giúp designer tập trung vào chất lượng và giúp khách hàng biết chính xác quyết định nào có thể làm thay đổi ngân sách hoặc lịch bàn giao.

Tiêu chí đánh giá sau khi triển khai

Sau khi áp dụng quy trình, hãy đánh giá bằng bằng chứng thay vì cảm giác. Ghi lại mục tiêu ban đầu, hành động người dùng cần thực hiện, thời gian hoàn thành, lỗi phát sinh và kết quả đầu ra. Một quy trình chỉ được xem là hiệu quả khi người khác có thể làm theo mà không cần người tạo giải thích riêng từng bước. Nếu kết quả phụ thuộc vào một cá nhân, hãy biến phần kiến thức đó thành hướng dẫn, ví dụ, checklist hoặc trường dữ liệu rõ ràng.

Hãy chia review thành ba lớp. Lớp đầu kiểm tra chất lượng đầu ra và mức độ đúng ngữ cảnh. Lớp hai kiểm tra quyền, nguồn, phiên bản, dữ liệu và khả năng truy vết. Lớp ba kiểm tra trải nghiệm trên mobile, lỗi mạng, nội dung dài và trạng thái không có dữ liệu. Mỗi lớp cần một người chịu trách nhiệm và một tiêu chí pass/fail. Những lỗi nhỏ nhưng lặp lại nên được ưu tiên vì chúng tạo ra chi phí hỗ trợ lớn.

Cách cải tiến qua từng vòng

Không nên thay đổi quá nhiều biến cùng lúc. Chọn một giả thuyết, thử trong phạm vi nhỏ, đo trong khoảng thời gian đủ dài rồi ghi quyết định. Nếu thử nghiệm không đạt, rollback và nêu nguyên nhân; nếu đạt, cập nhật tài liệu chính thức. Changelog giúp người dùng hiểu thay đổi, còn nhật ký quyết định giúp đội ngũ không lặp lại cùng một tranh luận. Khi quy mô tăng, hãy chuyển các mẹo cá nhân thành quy tắc có thể bàn giao.

Cuối mỗi vòng, đặt câu hỏi: điều gì đang tạo giá trị thật, điều gì chỉ làm hệ thống lớn hơn, rủi ro nào chưa được kiểm tra và bằng chứng nào còn thiếu? Cách làm này giữ cho nội dung, workflow và tài sản liên quan luôn rõ ràng, có thể bảo trì và đáng tin cậy trong thực tế.