Ứng dụng quy trình đề xuất cho freelancer: từ Nháp đến Thắng/Thua

Tại sao đề xuất bị bỏ quên

Hầu hết freelancer không mất đề xuất vì công việc kém. Họ mất vì đề xuất biến mất.

Tình trạng lộn xộn thường thấy: một bản nháp trong tài liệu, một file PDF cuối cùng trong thư mục, tin nhắn cuối cùng của khách chôn sâu trong email hoặc chat, và "trạng thái" duy nhất là những gì bạn còn nhớ. Khi bạn bận giao hàng cho khách, rất dễ quên ai đang chờ báo giá và ai cần được nhắc lần hai.

Đề xuất rơi rụng khắp nơi như:

• Một Google Doc tên “Proposal v7 FINAL (2)”
• Một chuỗi email với ba tiêu đề khác nhau
• Một ghi chú trong điện thoại với ngày theo dõi
• Một nhắc lịch không có ngữ cảnh
• Trong đầu bạn (cho đến khi quá trễ)

Đề xuất bị bỏ lỡ vì một lý do đơn giản: không có một nơi duy nhất hiển thị hành động tiếp theo. Nếu bạn không thể trả lời "Tôi nên làm gì tiếp, và cho khách nào?" trong 10 giây, các bước theo dõi sẽ bị trì hoãn. Trì hoãn biến thành mất hợp đồng, ngay cả khi khách có hứng thú.

Đó chính là pipeline, nói đơn giản: một tập trạng thái rõ ràng cho biết mỗi đề xuất đang ở đâu và bước tiếp theo là gì. Một ứng dụng pipeline đề xuất không phải là cỗ máy bán hàng cầu kỳ. Nó là bảng điểm và danh sách việc cần làm gộp lại.

Giữ kỳ vọng thực tế. Bạn không cần xây một CRM phức tạp với dự báo, vùng miền, và các báo cáo bạn sẽ không bao giờ đọc. Bạn chỉ cần một công cụ nhẹ phù hợp cách bạn thực sự làm việc và làm cho "bước tiếp theo" trở nên rõ ràng.

Điều này ngăn được gì. Bạn gửi báo giá thiết kế web vào thứ Ba và bảo sẽ theo dõi vào thứ Sáu. Thứ Sáu bận. Đến thứ Hai bạn không nhớ đã kiểm tra chưa. Một pipeline nhỏ với một cột hiển thị rõ "Đang chờ khách" và ngày theo dõi tiếp theo dừng mất mát thầm lặng đó.

Một pipeline đề xuất nhẹ nên làm gì

Một ứng dụng pipeline đề xuất có một nhiệm vụ: giữ mọi đề xuất chuyển từ Nháp đến Thắng hoặc Thua với tối thiểu nỗ lực. Nếu nó tạo thêm công việc hành chính, bạn sẽ ngừng dùng ngay khi cần nó nhất.

Trước khi thiết kế, quyết định những gì bạn phải biết về một đề xuất ngay cả vài tháng sau. Giữ ở mức vài chi tiết giúp bạn theo dõi, dự báo thu nhập, và học được điều gì bán chạy.

Một tối thiểu thực tế cho mỗi đề xuất:

• Khách hàng (cá nhân hoặc công ty) và phương thức liên hệ
• Loại dịch vụ (ví dụ: làm mới website, app di động, SEO hàng tháng)
• Giá ước tính (hoặc khoảng) và ngày bắt đầu dự kiến
• Ngày theo dõi tiếp theo
• Trạng thái hiện tại (Nháp, Đã gửi, Đang thương lượng, Thắng, Thua)

Rồi định nghĩa "xong" để app đáng tin cậy. Một đề xuất không nên nằm mãi ở trạng thái Đã gửi. "Xong" nghĩa là các mục bị treo kích hoạt nhắc nhở, kết quả được ghi khi bạn nhận được phản hồi, và bạn có thể thấy báo cáo đơn giản mà không cần xuất bảng tính.

Giữ phạm vi nhỏ lúc đầu. Một người dùng, một workspace, và các trường đơn giản tốt hơn hệ thống lớn bạn không bao giờ duy trì. Nếu bạn gửi ba đề xuất trong tuần (hai cho "landing page + nội dung" và một cho "hỗ trợ theo tháng"), một pipeline ép buộc lịch theo dõi và kết quả sẽ nhanh cho bạn biết dịch vụ nào chốt tốt hơn và nơi bạn mất thời gian.

