Proposal không phải tài liệu — nó là một decision đang chờ được đưa ra
Cách nhìn proposal như một decision architecture: giúp người đọc hiểu họ đang phải quyết định điều gì, uncertainty nằm ở đâu, evidence nào cần có và ask nào cần trở nên rõ ràng.
Đừng bắt đầu bằng slide, hãy bắt đầu bằng decision
Nhiều proposal bắt đầu bằng câu hỏi: cần bao nhiêu trang, bố cục ra sao, mở đầu thế nào.
Nhưng câu hỏi quan trọng hơn là: sau khi đọc xong, người này phải quyết định điều gì?
Proposal là một decision interface
Bên dưới mọi proposal đều có một decision: approve budget, chọn vendor, đồng ý partnership, ưu tiên feature, tài trợ project hoặc cho phép triển khai.
Document chỉ là interface giúp decision đó diễn ra.
Framework: Decision → Uncertainty → Evidence → Confidence → Ask
Decision — người đọc cần quyết định điều gì?
Uncertainty — điều gì khiến họ chưa thể quyết định?
Evidence — bằng chứng nào làm giảm uncertainty?
Confidence — mức độ tin tưởng nào cần đạt?
Ask — hành động cụ thể cuối cùng là gì?
Decision phải đủ cụ thể
“Thuyết phục khách hàng” quá rộng.
“Để khách hàng phê duyệt gói triển khai 3 tháng với scope X, budget Y và kickoff trong tháng này” là một decision rõ hơn.
Uncertainty là thứ thực sự khiến proposal dài ra
Người đọc có thể chưa tin problem đủ lớn, chưa tin solution đúng, chưa tin team làm được, chưa tin timing phù hợp hoặc chưa hiểu risk.
Mỗi section trong proposal nên tồn tại để xử lý một uncertainty cụ thể.
Evidence không phải để gây ấn tượng
Case study, metric, prototype, timeline, testimonial hay benchmark chỉ có giá trị khi chúng làm giảm uncertainty liên quan đến decision.
Confidence không phải certainty tuyệt đối
Không có proposal nào loại bỏ toàn bộ risk.
Mục tiêu là làm uncertainty đủ nhỏ để decision trở nên hợp lý trong điều kiện hiện tại.
The Ask phải là phần rõ nhất
Proposal có thể trình bày rất tốt nhưng thất bại vì kết thúc bằng một CTA mơ hồ như “mong nhận được phản hồi”.
Ask mạnh nói rõ: approve gì, ai approve, khi nào và bước tiếp theo là gì.
Ứng dụng trên Forwork
Proposal trên Forwork có thể được cấu trúc quanh decision thay vì quanh slide: Decision, Problem, Why Now, Insight, Idea, Proof, Plan, Risk, Ask.
Project proof có thể được kéo vào Proposal để giảm uncertainty về capability.
Kết luận
Trước khi viết một proposal, hãy viết một câu duy nhất:
“Sau tài liệu này, tôi muốn người đọc quyết định điều gì?”
Mọi phần còn lại chỉ nên tồn tại để giúp decision đó trở nên rõ hơn, đáng tin hơn và dễ hành động hơn.
Decision → Uncertainty → Evidence → Confidence → Ask.