Proposal là tài liệu đề xuất giúp người ra quyết định hiểu vấn đề, giải pháp, phạm vi, thời gian, chi phí, trách nhiệm và điều kiện hợp tác. Nó không chỉ là một bản báo giá được trình bày đẹp. Proposal tốt phải giảm bất định, cho phép so sánh phương án và chỉ rõ bước tiếp theo trước khi các bên cam kết nguồn lực.
Proposal là gì?
Proposal có thể dịch là bản đề xuất, hồ sơ đề xuất hoặc phương án đề nghị. Tài liệu này được gửi để xin phê duyệt, thuyết phục khách hàng, cạnh tranh trong một quy trình lựa chọn nhà cung cấp hoặc thống nhất hướng triển khai trước khi ký hợp đồng.
Proposal thường xuất hiện trong:
- Dịch vụ Marketing, SEO, quảng cáo và truyền thông.
- Thiết kế website, phần mềm và hệ thống công nghệ.
- Tư vấn quản trị, tài chính hoặc nhân sự.
- Tổ chức sự kiện.
- Thiết kế, kiến trúc và xây dựng.
- Nghiên cứu, tài trợ và dự án xã hội.
- Mua sắm và lựa chọn nhà cung cấp.
- Đề xuất nội bộ giữa phòng ban với lãnh đạo.
Trong các quy trình mua sắm hoặc lựa chọn nhà cung cấp chính thức, Request for Proposals (RFP) thường mô tả yêu cầu, điều khoản dự kiến, thông tin bắt buộc trong hồ sơ và tiêu chí đánh giá. Nhà cung cấp cần đọc RFP như một bộ yêu cầu kiểm soát, không chỉ như tài liệu tham khảo để viết nội dung bán hàng.

