Viết proposal để khách hàng Mỹ thực sự trả lời bạn

Điều khiến một proposal bị xóa trong vài giây

Người nhận proposal ở phía công ty Mỹ thường đọc lướt dòng đầu tiên và quyết định có đọc tiếp hay không trong vài giây. Một proposal mở đầu bằng lời chào chung chung kiểu tôi là lập trình viên có nhiều năm kinh nghiệm, sẵn sàng giúp bạn hoàn thành dự án, gần như chắc chắn bị bỏ qua, vì nó không nhắc gì đến dự án cụ thể đang cần làm.

Dấu hiệu khác khiến proposal bị loại ngay là độ dài sai chỗ: quá ngắn để chứng minh bạn đã đọc kỹ yêu cầu, hoặc quá dài với những đoạn giới thiệu bản thân không liên quan. Người đọc đang tìm câu trả lời cho một câu hỏi duy nhất, bạn có hiểu đúng việc họ cần làm không, mọi thứ khác chỉ nên xuất hiện nếu phục vụ câu trả lời đó.

Cấu trúc của một proposal được đọc hết

Một proposal hiệu quả thường mở đầu bằng việc nhắc lại đúng vấn đề của khách hàng theo cách của riêng bạn, không sao chép lại đề bài. Điều này cho người đọc thấy bạn hiểu vấn đề, không chỉ đọc tiêu đề. Sau đó là một hướng tiếp cận ngắn gọn, không cần chi tiết đến từng bước, chỉ đủ để cho thấy bạn đã có suy nghĩ cụ thể chứ không phải trả lời chung chung cho mọi dự án.

• Một câu mở đầu nhắc đúng vấn đề của dự án này, không phải mẫu câu dùng chung
• Một hướng tiếp cận ngắn, đủ cụ thể để chứng minh bạn đã suy nghĩ về bài toán
• Một ví dụ công việc liên quan trực tiếp, không phải toàn bộ portfolio
• Một câu hỏi làm rõ, nếu phạm vi công việc còn điểm chưa rõ ràng
• Một lời đề nghị bước tiếp theo cụ thể, ví dụ một cuộc gọi ngắn

Cách nói về phạm vi công việc mà không hứa hẹn quá đà

Rất dễ bị cám dỗ nói có thể làm mọi thứ để tăng khả năng được chọn, nhưng điều đó thường phản tác dụng với khách hàng Mỹ đã có kinh nghiệm làm việc với nhiều freelancer trước đó. Họ nhận ra ngay khi một phản hồi quá chung chung để có giá trị thật. Cách an toàn hơn là nói rõ phần nào bạn tự tin làm ngay, phần nào cần trao đổi thêm để hiểu rõ trước khi cam kết thời gian.

Cam kết về mức thù lao và lịch trình nên chờ đến khi phạm vi công việc được viết rõ bằng văn bản, không nên chốt trong tin nhắn đầu tiên. Trong mô hình làm việc qua Panorama Systems, phần này đã được xử lý trước: khi một dự án được đề xuất, phạm vi, mức thù lao và thời gian đã có sẵn, nên proposal thực chất là buổi trao đổi kỹ thuật, không phải một vòng thương lượng giá.

Trình bày công việc cũ: bằng chứng, không phải danh sách

Một đường link tới sản phẩm đang hoạt động, hoặc một đoạn mô tả ngắn về vai trò cụ thể của bạn trong một dự án, có sức nặng hơn nhiều một danh sách công nghệ đã từng dùng qua. Khách hàng muốn biết bạn đã tự mình quyết định điều gì trong dự án đó, không chỉ tham gia vào một đội ngũ lớn mà không rõ phần đóng góp của bạn.

Nếu công việc cũ có ràng buộc bảo mật, việc mô tả loại vấn đề đã giải quyết, không nêu tên khách hàng, vẫn đủ để chứng minh năng lực mà không vi phạm cam kết trước đó.

Khi proposal đến từ một hồ sơ đã có sẵn thông tin dự án

Khi một dự án được đề xuất qua hồ sơ tại /talent, phần lớn công việc của một proposal thông thường, tức thuyết phục khách hàng đọc hết tin nhắn, đã được làm sẵn nhờ hồ sơ khớp với yêu cầu dự án. Điều còn lại là một cuộc trao đổi ngắn để xác nhận hai bên hiểu đúng phạm vi công việc và lịch làm việc, gần với một buổi phỏng vấn kỹ thuật ngắn hơn là một lượt chào hàng.

Một proposal tốt trả lời câu hỏi khách hàng chưa kịp hỏi: bạn có thực sự hiểu việc họ cần làm không.