Chọn trạng thái phù hợp với quy trình thực tế

Trạng thái chỉ hữu ích nếu chúng phản ánh ngày làm việc thực tế của bạn, không phải một quy trình lý tưởng mà bạn sẽ không theo. Giữ tập nhỏ để kéo một thẻ tiến lên cảm thấy nhẹ nhàng.

Một tập thực tế:

• Đang soạn
• Sẵn sàng gửi
• Đã gửi
• Cần theo dõi
• Đang thương lượng
• Thắng
• Thua

Giữ tên ngắn và gợi hành động. Nếu bạn không biết phải làm gì tiếp khi đọc một trạng thái, đổi tên nó.

Tiếp theo, đặt vài quy tắc đơn giản để không có đề xuất nào biến thành zombie.

Ví dụ:

• Một đề xuất không thể chuyển sang Đã gửi nếu nó chưa có khách hàng, loại dịch vụ, tổng giá, và khoảng thời gian giao hàng.
• Đang thương lượng nên có nghĩa là khách đã trả lời và phạm vi, giá hoặc điều khoản đang thay đổi.
• Thắng nên yêu cầu dấu hiệu rõ ràng: hợp đồng ký, tiền đặt cọc, hoặc một "đồng ý" bằng văn bản.

Ngày theo dõi là rào chắn khác. Không phải mọi trạng thái đều cần nhắc, nhưng một số thì có. Một mặc định tốt là: Đã gửi và Cần theo dõi phải có ngày theo dõi. Đang thương lượng cũng có thể yêu cầu, nhưng chỉ khi bước tiếp theo là việc của bạn.

Một kịch bản nhanh: bạn gửi báo giá thiết kế web vào thứ Hai. Nếu không nghe lại trước thứ Năm, nó hiện là Cần theo dõi. Nếu khách trả lời "bớt blog và giảm giá được không?", bạn chuyển sang Đang thương lượng và đặt ngày theo dõi cho ngày hôm sau. Đó là đủ cấu trúc để giữ đà mà không biến workflow thành giấy tờ.

Thiết kế dữ liệu: khách hàng, đề xuất, dịch vụ, hoạt động

Ứng dụng pipeline đề xuất sống hoặc chết dựa trên dữ liệu. Nếu cấu trúc quá lỏng bạn sẽ bỏ qua trường. Nếu quá chặt bạn sẽ ngừng dùng. Nhắm vào một tập đối tượng nhỏ bạn có thể tin cậy, rồi thêm chi tiết chỉ khi thật sự cần.

Bắt đầu với bốn đối tượng cốt lõi: Khách hàng, Đề xuất, Dịch vụ, và Hoạt động.

Các bảng cốt lõi (và những gì chúng lưu)

Giữ phiên bản đầu đơn giản:

• Clients (Khách hàng): tên, người liên hệ, email, ghi chú (và tuỳ chọn kích thước công ty)
• Proposals (Đề xuất): tiêu đề, client_id, loại_dịch_vụ (hoặc services), giá trị, trạng thái, ngày_gửi, ngày_theo_dõi_tiếp_theo, lý_do_kết_quả
• Services (Dịch vụ): tên (ví dụ: “Làm mới website”, “Đánh giá SEO”), tuỳ chọn khoảng giá mặc định
• Activities (Hoạt động): proposal_id, loại (ghi chú, nhắc, gọi, email), dấu thời gian, chi tiết

Với đề xuất, ngày_theo_dõi_tiếp_theo là mạng lưới an toàn cho bạn trong tương lai. lý_do_kết_quả quan trọng khi bạn đánh dấu Thắng hoặc Thua, vì “Thua: quá đắt” và “Thua: thời gian” dẫn tới biện pháp khác nhau.

Một dịch vụ cho mỗi đề xuất hay nhiều dịch vụ?

Một loại dịch vụ cho mỗi đề xuất là thiết lập nhanh nhất và hiệu quả nếu bạn bán gói rõ ràng. Nhiều dịch vụ cho mỗi đề xuất hợp lý hơn khi bạn hay bán gộp (thiết kế + phát triển + bảo trì), nhưng nó làm phức tạp hơn. Bạn sẽ cần bảng nối (như ProposalServices) và báo cáo sẽ khó hơn.