Proposal giải quyết vấn đề gì?
Một proposal cần tạo sự đồng thuận giữa bên đề xuất và bên ra quyết định trước khi nguồn lực được cam kết.
Tài liệu phải làm rõ:
- Hiện trạng hoặc nhu cầu nào đang tồn tại.
- Mục tiêu nào cần đạt.
- Giải pháp được đề xuất là gì.
- Vì sao giải pháp phù hợp với bối cảnh.
- Phạm vi công việc gồm và không gồm những gì.
- Ai chịu trách nhiệm cho từng đầu việc.
- Thời gian và cột mốc triển khai.
- Chi phí, lịch thanh toán và điều kiện thương mại.
- Cách đánh giá kết quả.
- Quyết định hoặc hành động tiếp theo cần được thực hiện.
Proposal không bảo đảm khách hàng sẽ ký hợp đồng. Nó giảm bất định và giúp người đọc đánh giá giải pháp theo cùng một bộ thông tin.
Proposal khác báo giá thế nào?
Báo giá tập trung vào danh mục hàng hóa, dịch vụ, số lượng, đơn giá, thuế, thời hạn hiệu lực và điều kiện thanh toán. Proposal rộng hơn: nó giải thích bối cảnh, vấn đề, giải pháp, phạm vi và lý do lựa chọn.
Trong dự án đơn giản, báo giá có thể đủ. Ví dụ khách đã xác định chính xác sản phẩm, số lượng, tiêu chuẩn và chỉ cần biết giá giao hàng.
Proposal cần thiết hơn khi:
- Khách hàng chưa biết giải pháp nào phù hợp.
- Dự án có nhiều giai đoạn hoặc bên liên quan.
- Phạm vi cần được làm rõ.
- Các nhà cung cấp đề xuất phương pháp khác nhau.
- Giá phụ thuộc giả định hoặc nguồn lực.
- Người phê duyệt không tham dự buổi trao đổi ban đầu.
Proposal trả lời “vì sao và triển khai thế nào”; báo giá trả lời “mua gì và trả bao nhiêu”. Hai tài liệu có thể được kết hợp, nhưng không nên đánh đồng.
Proposal, RFP và Pitch Deck khác nhau ra sao?
| Tài liệu | Do ai tạo? | Mục đích chính |
|---|---|---|
| RFP | Bên mua hoặc đơn vị mời đề xuất. | Mô tả yêu cầu, hướng dẫn nộp hồ sơ và tiêu chí đánh giá. |
| Proposal | Bên đề xuất hoặc nhà cung cấp. | Trình bày cách đáp ứng nhu cầu, phạm vi, nguồn lực, chi phí và điều kiện. |
| Pitch Deck | Doanh nghiệp, startup hoặc đội bán hàng. | Trình bày tổng quan bằng slide để gây chú ý và mở cuộc thảo luận. |
| Quotation | Nhà cung cấp. | Thông báo giá, số lượng và điều kiện thương mại. |
| SOW | Một hoặc hai bên cùng xây dựng. | Xác định chi tiết công việc, deliverable, tiêu chuẩn và trách nhiệm. |
| Contract | Các bên tham gia giao dịch. | Tạo nghĩa vụ và quyền pháp lý sau khi được chấp thuận, ký kết hợp lệ. |
Proposal có thể trở thành căn cứ để xây SOW và hợp đồng, nhưng bản đề xuất không tự động thay thế hợp đồng. Doanh nghiệp cần ghi rõ tài liệu nào có tính ràng buộc và điều khoản nào chỉ là giả định đề xuất.
Hai loại Proposal phổ biến
Solicited Proposal
Solicited Proposal là đề xuất được gửi sau khi khách hàng yêu cầu. Yêu cầu có thể là RFP chính thức, brief, email hoặc biên bản cuộc họp.
Khi phản hồi RFP, nhà cung cấp cần:
- Đọc toàn bộ hướng dẫn và phụ lục.
- Lập bảng đối chiếu từng yêu cầu.
- Tuân thủ cấu trúc, định dạng và thời hạn.
- Chỉ ra phần đáp ứng, ngoại lệ và giả định.
- Bám sát tiêu chí đánh giá.
- Không thay thế câu trả lời bằng nội dung giới thiệu chung.
Trong quy trình lựa chọn cạnh tranh, hồ sơ cần bám đúng hướng dẫn nộp, yêu cầu bắt buộc và tiêu chí đã công bố. Một proposal trình bày đẹp nhưng thiếu biểu mẫu, bằng chứng hoặc điều kiện bắt buộc vẫn có thể bị đánh giá thấp hoặc bị loại theo quy định của hồ sơ mời đề xuất.
Unsolicited Proposal
Unsolicited Proposal là đề xuất chủ động gửi khi khách hàng chưa yêu cầu tài liệu cụ thể.
Đề xuất dạng này cần ngắn, có căn cứ và tôn trọng người nhận. Không nên gửi một hồ sơ dài chỉ dựa trên suy đoán rằng doanh nghiệp “đang làm Marketing kém”.
Một unsolicited proposal phù hợp nên:
- Nêu lý do liên hệ cụ thể.
- Chỉ ra quan sát có thể kiểm chứng.
- Không phóng đại tổn thất.
- Đề xuất bước khám phá nhỏ trước khi bán dự án lớn.
- Cho người nhận quyền từ chối hoặc không tiếp tục trao đổi.
Proposal nội bộ và Proposal thương mại
| Tiêu chí | Proposal nội bộ | Proposal thương mại |
|---|---|---|
| Người đọc | Lãnh đạo, hội đồng hoặc phòng ban. | Khách hàng, đối tác hoặc bên mời đề xuất. |
| Trọng tâm | Giá trị tổ chức, ngân sách và khả năng thực thi nội bộ. | Giá trị cho khách hàng, phạm vi, năng lực và điều kiện hợp tác. |
| Bằng chứng | Dữ liệu nội bộ, benchmark và nguồn lực hiện có. | Case study, phương pháp, đội ngũ và tài liệu tham chiếu. |
| Quyết định | Phê duyệt ngân sách hoặc thay đổi hoạt động. | Chọn nhà cung cấp, thương lượng hoặc ký hợp đồng. |
Cấu trúc một Proposal hoàn chỉnh
Không có một mẫu cố định cho mọi ngành. Proposal cần đủ thông tin để được đánh giá nhưng không nên dài chỉ để tạo cảm giác “công phu”.
Cấu trúc thực hành có thể gồm:
- Trang bìa: tên đề xuất, khách hàng, nhà cung cấp, phiên bản và ngày gửi.
- Executive Summary: tóm tắt vấn đề, hướng giải pháp, giá trị và quyết định cần phê duyệt.
- Hiểu biết về hiện trạng: bối cảnh, dữ liệu, ràng buộc và vấn đề đã xác nhận.
- Mục tiêu: kết quả kinh doanh hoặc vận hành mà dự án hướng tới.
- Giải pháp đề xuất: phương pháp, cấu phần và lý do lựa chọn.
- Phạm vi: deliverable, số lượng, tiêu chuẩn và phần loại trừ.
- Phương pháp triển khai: quy trình, công cụ và cách kiểm soát chất lượng.
- Timeline: giai đoạn, mốc duyệt, dependency và ngày dự kiến.
- Đội ngũ: vai trò, trách nhiệm và mức độ tham gia.
- Quản trị dự án: họp, báo cáo, phê duyệt và xử lý thay đổi.
- Bằng chứng năng lực: case study, kinh nghiệm và tài liệu liên quan.
- Ngân sách: phí, chi phí bên thứ ba, thuế và lịch thanh toán.
- Giả định và rủi ro: điều kiện để kế hoạch khả thi.
- Điều khoản đề xuất: hiệu lực, bảo mật, sở hữu trí tuệ và điều kiện hủy.
- Next Step: người quyết định, thời hạn phản hồi và hành động tiếp theo.
Với dự án có nhiều bên liên quan, một Project Manager hoặc đầu mối tương đương nên chịu trách nhiệm quản lý phiên bản, dependency, phê duyệt và thay đổi phạm vi.
Executive Summary viết thế nào?
Executive Summary không phải phần giới thiệu doanh nghiệp được đặt lên đầu. Đây là bản tóm tắt quyết định dành cho người không có thời gian đọc toàn bộ tài liệu.
Một Executive Summary tốt nên trả lời:
- Khách hàng đang muốn đạt kết quả gì?
- Vấn đề hoặc cơ hội nào đã được xác định?
- Giải pháp đề xuất là gì?
- Tại sao phương án này phù hợp?
- Giá trị dự kiến và giới hạn của dự báo là gì?
- Quyết định nào cần được phê duyệt?
Không nên viết “giải pháp đột phá giúp tăng ROI vượt trội” khi chưa có baseline, ngân sách hoặc bằng chứng. Dùng ngôn ngữ kinh doanh rõ ràng, nhưng không thay sự cụ thể bằng khẩu hiệu.
Problem Statement cần dựa trên bằng chứng
Problem Statement mô tả khoảng cách giữa hiện trạng và kết quả mong muốn. Nội dung cần dựa trên dữ liệu đã được khách hàng xác nhận hoặc được ghi rõ là giả thuyết.
Cấu trúc tham khảo:
- Hiện trạng: điều gì đang diễn ra?
- Ảnh hưởng: vấn đề tác động đến khách hàng hoặc hoạt động thế nào?
- Nguyên nhân đã biết: dữ liệu nào hỗ trợ nhận định?
- Điều chưa biết: phần nào cần nghiên cứu thêm?
- Ưu tiên: vì sao nên xử lý trong giai đoạn này?
Không nên tự tuyên bố khách hàng “mất 5.000 lead mỗi tháng” hoặc đối thủ “chiếm 80% thị trường” khi không có nguồn và phương pháp tính.

