Menu
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Đang tải...

Bài 47 — Discovery for B2B Enterprise

Zero to One Product Discovery Bài 47/60

Mở đầu — vì sao bài này quan trọng

Nếu bạn từng làm discovery cho sản phẩm B2C — phỏng vấn vài chục người dùng, dựng landing page, đo tỷ lệ đăng ký — rồi nghĩ rằng có thể áp y nguyên công thức đó vào sản phẩm bán cho doanh nghiệp, thì bài học này sẽ giúp bạn tránh một cú vấp rất đắt giá.

Lý do đơn giản: trong B2C, người dùng và người trả tiền thường là một. Bạn thuyết phục được một người, bạn có một khách hàng. Nhưng trong B2B Enterprise — bán phần mềm, dịch vụ hay giải pháp cho các tổ chức lớn — một quyết định mua hàng có thể liên quan đến 6, 8, thậm chí hơn chục con người, mỗi người có động cơ, nỗi sợ và quyền lực khác nhau. Người dùng cuối thích sản phẩm chưa chắc đã mua được. Người ký hợp đồng có khi chưa từng mở phần mềm của bạn lên một lần nào.

Discovery cho B2B Enterprise vì thế không phải là "phỏng vấn user kỹ hơn", mà là một dạng discovery khác về bản chất: bạn đang vẽ bản đồ một hệ sinh thái ra quyết định, hiểu chu kỳ ngân sách của doanh nghiệp, và tìm ra ai là người thực sự đẩy được thương vụ về đích. Hiểu sai cấu trúc này là nguyên nhân số một khiến các startup B2B đốt sạch tiền sau những "buổi demo rất hứng khởi" mà không bao giờ ra hợp đồng.

Bài này sẽ trang bị cho bạn cách làm discovery đúng cho bối cảnh enterprise — một kỹ năng cực kỳ giá trị tại Việt Nam và Đông Nam Á, nơi thị trường B2B SaaS đang bùng nổ nhưng số người làm được discovery bài bản còn rất hiếm.

Khái niệm cốt lõi

User ≠ Buyer ≠ Champion ≠ Decision-maker

Đây là nền tảng của toàn bộ bài học. Trong một thương vụ enterprise, bạn cần phân biệt rạch ròi bốn vai trò (đôi khi do bốn người khác nhau đảm nhiệm):

  • User (người dùng cuối): người trực tiếp dùng sản phẩm hằng ngày. Ví dụ: nhân viên kế toán dùng phần mềm hóa đơn. Họ quan tâm sản phẩm có dễ dùng không, có giúp họ đỡ khổ không. Nhưng họ thường không có ngân sách và không quyết định mua.
  • Buyer (người mua / người giữ ngân sách): người kiểm soát tiền, thường là trưởng phòng hoặc giám đốc một bộ phận. Họ quan tâm chi phí, ROI (lợi tức đầu tư), và rủi ro ngân sách.
  • Champion (người vô địch nội bộ): người tin vào giải pháp của bạn và sẵn sàng "chiến đấu" cho nó bên trong tổ chức. Đây là tài sản quý nhất trong mọi thương vụ B2B. Không có champion, deal gần như không thể đi xa.
  • Decision-maker (người ra quyết định cuối): người đặt bút ký hoặc nói "đồng ý". Có thể là CEO, CFO, hoặc một hội đồng. Họ quan tâm bức tranh chiến lược, không quan tâm tính năng nhỏ.
Ngoài bốn vai chính, enterprise còn có các gatekeeper (người gác cổng) như bộ phận IT (lo về bảo mật, tích hợp), bộ phận Pháp chế (lo hợp đồng, dữ liệu), và Mua sắm/Procurement (lo đàm phán giá). Mỗi nhóm này có quyền phủ quyết — họ không làm deal thắng được, nhưng đủ sức làm deal chết.

Nhiệm vụ discovery của bạn là lập bản đồ tất cả những vai trò này cho từng khách hàng tiềm năng, hiểu động cơ riêng của mỗi vai, và xác định đường đi từ user yêu thích sản phẩm đến chữ ký cuối cùng.

Multi-stakeholder và chu kỳ bán hàng dài