Một thỏa hiệp tốt là bắt đầu với một loại dịch vụ và chỉ thêm nhiều khi bạn thấy đề xuất thực tế thường gồm nhiều dịch vụ.

Hoạt động giúp bạn có lịch sử nhẹ mà không phải mò trong email. Sau khi gửi đề xuất, ghi nhanh như “Gửi v2, khách hỏi về timeline.” Sau đó bạn thấy mọi thứ rõ ràng.

Lên kế hoạch màn hình: board, list, chi tiết, báo cáo

Một ứng dụng pipeline đề xuất chỉ cần vài màn hình nếu mỗi màn hình trả lời một câu hỏi rõ ràng. Mục tiêu là tốc độ: mở, thấy việc cần làm, sửa một mục, xong.

Bảng pipeline (xem hàng ngày)

Đây là màn hình bạn ở lại nhiều nhất. Mỗi cột là một trạng thái. Mỗi thẻ nên hiển thị vừa đủ để quyết bước tiếp theo:

• Tên khách
• Giá trị đề xuất (hoặc retainer ước tính)
• Ngày theo dõi tiếp theo
• Thẻ loại dịch vụ

Hành động nhanh quan trọng hơn bố cục hoàn hảo. Từ thẻ (hoặc ngăn chi tiết nhỏ), bạn nên thay đổi trạng thái, đặt ngày theo dõi, thêm ghi chú, và đánh dấu Thắng hoặc Thua mà không phải điền form dài.

Danh sách đề xuất (xem tìm kiếm và bắt kịp)

Bảng tốt cho luồng, nhưng list tốt hơn để tìm. Dùng bảng kiểu table với bộ lọc như trạng thái, khách, loại dịch vụ, và quá hạn theo dõi. Đây là view để bắt kịp khi tuần bận.

Trang chi tiết (sửa nhanh, không giấy tờ)

Bạn chỉ cần hai trang: trang Đề xuất và trang Khách hàng.

Trang Đề xuất là nơi timeline (ghi chú, thay đổi trạng thái, ngày theo dõi) cùng các trường chính như giá trị và loại dịch vụ. Trang Khách hàng là nơi bối cảnh sống: thông tin liên hệ, đề xuất hiện có, và hoạt động gần đây.

Nếu đổi ngày theo dõi mất 30 giây, bạn sẽ không cập nhật. Tối ưu hóa các trang này cho sửa một chạm.

Báo cáo đơn giản (một màn hình)

Một báo cáo nhẹ là đủ lúc đầu: tỉ lệ chốt theo loại dịch vụ và thời gian trung bình để chốt. Nó nên trả lời hai câu: “Tôi nên bán gì nhiều hơn?” và “Giao dịch chững ở đâu?”

Xây từ con số 0 đến có thể dùng được

Một ứng dụng pipeline đề xuất hữu dụng không phải là “CRM đầy đủ”. Nó là nơi thấy cái gì còn hoạt động, cái gì mắc kẹt, và việc cần làm hôm nay.

Xây phiên bản đầu dùng trong cùng ngày

Bắt đầu với mô hình dữ liệu và vài bản ghi giả để thử luồng. Tạo một khách hàng với hai đề xuất và ít nhất hai loại dịch vụ (ví dụ, “Làm mới website” và “SEO định kỳ”).

Rồi xây hai màn hình chính: bảng (cột theo trạng thái) và form chi tiết đề xuất. Bảng để quét hàng ngày. Form để cập nhật chính xác.

Một thứ tự xây dựng giúp tiến nhanh:

• Mô hình: Khách hàng, Đề xuất, Loại dịch vụ, Hoạt động
• Giao diện: Board view + Form chi tiết đề xuất (trạng thái, giá trị, ngày gửi, ngày theo dõi)
• Quy tắc: Chặn việc chuyển trạng thái nếu thiếu trường chính (ví dụ, Đã gửi yêu cầu ngày gửi)
• Nhắc: Thông báo khi đến ngày theo dõi (và tuỳ chọn khi đề xuất vừa chuyển sang Đã gửi)
• Dashboard: Đếm theo trạng thái và một biểu đồ tỉ lệ chốt theo loại dịch vụ