Giải pháp đề xuất phải cụ thể đến đâu?
Giải pháp cần đủ chi tiết để người đọc đánh giá tính khả thi nhưng không cần biến proposal thành tài liệu hướng dẫn triển khai từng thao tác.
Mỗi cấu phần nên nêu:
- Hoạt động sẽ thực hiện.
- Mục đích của hoạt động.
- Đầu vào cần có.
- Deliverable.
- Tiêu chuẩn nghiệm thu.
- Người phụ trách.
- Dependency.
- Rủi ro hoặc giới hạn.
Ví dụ, “triển khai SEO tổng thể” quá rộng. Cách viết rõ hơn là xác định phạm vi audit, nghiên cứu từ khóa, số nhóm nội dung, template cần sửa, chu kỳ báo cáo và phần kỹ thuật do bên nào thực hiện.
Một đề xuất SEO tổng thể phải tách rõ hoạt động tư vấn, sản xuất nội dung, chỉnh sửa website, Digital PR và những phần cần đội kỹ thuật khách hàng phối hợp.
Scope, Assumption và Exclusion
Ba phần này giúp hạn chế tranh chấp do hai bên hiểu khác nhau về cùng một câu “đã bao gồm”.
Scope – phạm vi
Phạm vi nêu những gì nhà cung cấp sẽ thực hiện và bàn giao. Nên dùng danh từ đo được như số trang, số phiên workshop, số vòng chỉnh sửa hoặc số báo cáo.
Assumption – giả định
Giả định là điều kiện được dùng để xây timeline và chi phí. Ví dụ:
- Khách hàng phản hồi trong hai ngày làm việc.
- Quyền truy cập được cung cấp đúng thời hạn.
- Nội dung pháp lý do khách hàng phê duyệt.
- Website hiện tại cho phép chỉnh sửa template.
- Dữ liệu đầu vào có thể sử dụng hợp pháp.
Exclusion – phần loại trừ
Exclusion nêu việc không thuộc giá hoặc phạm vi, chẳng hạn:
- Ngân sách quảng cáo.
- Phí công cụ và license bên thứ ba.
- Chi phí quay chụp.
- Phát triển tính năng ngoài danh sách.
- Biên dịch sang ngôn ngữ khác.
- Đăng ký pháp lý hoặc xin giấy phép.
Loại trừ rõ không làm proposal kém hấp dẫn. Nó giúp khách hàng so sánh các đề xuất công bằng và hiểu tổng chi phí sở hữu.
Timeline cần thể hiện dependency
timeline không nên chỉ là danh sách tháng 1, tháng 2 và tháng 3. Cần thể hiện quan hệ giữa công việc, mốc duyệt và trách nhiệm của hai bên.
Ví dụ:
| Giai đoạn | Đầu ra | Điều kiện chuyển bước |
|---|---|---|
| Khởi động | Brief, quyền truy cập, baseline và kế hoạch. | Khách hàng xác nhận mục tiêu và dữ liệu đầu vào. |
| Nghiên cứu | Audit, insight, keyword và đề xuất ưu tiên. | Hai bên chốt phạm vi triển khai. |
| Sản xuất | Nội dung, thiết kế, landing page hoặc campaign asset. | Đầu ra được duyệt theo SLA phản hồi. |
| Triển khai | Xuất bản, chạy chiến dịch và kiểm tra tracking. | Hệ thống, ngân sách và quyền truy cập sẵn sàng. |
| Đánh giá | Báo cáo, bài học và kế hoạch tiếp theo. | Dữ liệu đủ kỳ và được đối chiếu. |
Gantt Chart hữu ích với dự án có nhiều dependency, nhưng không bắt buộc cho mọi proposal. Với dự án ngắn, bảng cột mốc có thể dễ đọc hơn.
Pricing trong Proposal
Pricing cần giúp người đọc hiểu mình trả tiền cho điều gì, khoản nào chưa bao gồm và lịch thanh toán liên quan đến cột mốc nào.
Phần ngân sách nên nêu:
- Phí dịch vụ.
- Đơn vị tính.
- Khối lượng hoặc deliverable.
- Chi phí một lần và chi phí định kỳ.
- Thuế.
- Chi phí bên thứ ba.
- Lịch thanh toán.
- Thời hạn hiệu lực báo giá.
- Điều kiện thay đổi giá.
- Chi phí phát sinh hoặc change request.
Có nên luôn đưa ba gói giá?
Không. Tiered Pricing phù hợp khi khách hàng có thể chọn phạm vi hoặc mức dịch vụ khác nhau. Nó không phù hợp khi RFP yêu cầu một cấu hình cố định hoặc các lựa chọn làm người đọc khó so sánh.
Nếu đưa nhiều phương án, mỗi phương án phải giải thích:
- Kết quả hoặc mức độ bao phủ.
- Deliverable tăng hoặc giảm.
- Rủi ro còn lại.
- Những gì không được chuyển từ gói khác.
Không nên tạo một gói giá cao chỉ để làm “mỏ neo” nếu gói đó không có giá trị sử dụng thực tế.
Bài Budget là gì giúp người lập proposal xác định ngân sách, giả định, dòng tiền và dự phòng trước khi báo giá.
Có nên cam kết ROI và KPI?
Proposal nên nêu cách đo kết quả, nhưng phải phân biệt rõ KPI, target, forecast và guarantee. Với chỉ số tài chính như ROI, dự báo chỉ có ý nghĩa khi nêu baseline, phạm vi chi phí, thời gian đo và các giả định ảnh hưởng đến kết quả.
Phân biệt:
- Deliverable: đầu ra nhà cung cấp kiểm soát trực tiếp.
- Performance indicator: chỉ số theo dõi hiệu suất.
- Target: mức mục tiêu hai bên hướng đến.
- Forecast: dự báo dựa trên giả định.
- Guarantee: cam kết pháp lý cần điều kiện và trách nhiệm rõ.
Agency có thể cam kết các đầu ra nằm trong phạm vi kiểm soát như số lượng hạng mục, tiêu chuẩn chất lượng, chu kỳ báo cáo và thời gian phản hồi. Cam kết doanh thu, ROI hoặc vị trí tìm kiếm tuyệt đối cần điều kiện pháp lý và vận hành rất rõ vì kết quả còn phụ thuộc sản phẩm, giá, website, ngân sách, thị trường, đối thủ và năng lực phối hợp của khách hàng.
Bằng chứng năng lực cần trình bày ra sao?
Social proof có giá trị khi liên quan đến dự án đang đề xuất.
Có thể dùng:
- Case study cùng ngành hoặc cùng loại vấn đề.
- Kết quả trước và sau với khoảng thời gian rõ.
- Vai trò cụ thể của đội ngũ.
- Phương pháp đo.
- Phản hồi khách hàng đã được phép sử dụng.
- Chứng chỉ hoặc kinh nghiệm liên quan.
- Mẫu đầu ra đã ẩn dữ liệu nhạy cảm.
Không nên:
- Dùng logo khách hàng khi chưa được phép.
- Nhận toàn bộ công lao của dự án có nhiều bên.
- Đưa số liệu tăng trưởng nhưng không nêu baseline.
- Bịa case study với thương hiệu nổi tiếng.
- Đăng dữ liệu ngân sách, doanh thu hoặc hệ thống nội bộ.