Vì nhiều người tham gia, nên chu kỳ ra quyết định kéo dài — thường 3 đến 12 tháng với enterprise lớn, có khi hơn. Điều này thay đổi cách bạn làm discovery:

  • Bạn không thể chỉ phỏng vấn một người rồi kết luận. Bạn cần phỏng vấn chéo nhiều vai trong cùng một tổ chức để ráp lại bức tranh thật.
  • Một câu trả lời "chúng tôi rất thích ý tưởng này" từ một user không phải tín hiệu mua. Tín hiệu thật nằm ở chỗ: có ai đó sẵn sàng giới thiệu bạn lên cấp trên không? Có ai sẵn sàng bỏ thời gian dự họp với bạn không?
  • Bạn phải khám phá cả quy trình mua hàng nội bộ của họ: ai phê duyệt, qua bao nhiêu cửa, mất bao lâu.

Chu kỳ ngân sách (budget cycle)

Đây là yếu tố rất Việt Nam mà nhiều founder bỏ qua. Doanh nghiệp lớn lập ngân sách theo quý hoặc theo năm tài chính. Nếu sản phẩm của bạn không nằm trong ngân sách đã duyệt của năm nay, dù họ thích đến đâu, tiền cũng phải chờ kỳ lập ngân sách sau.

Discovery tốt phải trả lời được: Khoản chi cho sản phẩm của tôi sẽ lấy từ ngân sách nào? Ngân sách đó được duyệt khi nào? Ai là người đề xuất khoản chi đó? Nếu khách hàng nói "đầu năm sau công ty mới lập ngân sách chuyển đổi số", bạn biết ngay timeline thực tế của mình, thay vì ảo tưởng chốt deal trong tháng này.

Pain phải đủ lớn để vượt "chi phí chuyển đổi"

Trong enterprise, không mua một giải pháp mới là lựa chọn mặc định an toàn nhất. Đổi sang công cụ mới đồng nghĩa với rủi ro, đào tạo lại nhân viên, tích hợp hệ thống — tất cả đều tốn kém. Vì vậy discovery B2B phải đào sâu đến mức định lượng được nỗi đau: pain này khiến họ mất bao nhiêu tiền mỗi tháng? Bao nhiêu giờ nhân công? Nếu không trả lời được con số, bạn chưa tìm được pain đủ lớn.

Tình huống thực tế

Ví dụ 1 — Startup HRTech bán cho chuỗi bán lẻ tại TP.HCM

Một startup giả định tên NhanSuViet làm phần mềm chấm công và quản lý ca cho các chuỗi bán lẻ. Họ phỏng vấn 15 quản lý cửa hàng và nhận về phản hồi tuyệt vời: "Bảng tính Excel chấm công của chúng tôi loạn lắm, phần mềm này cứu cánh!". Tự tin, họ ký hợp đồng demo với một chuỗi 40 cửa hàng.

Sáu tháng trôi qua, deal không nhúc nhích. Khi làm lại discovery cho đúng, họ phát hiện:

  • User (quản lý cửa hàng) đúng là thích sản phẩm, nhưng họ không có quyền mua.
  • Buyer là Giám đốc Vận hành — người chưa từng được nói chuyện. Mối quan tâm của ông không phải Excel loạn, mà là tỷ lệ gian lận chấm công đang làm công ty thất thoát ước tính 200 triệu/năm.
  • Gatekeeper IT lo lắng phần mềm có tích hợp được với hệ thống ERP đang dùng không.
  • Ngân sách công nghệ năm đó đã chốt; khoản mới phải chờ kỳ lập kế hoạch tháng 11.
Bài học: NhanSuViet đã phỏng vấn đúng người để xây sản phẩm (user) nhưng sai người để bán hàng (buyer/decision-maker). Khi họ điều chỉnh thông điệp từ "hết loạn Excel" sang "giảm thất thoát do gian lận chấm công 200 triệu/năm", và bắt đầu phỏng vấn Giám đốc Vận hành, deal mới có động lực thật. Discovery B2B phải chạm tới động cơ của người giữ tiền, không chỉ người dùng.

Ví dụ 2 — Base.vn và bài toán nhiều người ra quyết định

Lấy bối cảnh gần với thực tế thị trường Việt Nam: các nền tảng quản trị doanh nghiệp như Base.vn bán bộ công cụ làm việc cho hàng nghìn doanh nghiệp. Một bài học kinh điển trong loại sản phẩm này là: bộ phận nào "mua" trước sẽ định hình toàn bộ cách triển khai.