Thêm kiểm tra “không thể chuyển nếu thiếu…”

Đây là thứ làm app đáng tin. Ví dụ: bạn kéo đề xuất từ Nháp sang Đã gửi nhưng app ngăn nếu không có email khách hoặc không có số tiền. Ma sát nhỏ đó ngăn dữ liệu lộn xộn sau này.

Một quy tắc mặc định giữ mọi thứ khỏi trôi: mọi đề xuất mở phải có ngày theo dõi. Nếu thiếu, hiển thị cảnh báo trên bảng.

Một định nghĩa “có thể dùng” đơn giản:

• Bạn có thể thêm đề xuất dưới 60 giây
• Bạn có thể thấy ai cần theo dõi hôm nay chỉ trong một cái liếc
• Trạng thái thay đổi nhất quán (không có đề xuất nửa gửi)
• Tỉ lệ chốt nhìn thấy theo loại dịch vụ
• Nhắc giữ im lặng khi bạn đã chủ động

Nhắc theo trạng thái mà không làm phiền

Nhắc hoạt động tốt nhất khi liên kết với khoảnh khắc rõ ràng trong pipeline, không phải một tiếng chuông lịch ngẫu nhiên. Nếu app biết trạng thái hiện tại, nó chỉ thúc bạn khi đề xuất có nguy cơ bị bỏ quên.

Bạn không cần nhiều trigger. Một thiết lập đơn giản như:

• Khi đề xuất chuyển sang Đã gửi, yêu cầu ngày theo dõi.
• Vào ngày theo dõi, gửi một nhắc duy nhất.
• Nếu vẫn không phản hồi sau X ngày ở trạng thái Đã gửi, tạo tự động một tác vụ theo dõi.

Giữ văn bản nhắc ngắn và tập trung hành động. Chỉ bao gồm ai, về đề xuất nào, và bước tiếp theo:

• "Theo dõi {Khách}: {Đề xuất} - kiểm tra nhanh"
• "{Khách} / {Đề xuất} - hỏi xem có muốn sửa trước khi duyệt không"
• "{Khách} / {Đề xuất} - xác nhận timeline và ngày bắt đầu"

Thêm giới hạn để không trở thành tiếng ồn: tối đa một nhắc cho mỗi đề xuất mỗi ngày, và có các tuỳ chọn Snooze (1 ngày, 3 ngày, tuần sau).

Theo dõi kết quả mỗi nhắc cũng vậy. Lưu nhật ký nhỏ: hoàn thành, hoãn (đến khi nào), bỏ qua, hoặc đã gửi.

Ví dụ: bạn đánh dấu “Làm mới website - Acme Co” là Đã gửi vào thứ Hai và đặt theo dõi thứ Năm. Sáng thứ Năm bạn nhận một nhắc và hoãn sang thứ Sáu. Thứ Sáu bạn theo dõi, đánh dấu nhắc hoàn thành, và bộ đếm "không phản hồi sau X ngày" được đặt lại.

Theo dõi tỉ lệ chốt theo loại dịch vụ (và dùng con số)

Ứng dụng pipeline đề xuất chỉ có giá trị nếu giúp bạn quyết định bước tiếp theo. Cách dễ nhất là theo dõi tỉ lệ chốt theo loại dịch vụ, không chỉ tổng thể. “Thiết kế website” và “bảo trì hàng tháng” thường hoạt động như hai mảng kinh doanh khác nhau.

Trước tiên, làm cho kết quả nhất quán:

• Thắng nghĩa là có một đồng ý rõ ràng (hợp đồng ký, đặt cọc, hoặc ngày bắt đầu xác nhận).
• Thua nghĩa là bạn không còn theo đuổi nữa (họ nói không, chọn bên khác, hoặc nó im lặng đủ lâu để bạn chắc là chết).

Chọn một quy tắc và bám theo, nếu không số liệu sẽ nhiễu.

Giữ lý do thua ngắn và nhất quán:

• Giá
• Thời gian
• Không khớp phạm vi
• Không phản hồi
• Chọn đối thủ