Thiết kế Proposal dễ đọc
Thiết kế hỗ trợ quyết định, không thay thế nội dung.
- Dùng hệ heading rõ ràng.
- Mỗi phần trả lời một câu hỏi chính.
- Đoạn văn ngắn và có khoảng trắng.
- Bảng chỉ dùng khi dữ liệu cần so sánh.
- Màu chữ và nền có tương phản tốt.
- Không nhồi quá nhiều icon và biểu đồ trang trí.
- Giữ số trang, tên dự án và phiên bản nhất quán.
- Kiểm tra PDF trên laptop và điện thoại.
- Ảnh có độ phân giải phù hợp nhưng không làm file quá nặng.
- Có mục lục hoặc liên kết điều hướng với tài liệu dài.
- Dùng alt text và tag tài liệu khi yêu cầu accessibility.
Proposal không bắt buộc phải được làm bằng PowerPoint. Định dạng nên phụ thuộc cách người đọc sử dụng: PDF để đọc độc lập, slide cho buổi trình bày, tài liệu web cho cộng tác và hệ thống procurement cho hồ sơ chính thức.
Proposal có thể dùng chữ ký điện tử không?
Proposal có thể được gửi, xác nhận hoặc ký bằng phương tiện điện tử khi phù hợp với loại giao dịch, thỏa thuận của các bên và pháp luật áp dụng. Theo pháp luật Việt Nam hiện hành, thông tin không bị phủ nhận giá trị pháp lý chỉ vì được thể hiện dưới dạng thông điệp dữ liệu; tuy nhiên, giá trị của chữ ký và hiệu lực giao dịch còn phụ thuộc điều kiện cụ thể.
Cần phân biệt:
- Nút “Accept” xác nhận ý định tiếp tục.
- Chữ ký điện tử theo quy trình của nền tảng.
- Chữ ký số dựa trên chứng thư số.
- Hợp đồng được ký hợp lệ.
Nút “Accept”, chữ ký điện tử, chữ ký số và hợp đồng điện tử không mặc nhiên có cùng giá trị trong mọi trường hợp. Với giao dịch có giá trị lớn, dữ liệu nhạy cảm hoặc yêu cầu hình thức riêng, doanh nghiệp cần kiểm tra danh tính và thẩm quyền người ký, phương thức xác thực, audit trail, thời điểm ký, tính toàn vẹn tài liệu, khả năng lưu trữ và quy định chuyên ngành liên quan.
Tracking Proposal cần lưu ý gì?
Một số nền tảng cho biết tài liệu đã được mở, thời điểm truy cập hoặc trang được xem. Những dữ liệu này có thể hỗ trợ follow-up nhưng không cho biết chính xác người đọc đang nghĩ gì.
Không nên suy luận:
- Đọc lâu ở trang giá nghĩa là khách thấy giá quá cao.
- Mở nhiều lần nghĩa là chắc chắn sắp ký.
- Không mở nghĩa là khách không quan tâm.
Tracking có thể chịu ảnh hưởng bởi email security scanner, chuyển tiếp nội bộ, cache và nhiều người cùng mở.
Nếu dùng tracking, doanh nghiệp nên thông báo phù hợp, chỉ thu thập dữ liệu cần thiết, giới hạn người được truy cập và thiết lập thời gian lưu trữ. Dữ liệu mở tài liệu chỉ nên hỗ trợ follow-up; không nên được dùng để suy diễn ý định, gây áp lực hoặc thay thế trao đổi trực tiếp với khách hàng.
Quy trình viết Proposal
- Qualification: xác định cơ hội có phù hợp để đầu tư thời gian hay không.
- Discovery: thu thập mục tiêu, bối cảnh, ngân sách, thời hạn và người quyết định.
- Đọc yêu cầu: phân tích brief, RFP, phụ lục và tiêu chí đánh giá.
- Lập compliance matrix: đối chiếu từng yêu cầu với phần trả lời.
- Xây solution outline: chốt vấn đề, phương pháp, phạm vi và bằng chứng.
- Ước tính nguồn lực: tính giờ công, nhà cung cấp, công cụ, dự phòng và lợi nhuận.
- Viết bản nháp: ưu tiên nội dung trước thiết kế.
- Review chéo: kỹ thuật, tài chính, pháp lý và người bán hàng cùng kiểm tra.
- Thiết kế: chuẩn hóa typography, bảng, biểu đồ và brand.
- QA: tên khách, số liệu, giá, link, phiên bản và file đính kèm.
- Phê duyệt nội bộ: xác nhận thẩm quyền báo giá và cam kết.
- Gửi và follow-up: nêu rõ thời hạn cùng bước trao đổi tiếp theo.
- Lưu bài học: ghi lý do thắng, thua hoặc không quyết định.

