Mở đầu — vì sao bài này quan trọng
Trong B2B SaaS, câu hỏi "khách hàng trả tiền cho cái gì?" không bao giờ chỉ là câu hỏi về con số. Nó là câu hỏi về đơn vị tính tiền (pricing unit) — bạn quy đổi giá trị mình tạo ra thành cái gì để khách hàng trả tiền: theo số người dùng (seat), theo lượng sử dụng (usage), hay theo một đơn vị giá trị nào đó gắn liền với kết quả kinh doanh của họ (value unit)?
Đây là một trong những quyết định khó đảo ngược nhất mà một PM phụ trách pricing phải đưa ra. Bạn có thể đổi giá khá dễ — tăng 10%, giảm 15% là chuyện thường. Nhưng đổi đơn vị tính tiền — ví dụ từ "trả theo số nhân viên" sang "trả theo số tin nhắn gửi đi" — gần như là làm lại toàn bộ hệ thống billing, viết lại trang pricing, đào tạo lại đội sales, và quan trọng nhất là tái định nghĩa lời hứa giá trị với khách hàng.
Bài học hôm nay đi sâu vào ba mô hình tính tiền B2B kinh điển và một mô hình lai. Quan trọng hơn, bạn sẽ hiểu một sự đánh đổi cốt lõi mà mọi nhà thiết kế pricing đều phải đối mặt: pricing power (khả năng thu được nhiều tiền hơn khi khách hàng nhận nhiều giá trị hơn) đấu với predictability (khả năng dự báo doanh thu một cách ổn định). Hiểu được sự đánh đổi này, bạn sẽ chọn đúng mô hình cho từng sản phẩm, từng giai đoạn.
Khái niệm cốt lõi
Ba đơn vị tính tiền nền tảng
Per-seat (theo ghế / theo người dùng). Khách hàng trả tiền theo số người trong tổ chức được cấp quyền truy cập. Ví dụ kinh điển là Slack, Microsoft 365, Notion, Figma. Mô hình này dễ hiểu đến mức ai cũng nhẩm được hóa đơn: "công ty mình 50 người, gói 8 đô/người/tháng, vậy là 400 đô/tháng". Đó là sức mạnh lớn nhất của nó — sự minh bạch và khả năng dự báo.
Per-usage (theo lượng sử dụng). Khách hàng trả tiền theo lượng tiêu thụ thực tế: số lượng truy vấn, dung lượng lưu trữ, số giờ tính toán, số GB dữ liệu, số API call. Snowflake (tính theo compute credit và storage), Twilio (theo số tin nhắn / phút gọi), AWS, Vercel (theo bandwidth, build minutes, function execution) là những ví dụ điển hình. Hóa đơn ở đây co giãn theo mức độ khách hàng thực sự dùng sản phẩm.
Value unit (theo đơn vị giá trị). Đây là cấp độ tinh vi nhất: bạn tính tiền theo một đơn vị phản ánh trực tiếp giá trị kinh doanh mà khách hàng nhận được, chứ không phải theo số người hay lượng tài nguyên kỹ thuật. Ví dụ: Shopify tính một phần phí theo doanh số bán hàng của cửa hàng; Stripe tính theo số tiền giao dịch xử lý; một phần mềm tuyển dụng có thể tính theo "số ứng viên được tuyển thành công"; một công cụ gửi email marketing tính theo số contact trong danh sách. Value unit khó tìm và khó đo, nhưng khi tìm đúng, nó tạo ra sự gắn kết tuyệt vời giữa "khách hàng thành công" và "bạn kiếm được nhiều tiền".
Sự đánh đổi trung tâm: Pricing power vs Predictability
Hãy hình dung một trục. Một đầu là predictability — doanh thu ổn định, dễ dự báo, khách hàng biết trước họ sẽ trả bao nhiêu. Đầu kia là pricing power — khả năng doanh thu của bạn tự động phình ra khi khách hàng dùng nhiều hơn, thành công hơn.
- Per-seat nghiêng mạnh về predictability. Bạn ký hợp đồng 100 ghế, bạn biết gần như chính xác doanh thu năm tới. Nhưng nó có một điểm yếu chí mạng: doanh thu của bạn bị "ngắt kết nối" khỏi giá trị. Nếu khách hàng dùng sản phẩm 10 tiếng/ngày thay vì 1 tiếng, bạn vẫn thu đúng từng đó tiền. Tệ hơn, per-seat khuyến khích khách hàng chia sẻ tài khoản để né phí, và dễ bị bào mòn khi xu hướng AI/tự động hóa khiến "số người" giảm trong khi "khối lượng công việc" tăng.
- Per-usage nghiêng mạnh về pricing power. Khi khách hàng dùng nhiều hơn, bạn thu nhiều hơn — doanh thu bám sát giá trị. Đây là lý do các công ty hạ tầng (infra) như Snowflake có Net Revenue Retention (NRR) thường trên 150-170%: khách hàng cũ tự nhiên chi nhiều hơn theo thời gian mà không cần bán thêm. Nhưng cái giá phải trả là predictability kém: cả bạn và khách hàng đều khó dự báo hóa đơn cuối tháng, dễ gây "bill shock" (sốc hóa đơn) và làm CFO bên mua khó chịu.
- Value unit lý tưởng nhất về mặt pricing power nếu bạn tìm được đơn vị đúng. Nó vừa bám giá trị, vừa khiến khách hàng cảm thấy công bằng ("tôi trả nhiều vì tôi bán được nhiều"). Nhưng nó là khó nhất để thực thi: phải đo lường được, phải minh bạch, và đơn vị giá trị phải nằm trong tầm kiểm soát của khách hàng (họ phải tin rằng dùng sản phẩm của bạn giúp tăng đơn vị đó).
Vì sao mô hình lai (hybrid) ra đời
Vì không mô hình đơn lẻ nào hoàn hảo, phần lớn công ty trưởng thành chuyển sang hybrid: một phần cố định (base / platform fee hoặc theo seat) + một phần biến đổi theo usage hoặc value. Phần cố định mang lại nền doanh thu dự báo được (predictability), phần biến đổi nắm bắt upside khi khách hàng phát triển (pricing power). Vercel là ví dụ kinh điển: gói Pro có phí nền 20 đô/người/tháng cộng phụ phí theo bandwidth và compute vượt hạn mức. Ta sẽ học sâu về hybrid ở Bài 21, nhưng ở đây cần nắm: hybrid là cách thực dụng nhất để cân bằng hai đầu của trục đánh đổi.
Tình huống thực tế
Ví dụ 1 — Slack: sức mạnh và giới hạn của per-seat
Slack chọn per-seat ngay từ đầu, ở mức khoảng 8-12 đô/người dùng hoạt động/tháng. Lựa chọn này cực kỳ thông minh cho giai đoạn tăng trưởng: nó dễ hiểu, dễ mua, và quan trọng là Slack thậm chí chỉ tính tiền những người thực sự hoạt động (fair billing) — bạn thêm 100 nhân viên nhưng chỉ 60 người dùng thường xuyên thì chỉ trả cho 60. Điều này giảm ma sát mua hàng đáng kể và giúp Slack lan rộng theo kiểu "bottom-up" trong doanh nghiệp.
Diễn giải: per-seat phù hợp khi giá trị sản phẩm tỷ lệ thuận với số người dùng — và với công cụ giao tiếp, một người dùng thêm = một người nữa được kết nối, nên đơn vị "seat" phản ánh giá trị khá tốt.
Bài học rút ra: per-seat thắng lớn khi (1) sản phẩm dùng theo nhóm, (2) giá trị tăng theo số người tham gia, và (3) bạn cần khách hàng dự báo được chi phí để dễ duyệt ngân sách. Nhưng hãy cảnh giác: nếu một ngày AI agent thay thế con người gửi tin nhắn, "số seat" sẽ không còn bám sát giá trị nữa — và đó chính xác là rủi ro dài hạn mà mọi công ty per-seat đang lo lắng.
Ví dụ 2 — Snowflake: pricing power tối đa với consumption
Snowflake tính tiền theo lượng tiêu thụ: compute (đo bằng "credit" theo thời gian chạy của warehouse) và storage (theo TB). Không có khái niệm "số người dùng" trong hóa đơn cốt lõi. Kết quả là khi một khách hàng doanh nghiệp chạy ngày càng nhiều phân tích dữ liệu, hóa đơn của họ tự động tăng — Snowflake thu được giá trị mà không cần đàm phán lại hợp đồng. Đây là động cơ tạo ra NRR cực cao mà nhà đầu tư rất yêu thích.
Mặt trái: khách hàng phải có cả một văn hóa "FinOps" để theo dõi và tối ưu chi phí, vì hóa đơn có thể nhảy vọt nếu ai đó viết một truy vấn tệ chạy suốt đêm. Snowflake phải đầu tư lớn vào dashboard giám sát usage, cảnh báo, và công cụ ước tính chi phí để giảm "bill shock".
Bài học rút ra: per-usage là vũ khí pricing power mạnh nhất cho sản phẩm hạ tầng, nơi mức tiêu thụ co giãn rõ rệt giữa các khách hàng. Nhưng nó đòi hỏi bạn đầu tư vào tính minh bạch — nếu khách không dự báo được chi phí, predictability kém sẽ giết chết niềm tin.
Ví dụ 3 — Một startup logistics Việt Nam chuyển từ seat sang value unit
Hãy lấy một ví dụ gần gũi (giả định hợp lý nhưng phản ánh đúng thực tế thị trường). Giả sử "GiaoNhanh", một startup SaaS ở TP.HCM bán phần mềm quản lý vận đơn cho các shop bán hàng online và nhà xe. Ban đầu họ tính 200.000đ/nhân viên/tháng. Vấn đề xuất hiện nhanh: một nhà xe nhỏ chỉ có 2 nhân viên nhưng xử lý 50.000 đơn/tháng trả y hệt một shop có 2 nhân viên xử lý 500 đơn. Khách hàng giá trị cao nhất lại trả ít nhất — pricing power gần như bằng không, và doanh thu không bám theo giá trị họ tạo ra.
GiaoNhanh chuyển sang hybrid: phí nền 300.000đ/tháng (đủ để dự báo doanh thu sàn) + 500đ cho mỗi vận đơn xử lý vượt 1.000 đơn đầu tiên. "Vận đơn xử lý" chính là value unit — nó phản ánh trực tiếp quy mô kinh doanh của khách. Kết quả mô phỏng: nhà xe 50.000 đơn giờ trả khoảng 300.000 + 49.000 × 500đ = gần 24,8 triệu/tháng, trong khi shop nhỏ vẫn chỉ trả quanh mức 300.000đ. Doanh thu tổng tăng mạnh nhưng khách nhỏ không bị đẩy giá, nên tỷ lệ rời bỏ ở phân khúc nhỏ không tăng.
Bài học rút ra: khi "số người dùng" không tương quan với giá trị, hãy đi tìm đơn vị giá trị thật sự (ở đây là số vận đơn). Đơn vị giá trị tốt phải thỏa: đo được rõ ràng, tăng khi khách thành công, và khách tin rằng sản phẩm của bạn góp phần làm nó tăng.
Hướng dẫn từng bước
Đây là quy trình thực hành để chọn đơn vị tính tiền cho một sản phẩm B2B:
- Liệt kê các "đơn vị" ứng viên. Brainstorm tất cả cách có thể tính: seat, active user, số dự án, số đơn hàng, GB lưu trữ, số API call, doanh số khách hàng, số giao dịch, số contact... Viết hết ra.
- Chấm điểm từng đơn vị theo 3 tiêu chí.
- Đặt đơn vị lên trục đánh đổi. Đơn vị nào nghiêng về predictability (như seat) làm nền; đơn vị nào nghiêng về pricing power (usage/value) làm phần biến đổi.
- Quyết định mô hình. Nếu giá trị bám chặt số người và khách cần dự báo: chọn per-seat thuần. Nếu sản phẩm hạ tầng, tiêu thụ co giãn mạnh: nghiêng về usage. Nếu muốn cân bằng (đa số trường hợp): chọn hybrid base + variable.
- Kiểm tra "fairness" hai chiều. Mô phỏng hóa đơn cho 3-4 chân dung khách điển hình (nhỏ, vừa, lớn). Khách lớn có trả tương xứng giá trị không? Khách nhỏ có bị đẩy giá đến mức rời bỏ không?
- Thiết kế cơ chế minh bạch. Nếu chọn usage/value, bắt buộc phải có dashboard theo dõi mức dùng, cảnh báo ngưỡng, và công cụ ước tính chi phí. Predictability không tự nhiên có — bạn phải xây nó.
- Lên kế hoạch đo lường sau khi ra mắt. Theo dõi NRR, tỷ lệ churn theo phân khúc, và mức độ phàn nàn về hóa đơn để biết đơn vị đã chọn có đang phục vụ cả hai phía không.
Lỗi thường gặp & mẹo
Lỗi 1 — Chọn đơn vị "dễ tính cho mình" thay vì "bám giá trị cho khách". Per-seat phổ biến vì nó dễ triển khai về kỹ thuật, không phải vì nó luôn đúng. Nếu giá trị sản phẩm không tỷ lệ với số người, per-seat sẽ khiến bạn để tiền trên bàn ở khách lớn và đẩy giá quá cao ở khách nhỏ.
Lỗi 2 — Chọn usage thuần mà không xây công cụ minh bạch. Hệ quả là "bill shock", khách hoảng loạn, churn tăng và đội support quá tải. Mẹo: luôn kèm dashboard usage real-time, cảnh báo khi sắp vượt ngưỡng, và cho phép đặt "spending cap" (trần chi tiêu).
Lỗi 3 — Đơn vị giá trị nằm ngoài tầm kiểm soát của khách. Nếu bạn tính theo "doanh số của khách" nhưng sản phẩm của bạn gần như không ảnh hưởng đến doanh số đó, khách sẽ thấy bất công và phản kháng. Đơn vị value chỉ hợp lệ khi khách tin sản phẩm bạn góp phần làm nó tăng.
Lỗi 4 — Quên rằng đội Tài chính/Mua hàng bên khách ghét sự bất định. Trong B2B, người duyệt ngân sách thường khác người dùng sản phẩm. CFO thích con số cố định để lập kế hoạch. Mẹo: dùng phần base cố định đủ lớn để họ yên tâm, để phần variable nắm upside.
Mẹo vàng — Bắt đầu nghiêng về predictability khi còn non, dịch dần sang pricing power khi trưởng thành. Startup giai đoạn đầu cần khách dễ mua và doanh thu dự báo được để sống sót, nên seat hoặc hybrid nhẹ thường an toàn. Khi đã có vị thế và hiểu rõ hành vi dùng, hãy tăng tỷ trọng usage/value để khai thác pricing power.
Bài tập thực hành
Chọn một sản phẩm B2B bạn đang làm (hoặc một sản phẩm bạn biết rõ, ví dụ Base.vn, Sapo, KiotViet, Haravan).
- Liệt kê tối thiểu 5 đơn vị tính tiền ứng viên cho sản phẩm đó.
- Lập một bảng chấm điểm: mỗi đơn vị chấm 1-5 cho ba tiêu chí value alignment, measurability, predictability. Cộng điểm và xếp hạng.
- Chọn ra mô hình bạn đề xuất: per-seat thuần, per-usage thuần, hay hybrid (nêu rõ phần base và phần variable).
- Mô phỏng hóa đơn cho 3 chân dung khách: một khách nhỏ, một khách vừa, một khách lớn. Tính ra con số cụ thể cho từng người.
- Trả lời bằng 3-4 câu: mô hình bạn chọn nghiêng về predictability hay pricing power? Khách lớn có trả tương xứng giá trị không? Bạn cần xây công cụ minh bạch nào để mô hình này không gây sốc hóa đơn?
Tóm tắt
- Quyết định đơn vị tính tiền (pricing unit) quan trọng và khó đảo ngược hơn nhiều so với quyết định mức giá.
- Ba đơn vị nền tảng: per-seat (theo người dùng — dễ hiểu, dự báo tốt), per-usage (theo lượng dùng — bám giá trị, pricing power cao), value unit (theo đơn vị giá trị kinh doanh — lý tưởng nhưng khó đo).
- Sự đánh đổi trung tâm là pricing power đấu với predictability. Seat nghiêng về predictability; usage/value nghiêng về pricing power.
- Vì không mô hình đơn lẻ nào hoàn hảo, hybrid (base cố định + variable theo usage/value) là lựa chọn thực dụng nhất cho phần lớn công ty trưởng thành.
- Slack cho thấy sức mạnh của per-seat; Snowflake cho thấy pricing power của usage; ví dụ GiaoNhanh cho thấy khi seat không bám giá trị, hãy đi tìm đơn vị giá trị thật.
- Quy tắc thực hành: chấm điểm các đơn vị theo value alignment / measurability / predictability, mô phỏng hóa đơn cho nhiều chân dung khách, và luôn đầu tư vào công cụ minh bạch nếu chọn usage/value.