Giả sử một công ty 300 nhân sự quan tâm. Nếu champion là Trưởng phòng Nhân sự, họ sẽ đẩy phân hệ quản lý công việc và quy trình nội bộ. Nhưng decision-maker là CEO lại quan tâm "bức tranh dữ liệu toàn công ty". Còn IT thì lo về việc dữ liệu nhân sự nhạy cảm được lưu ở đâu.

Một đội discovery giỏi sẽ chủ động phỏng vấn cả ba vai trước khi định hình gói bán: hỏi Trưởng phòng Nhân sự về pain vận hành, hỏi CEO về chỉ số chiến lược ông muốn thấy, hỏi IT về yêu cầu bảo mật. Từ đó họ thiết kế một "câu chuyện mua hàng" mà mỗi vai đều thấy mình trong đó.

Bài học: Trong enterprise, bạn không bán một sản phẩm — bạn bán nhiều câu chuyện cho nhiều vai cùng lúc. Discovery phải khám phá đủ "ngôn ngữ giá trị" của từng vai: vận hành cho user, ROI cho buyer, chiến lược cho decision-maker, an toàn cho IT.

Ví dụ 3 — Phần mềm logistics bán cho doanh nghiệp sản xuất FDI

Một startup logistics SaaS tiếp cận một nhà máy FDI Nhật tại Bình Dương. Sau buổi demo, trưởng phòng kho rất thích và nói "để tôi báo cáo lên". Founder mừng rỡ tưởng sắp chốt. Nhưng ba tháng im lặng.

Khi đào lại, họ phát hiện quy trình mua sắm của tập đoàn Nhật bắt buộc: mọi phần mềm trên 500 triệu phải qua hội đồng đánh giá ở trụ sở chính tại Tokyo, kèm bộ checklist bảo mật ISO mà startup chưa đáp ứng. Trưởng phòng kho — champion của họ — thậm chí không biết hết quy trình này.

Bài học: Discovery B2B enterprise phải khám phá quy trình mua hàng nội bộ như một đối tượng nghiên cứu riêng. Câu hỏi "Nếu anh chị quyết định dùng, bước tiếp theo trong công ty mình là gì? Ai cần phê duyệt? Có yêu cầu tuân thủ nào không?" quan trọng không kém câu hỏi về pain. Với doanh nghiệp FDI hay tập đoàn đa quốc gia, người ra quyết định thật có khi không nằm ở Việt Nam.

Hướng dẫn từng bước

Bước 1 — Lập bản đồ stakeholder (Stakeholder Map). Với mỗi khách hàng tiềm năng, vẽ ra sơ đồ: ai là user, buyer, champion, decision-maker, và gatekeeper (IT, pháp chế, mua sắm). Đánh dấu những ô bạn chưa biết — đó chính là việc discovery cần lấp đầy.

Bước 2 — Xác định và nuôi dưỡng champion. Trong những buổi phỏng vấn đầu, tìm người thể hiện sự sốt sắng thật sự (chủ động chia sẻ pain, sẵn sàng giới thiệu bạn lên cấp trên). Hỏi thẳng: "Nếu thấy giải pháp này hữu ích, anh/chị có sẵn sàng giúp tôi trình bày với người ra quyết định không?". Sự sẵn lòng đó là tín hiệu vàng.

Bước 3 — Phỏng vấn chéo nhiều vai. Đừng dừng ở user. Nhờ champion kết nối bạn với buyer và decision-maker. Với mỗi vai, dùng bộ câu hỏi khác nhau: user hỏi về quy trình hằng ngày; buyer hỏi về chi phí và ROI; decision-maker hỏi về ưu tiên chiến lược.

Bước 4 — Định lượng pain. Quy nỗi đau ra con số: tiền mất, giờ công lãng phí, doanh thu bỏ lỡ, rủi ro tuân thủ. Pain mơ hồ không thắng được "chi phí chuyển đổi" trong tổ chức.

Bước 5 — Khám phá quy trình mua và chu kỳ ngân sách. Hỏi rõ: khoản chi này lấy từ ngân sách nào, được duyệt khi nào, qua bao nhiêu cửa phê duyệt, có yêu cầu bảo mật/pháp lý nào không. Đây là phần discovery mà người làm B2C hay quên nhất.

Bước 6 — Tổng hợp thành "Account Map". Với mỗi tài khoản, ghép tất cả phát hiện thành một bức tranh: các vai, động cơ từng vai, champion, đường đi tới chữ ký, rào cản (IT, ngân sách), và timeline thực tế. Đây là đầu ra discovery cho bán hàng B2B.

Lỗi thường gặp & mẹo