Rồi tính tỉ lệ chốt theo loại dịch vụ trong khoảng thời gian bạn dùng (30 hoặc 90 ngày). Nếu bạn gửi 12 đề xuất "Chiến lược thương hiệu" và thắng 3, tỉ lệ là 25%. Nếu gửi 6 "Xây trang đích" và thắng 4, đó là 67%. Không cần hoàn hảo, chỉ cần ổn định.

Thêm "thời gian để chốt" để bạn không tự đánh lừa. Theo dõi số ngày từ khi Gửi đến lúc Thắng hoặc Thua. Bạn có thể thấy "Đánh giá SEO" chốt trong 5-10 ngày, trong khi "Xây website toàn bộ" mất 30-45 ngày. Điều đó thay đổi tần suất theo dõi và cách dự báo thu nhập.

Làm cho dữ liệu hữu dụng với một quy tắc duy nhất: nếu một dịch vụ có tỉ lệ chốt thấp và thời gian chốt dài, thu gọn gói (phạm vi, chứng minh, giá) hoặc chọn lọc khách hơn khi viết đề xuất. Nếu dịch vụ có tỉ lệ chốt cao, bảo vệ nó: tái sử dụng công thức hiệu quả và tăng giá cẩn trọng.

Những cạm bẫy thường gặp khi xây CRM cho đề xuất

Cách nhanh nhất làm ứng dụng pipeline vô dụng là làm nó rối. Freelancer bắt đầu với ý tốt, rồi có công cụ họ không tin.

Một cạm bẫy là có quá nhiều trạng thái cùng nghĩa. Nếu bạn không thể giải thích khác biệt giữa “Đã gửi”, “Đã nộp”, “Đã giao”, và “Đang xem xét” trong một câu, có lẽ chỉ cần một.

Cạm bẫy khác là để Đã gửi thành nghĩa địa. Nếu bạn không yêu cầu ngày theo dõi, bảng sẽ đầy đề xuất không biết làm gì. Một quy tắc đơn giản sửa hầu hết: mọi đề xuất ở Đã gửi phải có bước tiếp theo.

Một vài sai lầm khác phá tập trung:

• Trộn đề xuất với lead chung, khiến pipeline thành hộp thư lộn xộn
• Không ghi lý do Thua, nên lặp lại sai về giá và phạm vi
• Tự động hoá quá sớm, mất thời gian tinh chỉnh nhắc hơn là gửi đề xuất

Giữ nhắc nhở nhàm nhưng cụ thể. Một nhắc liên quan đến ngày theo dõi thường đã đủ. Quy tắc thêm chờ dữ liệu thật để biết cái nào hữu ích, cái nào gây ồn.

Nếu bạn mất ba đề xuất liên tiếp với lý do “thời gian quá dài”, đó là tín hiệu nên đề xuất một giai đoạn nhỏ đầu tiên, không phải thêm năm trạng thái mới.

Danh sách nhanh trước khi dựa vào nó hoàn toàn

Trước khi coi pipeline là nguồn tin cậy duy nhất, đảm bảo không có gì nằm lơ lửng và bước tiếp theo rõ ràng.

Mở view pipeline và bấm giờ. Bạn nên hiểu ưu tiên hôm nay trong dưới 30 giây. Nếu phải click vào nhiều đề xuất để tìm bước tiếp theo, thiết kế đang giấu trường quan trọng nhất.

Checklist:

• Mọi đề xuất mở hiển thị trạng thái rõ và ngày theo dõi tiếp theo. Nếu không có bước tiếp theo, đóng nó.
• View “hôm nay” hiển thị hành động bạn có thể làm ngay (theo dõi, gửi, sửa), không chỉ danh sách gây stress.
• Khi có Thắng hoặc Thua, bạn ghi được số cuối cùng và một lý do ngắn.
• Tỉ lệ chốt theo loại dịch vụ hiển thị cho cửa sổ gần đây bạn dùng (30-90 ngày).
• Nhắc có thể hoãn, và bạn không nhận trùng lặp cho cùng đề xuất trong cùng một ngày.

Thử nghiệm nhỏ: tạo ba đề xuất mẫu cho các dịch vụ khác nhau, kéo chúng qua các trạng thái, và kích hoạt nhắc. Nếu bạn phá nó trong năm phút, bạn sẽ phá nó khi tuần bận.

