Mở đầu — vì sao bài này quan trọng
Nếu bạn nhìn vào mười công ty SaaS B2B nổi tiếng nhất thế giới, có lẽ tám trong số đó tính tiền theo số người dùng — gọi là per-seat pricing (định giá theo "ghế", mỗi ghế tương ứng một người dùng có tài khoản). Slack, Notion, Figma, Zoom, Microsoft 365, Google Workspace, Atlassian — tất cả đều dùng mô hình này như xương sống doanh thu. Lý do không phải vì họ thiếu sáng tạo, mà vì per-seat là mô hình dễ hiểu nhất, dễ dự báo nhất, và dễ bán nhất khi sản phẩm của bạn tạo ra giá trị theo từng con người sử dụng.
Nhưng đây cũng là mô hình bị hiểu lầm nhiều nhất. Rất nhiều PM Việt Nam khi xây sản phẩm B2B đầu tiên mặc định chọn per-seat vì "ai cũng làm vậy", rồi sau đó phát hiện khách hàng tìm đủ cách dùng chung tài khoản, hoặc tăng trưởng doanh thu bị nghẽn vì công ty khách không thể thêm người. Bài này sẽ mổ xẻ per-seat pricing thật sâu: khi nào nó là lựa chọn đúng, cơ chế bên trong nó vận hành ra sao, những "cái bẫy" kinh điển, và cách thiết kế một mô hình per-seat khỏe mạnh. Đây là một trong những quyết định pricing có sức nặng nhất bạn sẽ ra với tư cách PM, vì nó định hình cách doanh thu của bạn lớn lên theo thời gian.
Khái niệm cốt lõi
Per-seat pricing là gì
Per-seat pricing nghĩa là khách hàng trả tiền theo số lượng người dùng (user) được cấp quyền truy cập sản phẩm. Công thức cơ bản: Doanh thu = Số seat × Giá mỗi seat. Nếu Slack tính 8 USD/người/tháng và một công ty có 50 nhân viên dùng, hóa đơn là 400 USD/tháng. Đơn giản đến mức kế toán bên khách cũng hiểu ngay — và đó chính là một trong những sức mạnh lớn nhất của mô hình.
"Seat" ở đây thường được định nghĩa là một tài khoản đăng nhập riêng (active user). Có hai biến thể nhỏ cần phân biệt:
- Active seat: chỉ tính những người thực sự đăng nhập/sử dụng trong kỳ. Mô hình này "công bằng" hơn với khách nhưng khó dự báo doanh thu.
- Provisioned seat (assigned seat): tính theo số tài khoản được cấp, dù người đó có dùng hay không. Phổ biến hơn trong B2B vì doanh thu ổn định và dễ quản lý hợp đồng.
Ba điều kiện để per-seat thực sự phù hợp
Per-seat không phải mô hình vạn năng. Nó tỏa sáng khi hội đủ ba điều kiện sau:
1. Giá trị tăng theo số người dùng (value scales with users). Đây là điều kiện quan trọng nhất. Với Slack hay Notion, mỗi người được thêm vào không gian làm việc thì giá trị tổng thể tăng lên — thêm người cộng tác, thêm tin nhắn, thêm tài liệu chia sẻ. Khách hàng cảm thấy "trả thêm tiền cho thêm người" là hợp lý vì họ nhận lại nhiều hơn. Ngược lại, nếu một công cụ phân tích dữ liệu mà chỉ một người trong phòng dùng để chạy báo cáo cho cả công ty, thì giá trị không gắn với số người — per-seat sẽ gây ức chế.
2. Sản phẩm B2B có ranh giới đội nhóm rõ ràng (clear team boundary). Per-seat hoạt động tốt khi bạn biết "ai thuộc về tổ chức này". Với phần mềm doanh nghiệp, ranh giới này rõ: nhân viên công ty A dùng tài khoản công ty A. Với sản phẩm tiêu dùng (B2C) nơi người dùng đến và đi tự do, khái niệm seat trở nên mờ nhạt.
3. Dễ đếm và dễ kiểm chứng (easy to count). Bộ phận nhân sự (HR) của khách luôn biết công ty mình có bao nhiêu người. Khi đại diện bán hàng của bạn hỏi "công ty anh có bao nhiêu nhân viên cần dùng?", khách trả lời được ngay. Khả năng đếm được này khiến quá trình báo giá, đàm phán và gia hạn cực kỳ mượt — không cần đo lường phức tạp như usage-based.
Vì sao per-seat dễ dự báo doanh thu
Đây là lý do CFO và nhà đầu tư yêu thích per-seat. Vì doanh thu = seat × giá, và số seat thay đổi chậm (công ty không tuyển/sa thải hàng loạt mỗi ngày), nên MRR (doanh thu định kỳ hàng tháng) rất ổn định và dễ mô hình hóa. Bạn có thể dự báo "nếu giữ được khách và họ tăng 10% nhân sự mỗi năm, doanh thu sẽ tăng tương ứng". Tính dự báo cao này làm cho định giá doanh nghiệp (valuation) đẹp hơn.
Cơ chế "expansion revenue" tự nhiên
Một đặc tính đẹp của per-seat là doanh thu mở rộng (expansion revenue) gần như tự động. Khi khách hàng phát triển — tuyển thêm người — họ phải mua thêm seat. Bạn không cần làm gì, doanh thu cũng tăng theo đà tăng trưởng của khách. Đây là cơ chế tạo nên net revenue retention (NRR) > 100% mơ ước của mọi công ty SaaS: ngay cả khi không có khách mới, doanh thu từ tập khách cũ vẫn lớn lên.
Tình huống thực tế
Ví dụ 1: Slack — per-seat đúng sách giáo khoa
Slack là minh họa kinh điển cho per-seat làm đúng. Gói Pro của Slack có giá khoảng 8,75 USD/người/tháng. Giá trị của Slack đến từ mạng lưới giao tiếp: một mình bạn dùng Slack thì vô nghĩa, nhưng cả công ty 200 người dùng thì nó thay thế email nội bộ. Mỗi người thêm vào làm mạng lưới giá trị dày lên — đúng điều kiện "value scales with users".
Điều thú vị là Slack còn thêm một cơ chế công bằng gọi là fair billing: nếu trong kỳ thanh toán có người không hoạt động, Slack tự động hoàn tín dụng (credit) cho phần seat không dùng. Điều này xóa bỏ nỗi lo lớn nhất của khách per-seat — "tôi trả tiền cho những tài khoản ma". Bài học: per-seat mạnh nhất khi bạn loại bỏ được cảm giác lãng phí của khách, và Slack biến điểm yếu của mô hình thành điểm bán hàng.
Ví dụ 2: Base.vn — per-seat trong bối cảnh doanh nghiệp Việt
Base.vn, nền tảng quản trị doanh nghiệp phổ biến tại Việt Nam, dùng per-seat làm trục định giá cho phần lớn ứng dụng của mình (Base Work+, Base HRM+...). Mức giá thường rơi vào khoảng vài chục nghìn đến trên trăm nghìn đồng mỗi nhân viên mỗi tháng tùy gói và ứng dụng. Bối cảnh này rất hợp với per-seat: khách hàng là doanh nghiệp có ranh giới đội nhóm rõ ràng, HR biết chính xác số nhân sự, và giá trị (quản lý công việc, chấm công, quy trình) gắn trực tiếp với từng nhân viên được đưa vào hệ thống.
Tuy nhiên, Base cũng cho thấy thách thức rất Việt Nam: nhiều doanh nghiệp vừa và nhỏ (SME) muốn "mua cho 50 người nhưng thực tế chỉ 30 người dùng thường xuyên". Đội bán hàng phải khéo léo đóng gói theo bậc số lượng (ví dụ gói cho doanh nghiệp dưới 50 người, dưới 200 người) và thường chốt theo số nhân sự thực tế chứ không theo lý thuyết. Bài học: ở thị trường VN, per-seat cần đi kèm chiến lược đóng gói theo quy mô và đàm phán linh hoạt, vì khách rất nhạy cảm với việc "trả cho ghế trống".
Ví dụ 3: Một startup giả định bán per-seat sai — và cách họ sửa
Giả sử một startup VN tên "FlowDesk" làm phần mềm help-desk (xử lý yêu cầu khách hàng) cho các shop thương mại điện tử. Ban đầu họ tính 200.000đ/agent/tháng. Vấn đề phát sinh: các shop nhỏ chỉ có 2-3 nhân viên chăm sóc khách hàng, nhưng số lượng ticket (yêu cầu) khổng lồ vào mùa sale. Họ "lách" bằng cách cho 3 người dùng chung 1 tài khoản, đăng nhập xoay vòng. Doanh thu FlowDesk nghẽn, vì giá trị thật (số ticket xử lý) tăng vọt mà số seat thì không.
FlowDesk nhận ra sai lầm: với họ, giá trị không scale theo số người mà scale theo khối lượng công việc. Họ chuyển sang mô hình hybrid — một mức phí nền theo seat (giữ tính dễ hiểu) cộng phần phụ thu theo số ticket vượt hạn mức. Sau khi đổi, ARPA (doanh thu trung bình mỗi tài khoản) tăng gần 40% vì những shop bận rộn nhất giờ trả đúng với giá trị họ nhận. Bài học: trước khi chọn per-seat, hãy thành thật trả lời "giá trị của tôi có thực sự tăng theo số NGƯỜI không?". Nếu câu trả lời là không, per-seat sẽ vừa mất doanh thu vừa khuyến khích khách gian lận tài khoản.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để thiết kế (hoặc đánh giá lại) một mô hình per-seat.
Bước 1 — Kiểm tra điều kiện phù hợp. Trả lời ba câu hỏi: (a) Giá trị sản phẩm có tăng khi thêm người dùng không? (b) Khách hàng có ranh giới tổ chức rõ ràng không? (c) Số người dùng có dễ đếm và khó gian lận không? Nếu cả ba đều "có", per-seat là ứng viên mạnh. Nếu giá trị gắn với khối lượng (dữ liệu, giao dịch, dung lượng), hãy cân nhắc usage-based hoặc hybrid (chủ đề các bài sau).
Bước 2 — Định nghĩa "seat" thật rõ. Quyết định seat là active user hay provisioned user. Định nghĩa rõ ai cần seat: người chỉ xem (viewer) có cần trả tiền không? Nhiều sản phẩm cho viewer miễn phí và chỉ tính tiền editor/admin — đây là đòn bẩy quan trọng để giảm rào cản lan rộng trong tổ chức.
Bước 3 — Định giá mỗi seat dựa trên giá trị, không phải chi phí. Ước lượng giá trị mỗi người dùng nhận được (tiết kiệm thời gian, tăng doanh số, giảm lỗi) rồi định giá ở một phần nhỏ của giá trị đó. Đối chiếu với đối thủ để định vị, nhưng đừng để chi phí hạ tầng quyết định giá — vì chi phí phục vụ thêm một seat thường rất thấp.
Bước 4 — Thiết kế cơ chế chống "đau" cho khách. Quyết định cách xử lý seat không dùng: hoàn tín dụng kiểu Slack, hay cho phép giảm seat khi gia hạn. Càng giảm cảm giác "trả cho ghế trống", tỷ lệ giữ chân càng cao.
Bước 5 — Gắn per-seat vào cơ chế mở rộng. Làm cho việc thêm seat thật dễ — tự phục vụ (self-serve), không cần gọi sales. Mỗi rào cản khi thêm người là một lần bạn mất expansion revenue. Theo dõi chỉ số seats per account theo thời gian để biết tài khoản có đang lan rộng không.
Bước 6 — Theo dõi và phòng chống lạm dụng tài khoản dùng chung. Giám sát dấu hiệu dùng chung (một tài khoản đăng nhập từ nhiều địa điểm/thiết bị cùng lúc). Đừng vội khóa — hãy xem đó là tín hiệu nhu cầu để tiếp cận bán thêm seat một cách lịch sự.
Lỗi thường gặp & mẹo
Lỗi 1: Chọn per-seat khi giá trị không gắn với người dùng. Đây là sai lầm chí mạng đã thấy ở ví dụ FlowDesk. Nếu sản phẩm tạo giá trị theo khối lượng (số tin nhắn gửi đi, dung lượng lưu trữ, số giao dịch), per-seat sẽ khiến khách dùng chung tài khoản và doanh thu của bạn không theo kịp giá trị tạo ra.
Lỗi 2: Tính tiền mọi loại người dùng như nhau. Nếu admin, editor và viewer đều phải trả cùng giá, tổ chức khách sẽ ngại mời người vào — đúng thứ giết chết khả năng lan rộng. Mẹo: phân tầng seat. Cho người chỉ xem dùng miễn phí hoặc giá rẻ để sản phẩm lan khắp công ty, rồi kiếm tiền từ những người tạo nội dung.
Lỗi 3: Khiến việc thêm seat khó khăn. Nếu admin phải gửi email cho sales mỗi khi muốn thêm một người, bạn vừa tự bóp nghẹt expansion revenue. Mẹo: cho phép admin tự thêm seat trong vài cú click, thanh toán theo tỷ lệ (prorated) phần còn lại của kỳ.
Lỗi 4: Phạt khách khi họ phát triển quá nhanh, không có chiết khấu số lượng. Một công ty 1.000 người trả cùng đơn giá như công ty 10 người sẽ thấy hóa đơn "cắt cổ". Mẹo: thiết kế chiết khấu theo bậc số lượng (volume discount) — chủ đề sẽ được đào sâu ở bài riêng — để giữ khách lớn.
Lỗi 5: Bỏ qua hiện tượng "seat hoarding ngược". Ở thị trường VN, khách thường mua thiếu seat rồi dùng chung để tiết kiệm. Mẹo: vừa giám sát dùng chung, vừa làm cho việc thêm seat rẻ và mượt đến mức khách thấy mua đúng số người dễ hơn là gian lận.
Mẹo vàng: Per-seat đẹp nhất khi kết hợp với một động lực tự nhiên để mời thêm người — như khi bạn share một tài liệu Notion, người nhận buộc phải có tài khoản. Hãy thiết kế sản phẩm sao cho việc dùng nhiều hơn tự nhiên kéo theo nhiều người hơn, và nhiều người hơn tự nhiên kéo theo nhiều seat hơn.
Bài tập thực hành
- Chẩn đoán mô hình. Chọn một sản phẩm SaaS bạn đang dùng hoặc đang xây. Trả lời ba câu hỏi kiểm tra điều kiện ở Bước 1. Kết luận: per-seat có phù hợp không? Vì sao? Viết 3-5 câu lý giải.
- Phân tầng seat. Với sản phẩm đó, liệt kê các vai trò người dùng (admin/editor/viewer/guest...). Đề xuất vai trò nào nên trả phí đầy đủ, vai trò nào miễn phí hoặc giá rẻ, và giải thích cách phân tầng này thúc đẩy sản phẩm lan rộng trong tổ chức.
- Tính expansion revenue. Giả sử bạn có 100 khách, trung bình 20 seat/khách, giá 150.000đ/seat/tháng. Tính MRR hiện tại. Nếu mỗi khách tăng trung bình 10% số seat trong năm tới (và không mất khách nào), MRR mới là bao nhiêu? Con số này minh họa sức mạnh expansion của per-seat ra sao?
- Thiết kế cơ chế chống đau. Đề xuất một chính sách xử lý seat không hoạt động cho sản phẩm của bạn (kiểu fair billing của Slack, hay cho giảm seat khi gia hạn). Viết ngắn gọn cách bạn sẽ truyền thông chính sách này trên trang giá để biến nó thành điểm bán hàng.
Tóm tắt
Per-seat pricing là mô hình tính tiền theo số người dùng, với công thức đơn giản: doanh thu = số seat × giá mỗi seat. Nó tỏa sáng khi hội đủ ba điều kiện: giá trị tăng theo số người dùng (như Slack, Notion), sản phẩm B2B có ranh giới đội nhóm rõ ràng, và số người dễ đếm — HR luôn biết công ty có bao nhiêu nhân viên. Sức mạnh lớn nhất của per-seat là tính dễ hiểu, dễ dự báo doanh thu, và cơ chế expansion revenue gần như tự động khi khách hàng phát triển.
Nhưng per-seat cũng có những cái bẫy: chọn sai khi giá trị thực ra gắn với khối lượng (dẫn đến dùng chung tài khoản như ví dụ FlowDesk), tính tiền mọi vai trò như nhau (bóp nghẹt lan rộng), hay khiến việc thêm seat khó khăn (mất doanh thu mở rộng). Người PM giỏi không chọn per-seat vì "ai cũng làm vậy", mà vì đã thành thật kiểm tra giá trị sản phẩm có thực sự scale theo con người hay không, rồi thiết kế phân tầng seat, cơ chế chống đau cho khách, và con đường tự phục vụ để mở rộng thật mượt. Làm đúng, per-seat sẽ là cỗ máy doanh thu ổn định và lớn dần cùng khách hàng của bạn.