Lỗi 1 — Nhầm "user thích" với "tổ chức mua". Demo hứng khởi không phải tín hiệu doanh thu. Mẹo: sau mỗi buổi tích cực, hỏi ngay "Bước tiếp theo cụ thể trong công ty mình là gì?". Câu trả lời mơ hồ = chưa có động lực mua thật.

Lỗi 2 — Chỉ nói chuyện với một người. Một người không đại diện cho tổ chức. Mẹo: luôn nhắm tới ít nhất ba vai (user, buyer/champion, một gatekeeper) trước khi kết luận về một account.

Lỗi 3 — Bỏ qua gatekeeper IT và Pháp chế. Nhiều deal chết ở phút chót vì không vượt được rà soát bảo mật. Mẹo: hỏi sớm về yêu cầu tuân thủ, lưu trữ dữ liệu, tích hợp hệ thống — đừng để đến lúc đàm phán giá mới phát hiện.

Lỗi 4 — Phớt lờ chu kỳ ngân sách. Founder hay đặt timeline chốt deal theo nhu cầu sống còn của mình, không theo lịch ngân sách của khách. Mẹo: hỏi thẳng về năm tài chính và kỳ lập ngân sách của khách để dự báo timeline thực tế.

Lỗi 5 — Dùng một thông điệp cho mọi vai. "Dễ dùng" không lay động được CFO. Mẹo: chuẩn bị bản đồ giá trị riêng cho từng vai và kiểm chứng từng thông điệp trong discovery.

Mẹo nâng cao: Hỏi về thương vụ phần mềm gần nhất họ từng mua — ai tham gia, mất bao lâu, vướng ở đâu. Đây là cách nhanh nhất để hiểu quy trình mua nội bộ thật, vì họ kể về quá khứ cụ thể thay vì phỏng đoán tương lai.

Bài tập thực hành

Chọn một sản phẩm B2B (của bạn hoặc giả định) và một khách hàng tiềm năng cụ thể. Thực hiện:

  • Vẽ Stakeholder Map cho khách hàng đó: liệt kê người (hoặc chức danh) đảm nhiệm vai user, buyer, champion, decision-maker, và các gatekeeper IT/Pháp chế/Mua sắm. Đánh dấu ô nào bạn đang phải phỏng đoán.
  • Soạn ba bộ câu hỏi phỏng vấn khác nhau cho ba vai: user, buyer, decision-maker. Mỗi bộ 5 câu, bám đúng động cơ riêng của vai đó.
  • Định lượng pain: viết một câu khẳng định nỗi đau kèm con số, dạng "Vấn đề X khiến công ty mất khoảng [số tiền/số giờ] mỗi [tháng/năm]". Ghi rõ bạn cần hỏi ai để xác thực con số này.
  • Phác thảo quy trình mua: viết ra giả thuyết về các bước phê duyệt nội bộ và chu kỳ ngân sách của khách, rồi liệt kê những câu hỏi discovery để kiểm chứng giả thuyết đó.
Nếu có thể, hãy thực hiện ít nhất một cuộc phỏng vấn thật với một vai bạn chưa từng nói chuyện trước đây, và cập nhật lại Stakeholder Map sau buổi đó.

Tóm tắt

  • Trong B2B Enterprise, User ≠ Buyer ≠ Champion ≠ Decision-maker — discovery phải lập bản đồ và phỏng vấn chéo tất cả các vai, không chỉ người dùng cuối.
  • Quyết định mua mang tính đa bên (multi-stakeholder)chu kỳ dài (3–12 tháng); demo hứng khởi không phải tín hiệu doanh thu.
  • Champion là tài sản quý nhất — người sẵn sàng chiến đấu cho bạn bên trong tổ chức.
  • Phải khám phá chu kỳ ngân sáchquy trình mua hàng nội bộ (gồm gatekeeper IT, Pháp chế, Mua sắm) như đối tượng nghiên cứu riêng.
  • Pain phải được định lượng bằng con số để vượt qua "chi phí chuyển đổi" — vốn là lý do khiến doanh nghiệp mặc định không mua gì cả.
  • Mỗi vai cần một thông điệp giá trị riêng: vận hành cho user, ROI cho buyer, chiến lược cho decision-maker, an toàn cho IT.
Làm chủ được tư duy này, bạn sẽ ngừng đốt thời gian vào những deal "vui mà không thật", và biết chính xác cần đi qua những ai để biến sự yêu thích thành chữ ký.