Ví dụ: một tuần đơn giản với đề xuất (và bài học)

Thứ Hai bạn gửi năm đề xuất. Ba cho gói thiết kế web, hai cho retainer hỗ trợ hàng tháng. Mọi thứ bắt đầu ở Nháp, sau đó sang Đã gửi khi email ra đi.

Đến thứ Tư, trạng thái kể một câu chuyện:

• Hai đề xuất thiết kế chuyển sang Đã xem (bạn thấy khách mở tài liệu)
• Một đề xuất thiết kế vẫn Đã gửi (chưa mở)
• Một retainer vào Đang thương lượng (khách yêu cầu chỉnh giờ)
• Một retainer Thắng (họ ký)

Nhắc giữ bạn khỏi bỏ lỡ. Quy tắc “Đã xem nhưng không trả lời 2 ngày” thúc bạn theo dõi hai lead thiết kế vào sáng thứ Sáu. Quy tắc “Đã gửi nhưng chưa xem 3 ngày” bắt trường hợp lặng, bạn gửi lại thông điệp ngắn và bước rõ ràng.

Cuộc sống thật thì lộn xộn. Một khách trả lời muộn chủ Nhật “xin lỗi, tuần bận” và muốn bắt đầu tháng sau, bạn chuyển sang Đang giữ thay vì để nó mục ở Đã gửi. Thương lượng vẫn hoạt động, nhưng nhắc kiểm tra một lần, không mỗi ngày.

Cuối tuần, tỉ lệ chốt theo loại dịch vụ khiến bạn ngạc nhiên: retainer thắng 1/2, thiết kế web 0/3. Tuần sau bạn thay đổi: thu gọn phạm vi thiết kế thành hai tầng và thêm deadline phản hồi đơn giản.

Bước tiếp theo: ra mắt phiên bản nhỏ, rồi cải thiện

Cách nhanh nhất nhận giá trị là ra mắt phiên bản nhỏ mà bạn sẽ mở mỗi ngày. Một app pipeline đề xuất không cần template, tự động phức tạp, và biểu đồ ngày đầu. Nó cần cho bạn biết đã gửi gì, gì đang chờ, và bạn nên làm gì tiếp.

Đặt trạng thái sao cho mỗi trạng thái trả lời một câu: bước tiếp theo là gì? Nếu bạn không thể giải thích trạng thái trong một câu, nó sẽ làm chậm bạn.

Ba hành động làm trong tuần này:

• Đặt 5–7 trạng thái (Nháp, Đã gửi, Cần theo dõi, Đang thương lượng, Thắng, Thua thường là đủ)
• Xây view bảng để bạn kéo đề xuất giữa trạng thái trong vài giây
• Bật nhắc chỉ cho trường hợp quan trọng (Cần theo dõi, và Đang thương lượng khi bước tiếp theo là của bạn)

Khi vòng lặp cơ bản trở nên tự nhiên, thêm cải tiến từng bước. Thứ tự tốt là nhắc trước (để không bỏ lỡ), báo cáo sau (để học), rồi template sau nữa (để tiết kiệm thời gian). Nếu thêm mọi thứ cùng lúc, bạn không biết cái nào hữu ích và cái nào là ồn.

Nếu muốn xây mà không viết nhiều mã, AppMaster là một lựa chọn thực tế: bạn có thể mô hình hóa cơ sở dữ liệu (khách hàng, đề xuất, dịch vụ) và xây UI cùng quy tắc trạng thái ở một chỗ, rồi lặp khi quy trình thay đổi.

Giữ việc nâng cấp nhỏ và đo lường được. Sau một tuần, hỏi: tôi theo dõi nhanh hơn và mất ít phản hồi hơn không? Sau một tháng, hỏi: dịch vụ nào chốt tốt nhất, và dịch vụ nào cần ưu đãi hoặc tăng giá?

Đối xử với phiên bản đầu như công cụ cá nhân, không phải sản phẩm. Nếu mất hơn 30 giây để ghi đề xuất mới hoặc đẩy nó tiến, đơn giản hóa trường và màn hình trước khi thêm. Khi mọi thứ trở nên nhẹ nhàng, bạn sẽ thực sự dùng, và dữ liệu sẽ đáng tin.