Sơ đồ pipeline bán hàng cho nhà sáng lập B2B: các trường tối thiểu, giai đoạn và theo dõi hoạt động để dự báo rõ ràng và giữ giao dịch di chuyển mà không làm CRM phình to.

Ban đầu, pipeline của bạn có vẻ rõ ràng vì chỉ có vài giao dịch và hầu hết ngữ cảnh nằm trong đầu bạn. Rồi danh sách tăng lên, bạn bỏ lỡ một follow-up, và pipeline bắt đầu kể một câu chuyện đẹp hơn thực tế. Đó là “pipeline nói dối”: không cố ý, mà vì không có gì trong hệ thống buộc phải nói thật.
Nó biểu hiện theo những mẫu giống nhau:
Phản ứng phổ biến là xây CRM quá mức: nhiều trường hơn, nhiều giai đoạn tùy chỉnh hơn, ghi chú dài hơn. Trớ trêu là điều đó thường làm dự báo tồi đi. Khi việc cập nhật nặng nề, mọi người cập nhật ít hơn, và pipeline âm thầm hỏng.
Một sơ đồ pipeline bán hàng tối thiểu hiệu quả lại làm ngược lại. Nó chỉ đủ cấu trúc để đưa ra quyết định. Nó không cố gắng nắm bắt mọi thứ. Nó nắm những sự thật ít ỏi giúp bạn không tự lừa mình.
Nếu chỉ theo một quy tắc, hãy dùng cái này: mọi giao dịch mở phải có (1) một hành động tiếp theo rõ ràng, (2) một ngày cho hành động đó, và (3) một ngày đóng gắn với dòng thời gian thực của người mua (một cuộc họp, bước pháp lý, đánh giá ngân sách). Nếu thiếu bất kỳ điều nào, giao dịch không còn hoạt động.
Giai đoạn cũng nên có ý nghĩa. Một giao dịch chỉ tiến khi có điều gì đó cụ thể xảy ra, không phải vì cảm giác. Mục tiêu không phải là một bảng điều khiển đẹp. Mục tiêu là một cái nhìn trung thực để bạn điều hành doanh nghiệp.
Một sơ đồ pipeline chỉ hoạt động nếu mọi người đối xử với nó theo cùng một cách. Trước khi thêm trường hay tranh luận về giai đoạn, quyết định một mục pipeline đại diện cho gì.
Mặc định sạch cho B2B là: một giao dịch bằng một quyết định mua. Nếu cùng công ty có thể mua hai lần (hai đội, hai sản phẩm, hai ngân sách), đó là hai giao dịch, không phải một bản ghi lộn xộn.
Giữ các đối tượng đơn giản. Bạn có thể đi rất xa với ba thùng: lead (một người bạn có thể liên hệ), account (công ty), và deal (mua cụ thể bạn đang cố đóng). Nếu bạn làm một mình, bạn thậm chí có thể bỏ qua lead và account chính thức và chỉ đảm bảo mỗi giao dịch rõ tên công ty và liên hệ chính.
Viết vài quy tắc vận hành, đặc biệt nếu có ai khác ngoài bạn chạm vào pipeline:
Ví dụ: Bạn nói chuyện với Alex ở Northwind về một pilot cho đội tài chính. Đó là một giao dịch. Nếu sau một tháng bên sản phẩm muốn hợp đồng riêng, tạo giao dịch thứ hai. Đừng kéo dài một bản ghi để bao hai quyết định.
Một pipeline hữu dụng khi mỗi giao dịch có vài trường bạn thực sự kiểm tra hàng tuần. Thêm trường “phòng khi” và chúng nhanh chóng biến thành trang trí.
Bắt đầu với định dạng tên giao dịch giúp tránh trùng. Một mẫu đơn giản hiệu quả: Công ty - Sản phẩm/Phạm vi - Quý/Tháng. Ví dụ: “Acme - Team plan - Mar 2026.” Điều này giúp thấy rõ khi “Acme - Demo” và “Acme - Follow-up” thực ra là cùng một giao dịch.
Mỗi giao dịch cũng cần định danh rõ:
Vai trò quan trọng vì nó thay đổi bước bạn làm tiếp theo. Một champion cần được hỗ trợ. Người quyết định cần một business case.
Thêm các trường chịu trách nhiệm:
Rồi chỉ thêm phần tiền và thời gian bạn sẽ dùng:
Nếu không chắc về một trường, bỏ nó ra. Bạn luôn có thể thêm sau. Loại bỏ trường sau khi thói quen hình thành thì khó hơn nhiều.
Hầu hết các pipeline “lớn” không thật sự lớn. Chúng đầy các giao dịch đẹp mắt nhưng không có con đường rõ ràng đến một đồng ý.
Bắt đầu với một trường buộc rõ ràng: Use case (phạm vi). Viết điều khách hàng cố gắng đạt được bằng lời thường, cộng với khi nào coi là “xong”. Nếu bạn không thể mô tả kết quả trong hai câu, có lẽ bạn chưa hiểu giao dịch.
Tiếp theo, nắm quy trình quyết định ở một chỗ. Đây không phải danh sách liên hệ. Đó là câu chuyện về cách một quyết định được đưa ra: ai ký, ai có thể chặn, và những bước họ phải theo (kiểm tra bảo mật, pháp lý, mua sắm). Nếu bạn chưa biết người ký, coi giao dịch là sớm.
Thêm một tín hiệu phù hợp giá dù thô. Các khoảng (“<$5k”, “$5-25k”, “$25k+”) ổn, hoặc Likely / Unclear / Unlikely dựa trên những gì bạn nghe. Mục tiêu là ngăn không cho tiến các giao dịch không đủ khả năng chi trả.
Cuối cùng, giữ trường red flags một dòng. Nếu cần đoạn văn, cho vào ghi chú.
Một bộ gọn hoạt động cho hầu hết nhà sáng lập B2B:
Ví dụ: “Muốn dọn dẹp CRM trước khi gia hạn, người ký là VP Sales, cần kiểm tra bảo mật, ngân sách có khả năng $10-20k, cạnh tranh là không làm gì cả, red flag: champion không chủ trì dự án.” Bản ghi duy nhất đó khó khiến bạn tự lừa hơn.
Pipeline trở nên xấu khi nó thành danh sách mong muốn. Cách sửa không phải thêm trường. Là vài tín hiệu hoạt động buộc mỗi giao dịch trả lời một câu hỏi: bước tiếp theo là gì?
Nếu chỉ thêm một lớp vào sơ đồ pipeline của bạn, hãy dùng các trường hoạt động này:
Quy tắc thực tế: nếu một giao dịch không có bước tiếp theo hoặc không có ngày hạn, nó không phải là giao dịch thực sự. Đặt sang chế độ tạm hoặc đóng. Điều này hữu ích cho độ chính xác dự báo hơn bất kỳ mô hình chấm điểm nào.
Giữ “Lý do thua” ngắn để bạn thực sự dùng: giá, không có ngân sách, không có quyết định, chọn đối thủ, thời điểm, không phù hợp.
Ví dụ: Bạn có demo với ops lead vào thứ Ba. Ngay sau cuộc gọi bạn set ngày hoạt động cuối = Thứ Ba, kênh tiếp xúc = meeting, bước tiếp theo = “Gửi 2 case study và xác nhận ai ký,” ngày hạn bước tiếp theo = Thứ Năm. Nếu Thứ Năm trôi qua không phản hồi, giao dịch chuyển sang đỏ mà không ai phải tranh cãi về “tiến triển pipeline.”
Một mô hình giai đoạn tốt làm một việc: nói thật về vị trí mỗi giao dịch, mà không bắt bạn phải trông nom hàng chục bước nhỏ. Nếu bạn không thể nói điều gì phải đúng để giao dịch ở trong một giai đoạn, giai đoạn đó biến thành cảm giác.
Bộ sáu giai đoạn này phù hợp với hầu hết nhà sáng lập B2B:
New: Bạn có tên và lý do để liên hệ. Lần chạm đầu đã thực hiện hoặc đã được lên lịch.
Qualified: Xác nhận vừa đủ phù hợp. Vấn đề có thật, khách hàng khớp ICP của bạn, và có con đường khả thi để mua.
Discovery done: Bạn đã có một cuộc trò chuyện thực sự. Bạn hiểu use case, tiêu chí thành công, và ai tham gia.
Proposal sent: Giá và phạm vi đã ở trong tay khách hàng. Một bước tiếp theo được đặt lịch hoặc được yêu cầu rõ ràng.
Negotiation/Legal: Mua sắm, bảo mật, phê duyệt ngân sách, hoặc sửa hợp đồng đang được tiến hành.
Closed won / Closed lost: Kết quả được đánh dấu và lý do được ghi lại.
Chỉ tiến một giao dịch khi có điều gì đó đã xảy ra trong thực tế (một cuộc họp hoàn tất, một đề xuất gửi, pháp lý bắt đầu). Nếu không có gì xảy ra, giai đoạn giữ nguyên.
Tên giai đoạn không phải là định nghĩa giai đoạn. Nếu bạn chỉ dán nhãn cột “Qualified” hay “Negotiation”, bạn sẽ có giao dịch nằm đó vì không ai đồng ý “đã xong” nghĩa là gì.
Viết quy tắc giai đoạn như các kiểm tra đúng/sai đơn giản. Khi mọi giao dịch trong một giai đoạn chia sẻ cùng các sự thật, pipeline của bạn giữ được độ tin cậy.
Tiêu chí vào nói điều gì phải đúng trước khi giao dịch vào giai đoạn. Tiêu chí ra nói điều gì phải thay đổi để nó tiến lên. Giữ cả hai ngắn và đo được.
Ví dụ:
Nếu bạn không thể viết tiêu chí mà không dùng từ như “tốt”, “mạnh”, hay “quan tâm”, giai đoạn quá mơ hồ.
Đặt tuổi tối đa cho mỗi giai đoạn như một cảnh báo sớm, không phải trừng phạt. Ví dụ: Discovery tối đa 14 ngày, Proposal tối đa 21 ngày. Khi giao dịch chạm giới hạn, kích hoạt reset: đặt bước tiếp theo, đưa lùi, hoặc đóng.
Quyết định hành động mặc định khi tiêu chí không đạt:
Điều này ngăn các “giao dịch xác sống” làm phình dự báo.
Bạn có thể xây sơ đồ pipeline trong vài giờ nếu coi nó như một sản phẩm nhỏ: quy tắc trước, rồi chỉ những gì hỗ trợ những quy tắc đó.
Bắt đầu trên trang trắng, không phải bên trong công cụ. Viết giai đoạn và tiêu chí vào/ra bằng tiếng thường. Nếu bạn không thể giải thích một giai đoạn trong một câu, có lẽ đó là hai giai đoạn (hoặc không phải giai đoạn).
Luồng xây dựng đơn giản:
Thực hiện một bài kiểm tra thực tế khi thiết lập: lấy một giao dịch bạn đang làm và thử chuyển nó từng giai đoạn. Nếu bạn phải đoán, tiêu chí quá mơ hồ.
Một quy tắc đáng áp dụng sớm: nếu ngày hoạt động tiếp theo trống, giao dịch không thể ở giai đoạn hoạt động.
Phần lớn bloat bắt đầu từ ý tốt: bạn muốn chính xác hơn, nên thêm trường, thêm giai đoạn, và nhiều ghi chú. Hệ quả là ngược lại. Mọi người ngừng cập nhật, và pipeline trở thành nơi giao dịch đi để già đi.
Nếu hai giai đoạn cảm thấy giống nhau, chúng sẽ được dùng giống nhau. “Discovery”, “Deep discovery”, và “Discovery follow-up” thường chỉ nghĩa là “chúng tôi đã nói chuyện”, mà không có sự kiện tiếp theo rõ ràng. Giai đoạn chỉ nên thay đổi khi có điều gì thực sự thay đổi.
Bài kiểm tra nhanh: nếu bạn không thể nói điều gì phải đúng để vào giai đoạn trong một câu, có lẽ giai đoạn thừa.
Ngày đóng chỉ hữu ích nếu nó gắn với một lý do. Hãy coi đó như ngày mốc quyết định tiếp theo (phê duyệt ngân sách, cuộc họp mua sắm, hạn ký), và cập nhật khi sự kiện đó chuyển.
Ghi chú dài che giấu điều bạn cần nhất: điều gì xảy ra cuối cùng và bước tiếp theo là gì. Giữ ghi chú ngắn, và theo dõi hoạt động bằng ngày hoạt động cuối cộng bước tiếp theo (với người chịu trách nhiệm và ngày hạn).
Không có định nghĩa, “qualified” trở thành “họ nghe có vẻ tốt.” Chọn 3–4 kiểm tra phải đúng (vấn đề, người mua, thời hạn, và một dạng ngân sách). Nếu thiếu một thứ, chưa qualified.
Pipeline chỉ lớn mà không bao giờ thu nhỏ sẽ không còn là pipeline mà thành nghĩa địa. Đóng thua nhanh khi giao dịch không hoạt động hoặc không phù hợp, và ghi một lý do rõ ràng để bạn rút kinh nghiệm.
Chọn một thời điểm cố định mỗi tuần (30 phút là đủ) và coi đó như cuộc họp với chính bạn trong tương lai. Vệ sinh pipeline ít liên quan đến thêm trường hơn là đảm bảo mỗi giao dịch vẫn có con đường thực sự đi tới.
Một quy trình rà soát đơn giản:
Ví dụ cụ thể: nếu một giao dịch được đánh dấu “Proposal sent” nhưng không có cuộc họp nào đặt để xem xét, nó không ở giai đoạn proposal. Đưa lùi, đặt bước tiếp theo, và ngưng tính nó vào dự báo cho đến khi người mua lại tương tác.
Bạn bán công cụ phân tích B2B cho một công ty thương mại điện tử 50 người. Sau cuộc gọi đầu, bạn tạo giao dịch và chỉ điền những gì sẽ dùng trong tuần tới. Một schema đơn giản có ích vì nó buộc sự rõ ràng, không giấy tờ.
Ngay sau cuộc gọi, bản ghi trông như:
Giao dịch bắt đầu ở Discovery. Bạn chỉ tiến khi lời mời lịch được chấp nhận (không phải khi ai đó “nghe có vẻ quan tâm”). Sau demo, trigger để vào evaluation là một yêu cầu cụ thể (ví dụ, “Bạn có thể kết nối với Shopify và dữ liệu kho không?”), sau đó là kiểm tra kỹ thuật đã thỏa thuận.
Bây giờ chỗ nghẽn: CFO im lặng sau khi thấy giá. Nhật ký của bạn cho thấy hai lần follow-up, không trả lời, và ngày bước tiếp theo trôi qua. Quy tắc đơn giản: nếu không có bước tiếp theo đã đồng ý, giao dịch không thể ở Proposal.
Vì vậy bạn thực hiện bước trung thực: hoặc lùi lại về evaluation (nếu cần sponsor mới hoặc thông tin thiếu), hoặc đóng thua (nếu người quyết định không tương tác theo ngày đã đặt). Trong ví dụ này, bạn lùi lại, cập nhật các bên liên quan (Ops kéo vào quản lý tài chính), đặt ngày bước tiếp theo mới, và chỉ trở lại Proposal khi CFO xác nhận cuộc họp quyết định.
Một sơ đồ pipeline chỉ hoạt động nếu bạn tin tưởng nó. Cách nhanh nhất để tới đó là bắt đầu tối thiểu và dùng nó trong 30 ngày. Điều đó cho bạn thấy thứ bạn thực sự dùng, không phải thứ bạn nghĩ sẽ cần.
Trong tháng đầu, kỷ luật: nếu một trường không thay đổi quyết định, loại bỏ nó. Nếu một quyết định cứ lặp lại và bạn không thể trả lời từ pipeline, thêm đúng một trường để lấp khoảng trống đó.
Bài kiểm tra đơn giản trước khi thêm trường mới: “Nếu trường này trống, chúng tôi không thể quyết liệu ____.”
Nếu bạn muốn xây một CRM tuỳ chỉnh nhẹ thay vì ép một công cụ chung, những công cụ như Koder.ai (koder.ai) có thể giúp khi bạn đã viết xong giai đoạn, trường bắt buộc và quy tắc xác thực. Việc tạo và lặp trên một app đơn giản dễ dàng hơn khi schema đã rõ.
Một pipeline “nói dối” khi nó cho thấy tiến triển mà thực tế không được hậu thuẫn bởi hành động của người mua. Nguyên nhân phổ biến nhất là thiếu bước tiếp theo cụ thể, ngày hoạt động cuối cùng đã cũ, và ngày đóng liên tục bị đẩy ra mà không có mốc thời gian do người mua xác nhận.
Ba trường không thể thiếu cho mọi giao dịch mở: một hành động tiếp theo cụ thể, ngày hạn cho hành động đó, và ngày đóng gắn với một sự kiện thực tế của người mua như cuộc họp, đánh giá hoặc bước ký kết. Nếu bất kỳ trường nào trống, coi giao dịch là không hoạt động cho tới khi điền đầy.
Mặc định là “một giao dịch = một quyết định mua.” Nếu cùng một công ty có thể mua hai lần qua các đội, ngân sách hoặc hợp đồng khác nhau, hãy tạo hai giao dịch thay vì gộp vào một.
Bắt đầu với tên giao dịch giúp tránh trùng lặp, một công ty, một liên hệ chính, một người phụ trách, giá trị dự kiến, ngày đóng mục tiêu và nguồn cơ hội. Sau đó thêm đủ thông tin để giải thích vì sao giao dịch nên đóng: use case, quy trình quyết định và phù hợp về giá.
Một câu ngắn về use case cộng với tiêu chí thành công buộc bạn phải hiểu kết quả thực tế, không chỉ sự quan tâm của người mua. Nếu bạn không thể mô tả rõ kết quả, thường là giao dịch còn quá sớm để dự báo.
Viết quy trình quyết định dưới dạng một câu chuyện ngắn: ai ký, ai có thể chặn, và những bước cần xảy ra (bảo mật, pháp lý, mua sắm). Nếu bạn chưa biết người ký, giữ giao dịch ở giai đoạn sớm và đặt bước tiếp theo để tìm người đó và quy trình.
Dùng khoảng giá thô hoặc Likely/Unclear/Unlikely dựa trên những gì bạn nghe được. Mục tiêu không phải tính toán chính xác, mà là ngăn không cho giao dịch tiến nếu ngân sách không phù hợp với đề xuất của bạn.
Theo dõi ngày hoạt động cuối cùng, bước tiếp theo, ngày hạn bước tiếp theo và lý do đóng khi giao dịch kết thúc. Ghi chú có thể tồn tại, nhưng những trường hoạt động này là thứ giữ cho giao dịch không trôi và buộc bạn quyết định bước tiếp theo.
Chỉ chuyển giai đoạn khi điều gì đó thực sự xảy ra: cuộc gọi discovery hoàn tất, đề xuất thực sự được gửi, hoặc bộ phận pháp lý được giới thiệu. Nếu việc chuyển giai đoạn có thể xảy ra chỉ vì bạn “cảm thấy tốt,” định nghĩa giai đoạn quá mơ hồ và dự báo sẽ trôi.
Đặt số ngày tối đa cho mỗi giai đoạn như một cảnh báo sớm, rồi kích hoạt reset khi đạt giới hạn. Hành động mặc định là: đặt bước tiếp theo thực sự, đưa giao dịch lùi lại giai đoạn phù hợp với sự thật, hoặc đóng nó là không có quyết định sau các nỗ lực follow-up rõ ràng.