Compliance Matrix là gì?
Compliance Matrix là bảng theo dõi từng yêu cầu trong RFP và vị trí câu trả lời trong proposal.
| Yêu cầu | Cách đáp ứng | Vị trí trong Proposal |
|---|---|---|
| Kinh nghiệm cùng ngành | Hai case study và thông tin người tham chiếu. | Phần 9 – Bằng chứng năng lực. |
| Timeline 12 tháng | Kế hoạch theo quý và cột mốc nghiệm thu. | Phần 7 – Timeline. |
| Yêu cầu bảo mật | Quy trình phân quyền và quản lý dữ liệu. | Phần 12 – Điều khoản. |
| Bảng giá chi tiết | Phí theo workstream và chi phí bên thứ ba. | Phụ lục tài chính. |
Bảng này giúp đội viết không bỏ sót yêu cầu và giúp người đánh giá tìm thông tin nhanh hơn.
Follow-up sau khi gửi Proposal
Follow-up không phải nhắn “anh chị xem chưa?” mỗi ngày. Một quy trình phù hợp có thể gồm:
- Xác nhận người nhận đã nhận được đúng file.
- Đề nghị một buổi walkthrough nếu proposal phức tạp.
- Gửi câu trả lời cho câu hỏi còn mở.
- Xác nhận timeline ra quyết định.
- Hỏi có bên liên quan nào cần thêm thông tin.
- Cập nhật phiên bản khi phạm vi thay đổi.
- Ghi rõ ngày hết hiệu lực của giá và nguồn lực.
Nếu khách hàng im lặng, cần xem lại qualification, quy trình mua hàng, ngân sách và người ra quyết định thay vì kết luận proposal “chưa đủ kích thích”.
Dùng AI để viết Proposal thế nào?
AI có thể hỗ trợ:
- Tóm tắt biên bản discovery.
- Lập outline theo RFP.
- Kiểm tra yêu cầu bị bỏ sót.
- Viết lại đoạn dài thành ngôn ngữ rõ hơn.
- Tạo bảng rủi ro hoặc câu hỏi cần xác minh.
- Kiểm tra tính nhất quán thuật ngữ.
Không nên đưa vào hệ thống AI công cộng:
- Dữ liệu mật của khách hàng.
- Thông tin định danh cá nhân.
- Giá hoặc điều khoản chưa công bố.
- Mã nguồn và tài liệu sở hữu trí tuệ.
- RFP bị giới hạn chia sẻ.
AI không chịu trách nhiệm cho số liệu, cam kết, pháp lý hoặc khả năng triển khai. Người phụ trách proposal phải kiểm tra toàn bộ nội dung trước khi gửi.
Proposal cho Marketing và Content
Proposal Marketing cần liên kết hoạt động với mục tiêu kinh doanh và hành trình khách hàng, thay vì chỉ liệt kê số lượng bài đăng, quảng cáo hoặc thiết kế.
Một đề xuất cho chiến dịch Marketing nên làm rõ thị trường, đối tượng ưu tiên, insight, proposition, kênh, ngân sách media, tracking, attribution, deliverable và vai trò của Sales hoặc đội nội bộ.
Với dự án SEO tổng thể, proposal cần tách rõ hoạt động tư vấn, kỹ thuật, nghiên cứu từ khóa, sản xuất nội dung, xây liên kết, báo cáo và những phần cần đội ngũ khách hàng phối hợp.
Nếu có hạng mục báo chí, proposal cho dịch vụ PR báo chí cần nêu phạm vi viết bài, quy trình duyệt, kênh dự kiến, quyền chỉnh sửa của tòa soạn, yêu cầu pháp lý, thời gian đăng và cách nghiệm thu.
Với dịch vụ viết bài SEO, đề xuất nên nêu chủ đề, độ sâu nghiên cứu, quy trình duyệt, số vòng chỉnh sửa, quyền sử dụng hình ảnh, lịch xuất bản và tiêu chuẩn nghiệm thu.
Những lỗi khiến Proposal bị đánh giá thấp
- Sai tên khách hàng: cho thấy quy trình kiểm tra yếu.
- Không trả lời RFP: dùng brochure thay cho hồ sơ đáp ứng.
- Nói về mình quá nhiều: thiếu liên kết với nhu cầu người mua.
- Problem Statement không có nguồn: đưa ra tổn thất và số liệu giả định như sự thật.
- Phạm vi mơ hồ: không biết chính xác sẽ nhận được gì.
- Không nêu phần loại trừ: dễ phát sinh tranh chấp.
- Timeline không có dependency: mọi sự chậm trễ đều bị quy cho nhà cung cấp.
- Giá không giải thích: người đọc không hiểu khác biệt giữa các khoản.
- Cam kết quá mức: hứa ROI, thứ hạng hoặc doanh thu tuyệt đối.
- Case study không liên quan: logo nổi tiếng nhưng không chứng minh năng lực cần thiết.
- Thiết kế lấn át nội dung: nhiều hiệu ứng nhưng khó tìm thông tin.
- Không có CTA: người đọc không biết bước tiếp theo.
- Không quản lý phiên bản: nhiều file có giá và phạm vi khác nhau.
- Không kiểm tra pháp lý: proposal vô tình tạo cam kết ngoài thẩm quyền.
- Follow-up gây áp lực: làm giảm niềm tin thay vì hỗ trợ quyết định.
“Proposal tốt không ép khách hàng cảm thấy sợ bỏ lỡ. Nó giúp người ra quyết định nhìn rõ vấn đề, hiểu phạm vi, đánh giá rủi ro và tin rằng đội ngũ đề xuất có khả năng thực hiện đúng điều đã viết.”
Anh Thắng Giấu Tên – CEO Xuyên Việt Media
Checklist trước khi gửi Proposal
- Đúng tên pháp nhân và người nhận.
- Đúng phiên bản RFP hoặc brief.
- Đã trả lời mọi yêu cầu bắt buộc.
- Executive Summary có thể đọc độc lập.
- Problem Statement có căn cứ.
- Mục tiêu không bị nhầm với deliverable.
- Phạm vi đo được.
- Giả định và phần loại trừ rõ.
- Timeline có mốc duyệt và dependency.
- Vai trò hai bên được phân định.
- Giá, thuế và chi phí bên thứ ba rõ.
- Lịch thanh toán phù hợp cột mốc.
- Case study được phép sử dụng.
- Không có số liệu hoặc cam kết chưa kiểm chứng.
- Điều khoản bảo mật và sở hữu trí tuệ phù hợp.
- Link và file đính kèm hoạt động.
- PDF hiển thị tốt trên nhiều thiết bị.
- Người có thẩm quyền đã phê duyệt.
- Ngày hết hiệu lực được ghi rõ.
- Next Step có người phụ trách và thời hạn.
Câu hỏi thường gặp về Proposal
Proposal có phải báo giá không?
Không. Báo giá tập trung vào giá và điều kiện thương mại; proposal giải thích cả bối cảnh, giải pháp, phạm vi, phương pháp và giá trị đề xuất.
Proposal nên dài bao nhiêu trang?
Không có số trang chuẩn. Tài liệu cần đủ để trả lời yêu cầu và hỗ trợ quyết định. Dự án đơn giản có thể dùng vài trang; RFP phức tạp có thể cần hồ sơ cùng nhiều phụ lục.
Có nên gửi ba gói giá trong mọi Proposal?
Không. Nhiều gói chỉ phù hợp khi khách hàng có thể chọn mức phạm vi khác nhau. RFP yêu cầu cấu hình cố định nên được trả lời đúng yêu cầu trước.
Proposal có phải tài liệu ràng buộc pháp lý không?
Tùy nội dung, cách chấp thuận và pháp luật áp dụng. Doanh nghiệp nên ghi rõ hiệu lực, phần nào không ràng buộc và khi nào hợp đồng chính thức được hình thành.
Có thể dùng AI để viết Proposal không?
Có thể dùng AI để hỗ trợ outline, tóm tắt và kiểm tra, nhưng không được đưa dữ liệu mật vào công cụ không phù hợp. Con người phải xác minh số liệu, cam kết và điều khoản.
Nên follow-up sau khi gửi Proposal khi nào?
Nên thống nhất mốc phản hồi trước khi gửi. Nếu chưa có, có thể xác nhận người nhận đã nhận tài liệu và đề nghị lịch trao đổi phù hợp thay vì nhắn thúc giục liên tục.
Kết luận
Proposal là công cụ giúp biến một cuộc trao đổi thành phương án có thể đánh giá và phê duyệt. Giá trị của nó nằm ở sự rõ ràng về vấn đề, giải pháp, phạm vi, trách nhiệm, chi phí và rủi ro.
Một proposal thuyết phục không cần phóng đại nỗi đau hoặc tạo áp lực tâm lý. Nó cần bám yêu cầu, sử dụng bằng chứng, nêu giả định và giúp người đọc so sánh phương án một cách công bằng.
Trước khi thiết kế đẹp, hãy kiểm tra nội dung có đủ để trở thành căn cứ cho SOW, thương lượng và hợp đồng hay chưa. Proposal càng cụ thể và trung thực, quá trình triển khai sau khi ký càng ít tranh chấp.
Tài liệu tham khảo
- Acquisition.GOV. (2026). Federal Acquisition Regulation 15.203 và 15.303: Requests for Proposals; Responsibilities.
- World Bank. (2025). Standard Procurement Document: Request for Proposals – Consulting Services.
- Văn phòng Quốc hội. (2025). Luật Giao dịch điện tử, Văn bản hợp nhất số 42/VBHN-VPQH.
