User-based pricing đã hết thời? AI đang đổi cách SaaS kiếm tiền

1. Mở đầu: khách mời James D. Wilton và con đường vào nghề pricing

Đây là tập 161 của SaaS Backwards, podcast do Ken Lempit dẫn. Ken giới thiệu chương trình là nơi đi sâu vào những chiến lược và câu chuyện phía sau các công ty SaaS thành công. Hôm nay chương trình quay lại một chủ đề mà Ken gọi là một trong những chủ đề anh thích: vai trò then chốt của pricing trong việc thúc đẩy tăng trưởng và lợi nhuận của SaaS (video đăng ngày 11/04/2025).

Khách mời là James D. Wilton. Theo phần mô tả của video đăng ngày 11/04/2025, anh từng dẫn dắt mảng pricing ở McKinsey và là người sáng lập Monevate. Khi giới thiệu, Ken nói James có hơn 12 năm kinh nghiệm giúp các startup và công ty tăng trưởng nhanh tối đa hoá giá trị bằng pricing có chiến lược, và rằng ở McKinsey anh từng dẫn dắt mảng pricing cho các startup và scale-up công nghệ.

Ken chào James, James cảm ơn Ken đã mời và nói rất vui được có mặt. Ken nói lại rằng đây thật sự là một trong những chủ đề anh thích, và trước khi vào các câu hỏi đã chuẩn bị, anh mời James kể thêm một chút về bản thân và về Monevate.

James kể (video đăng ngày 11/04/2025) gần như cả sự nghiệp của anh là làm tư vấn, tính ra khoảng 20 năm. Anh khởi đầu với tư vấn sales, marketing và chiến lược. Anh đến với pricing strategy phần lớn là do tình cờ: có cơ hội gia nhập một team tư vấn nội bộ chuyên về mảng này, và anh "đánh liều" nhận lời, lúc đó chủ yếu vì lý do lối sống.

Nhưng rồi, theo lời anh, nó giống như một bóng đèn bật sáng: anh nhận ra mình mê pricing. Nó mang tính chiến lược hơn anh tưởng nhiều, và có nhiều chỗ cho sự sáng tạo hơn anh tưởng. Thế là anh bị cuốn vào, và quyết định dành phần còn lại của sự nghiệp tư vấn để tập trung vào pricing. Anh xây được một chuyên môn sâu về pricing cho SaaS, cho công nghệ và cho các sản phẩm đổi mới khác. Như Ken đã nhắc, anh gia nhập McKinsey vào khoảng năm 2018 (theo video đăng ngày 11/04/2025), được mời về để dẫn dắt mảng pricing cho bộ phận của McKinsey tập trung vào startup, scale-up và các công ty công nghệ tăng trưởng nhanh khác.

2. Từ McKinsey ra riêng, Saratoga Springs và câu hỏi về AI

Năm 2021, James quyết định ra làm riêng. Anh rất thích công việc ở McKinsey, nhưng thấy khá khó để phục vụ kiểu công ty mà anh muốn làm cùng: McKinsey mang lại rất nhiều giá trị, nhưng mức phí cũng tương xứng với điều đó. Vì vậy anh muốn tạo ra một công ty giữ được mức giá trị và chuyên môn pricing ấy nhưng làm việc được với nhiều công ty đang tăng trưởng hơn. Đó là tầm nhìn của Monevate năm 2021, và theo anh (video đăng ngày 11/04/2025), công ty đang phát triển tốt và đã lớn lên khá nhiều kể từ đó.

Về chuyện riêng, theo video đăng ngày 11/04/2025, James sống ở Saratoga Springs cùng vợ và ba cậu con trai 13, 11 và 3 tuổi. Ken nói, như James đã biết, anh rất thích Saratoga: một thị trấn nhỏ tuyệt vời, có rất nhiều thứ diễn ra so với một thành phố nhỏ ở vùng ven. Một nơi rất đẹp, và nếu thính giả chưa từng tới thì nên tới đó và tận hưởng mọi thứ Saratoga Springs có.

James hưởng ứng: tận hưởng các con suối, tận hưởng trường đua ngựa, và nói đó là màn quảng cáo miễn phí của anh cho Saratoga. Ken thêm Caffè Lena, rồi nói ở đó có quá nhiều nhà hàng ngon, một nơi thật sự vui (video đăng ngày 11/04/2025).

Rồi Ken vào chuyện chính (video đăng ngày 11/04/2025). Trước buổi ghi hình, James có nói AI đang thật sự thay đổi bức tranh pricing của SaaS. Ken muốn James nói rõ các tính năng AI đang tác động thế nào tới cách các công ty vẫn nghĩ về các mô hình pricing truyền thống, và theo anh những thách thức nào đang tới khi định giá và ra mắt các sản phẩm có thêm AI, vì với Ken đó có vẻ là một thế giới hoàn toàn mới mà các doanh nhân phần mềm phải tính tới.

James đồng ý. Anh nói thật lòng thì "cái chuyện AI này" đã làm cả giới SaaS chao đảo một phen. Điều thú vị là, theo anh (video đăng ngày 11/04/2025), monetize AI ít nhất trên lý thuyết hoàn toàn giống monetize bất cứ thứ gì khác, chuyện mà hai người có thể bàn sau nếu hợp. Nhưng nó vẫn làm mọi người chao đảo vì nó khác: công nghệ khác. Mọi người đã quá quen với SaaS trong 10, 20 năm qua, nên rất dễ phản xạ theo cách nghĩ quen thuộc về SaaS và các mô hình vẫn dùng để monetize nó. Có vài điểm khá khác ở các tính năng AI khiến người ta bị lệch nhịp một chút.

3. Ba điểm khiến AI làm giới SaaS lúng túng khi định giá

Điểm thứ nhất, theo James (video đăng ngày 11/04/2025), là về căn bản cách AI tạo ra giá trị khác với cách sản phẩm SaaS truyền thống tạo ra giá trị. Nói đơn giản: công cụ SaaS bạn mua thường là thứ bạn dùng để giúp bạn làm một việc gì đó. Còn các công cụ và tính năng AI thường ở một mức nào đó làm việc đó thay bạn. Vì vậy cách nghĩ về giá trị ở đây khác, và cách giá trị scale cũng khác, nên những mô hình pricing mà người ta mặc định dùng cũng phải khác một chút.

Điểm thứ hai là chi phí. Một trong những lý do khiến các doanh nghiệp SaaS hấp dẫn đến vậy trong mấy năm qua là margin thường rất, rất cao. Nhưng ít nhất vào lúc này (theo video đăng ngày 11/04/2025), AI dùng một lượng compute khổng lồ, và compute đó đang rất đắt. Vì vậy về mặt kỹ thuật margin thấp hơn nhiều, ít nhất là khi bạn không monetize theo usage một cách cụ thể, hoặc không kiểm soát hay monetize trên cùng metric mà bạn phát sinh chi phí. James cho rằng các chi phí này đẩy mức giá lên, và khiến người ta thận trọng hơn khi đặt giá.

Điểm thứ ba là một vướng mắc chồng lên điểm thứ hai. Ai làm SaaS pricing cũng biết rằng nên đặt pricing strategy sao cho mức giá gắn với giá trị khách hàng nhận được, và thường bạn chọn một metric nào đó để làm việc này. Vấn đề với AI, theo James (video đăng ngày 11/04/2025), là metric gắn với giá trị không phải lúc nào cũng trùng với metric gắn với chi phí. Nếu bạn định giá theo cách che phủ chi phí thật tốt, bạn chưa chắc đang định giá theo cách scale theo giá trị, và điều đó tạo ra ma sát trong quá trình mua. Ngược lại, nếu bạn chọn một thứ gắn với giá trị để đặt giá, có thể bạn đã chọn một thứ không che phủ được chi phí, và rồi gặp vấn đề về lợi nhuận.

Những phức tạp như vậy, theo James, khiến người ta không thể ra quyết định pricing nhanh được, và làm người ta vừa lo vừa háo hức về việc những pricing strategy nào nhiều khả năng sẽ nổi lên (video đăng ngày 11/04/2025).

4. Các công ty AI native có nghĩ tới chi phí không

Ken thấy chuyện giá trị và chi phí rất thú vị. Anh nói khi trò chuyện với các doanh nhân AI, những công ty AI native còn non trẻ, anh không nghe họ nói nhiều về chi phí. Anh tự hỏi có phải có những nhà cung cấp đang che chắn cho họ khỏi chi phí thật hay không, và vì sao lại thế, vì anh chưa nghe ai nói tới chuyện này (video đăng ngày 11/04/2025).

James nói anh chỉ có vài phản hồi mang tính giai thoại từ việc nói chuyện với một vài người, nên không thể nói thành quy luật chung. Theo những gì anh nghe (video đăng ngày 11/04/2025), có một nhóm công ty rất lo về chi phí và muốn chắc chắn tuyệt đối là mình che phủ được, vì không muốn margin chạy lung tung. Và có những công ty khác nhìn xa hơn, đúng hay sai thì chưa biết, và nói: tôi tin chi phí rồi sẽ giảm. James cho rằng điều đó có lẽ đúng, chỉ là chưa biết sẽ nhanh tới mức nào. Với những model như DeepSeek xuất hiện, ít ra cũng đã có phần nào tiền lệ cho việc chi phí đi xuống.

Lập luận của nhóm thứ hai, theo cách James kể lại: vì tin chi phí sẽ giảm nên tạm thời không bận tâm chuyện đó, chấp nhận chịu thiệt về lợi nhuận lúc này, xây dựng sự ưa chuộng (preference), rồi đặt cược rằng khi chi phí giảm dần thì mình sẽ ở vị thế tốt và có lãi ở trạng thái cuối cùng (video đăng ngày 11/04/2025).

Ken nói điều này đặc biệt đúng với những công ty đang hình dung lại doanh nghiệp của mình, chuyển từ SaaS truyền thống sang AI native. Anh không nghĩ kiểu copilot tốn compute bằng một môi trường AI native. Nhưng nếu bạn định hình dung lại hoàn toàn doanh nghiệp quanh một năng lực AI native, ở bất kỳ mảng ứng dụng nào, thì một điều bạn phải thật sự hiểu là chi phí của mình sẽ là bao nhiêu, vì pricing cũ có thể không còn chạy được nữa (theo Ken, video đăng ngày 11/04/2025).

James đồng ý đó là một trong những hệ quả, và nói Ken hoàn toàn đúng khi cho rằng có những loại tốn compute hơn loại khác. Nhưng theo anh, ngay cả những loại nhẹ hơn, nếu đem so với các mô hình SaaS cũ, cũng vẫn khác một trời một vực (video đăng ngày 11/04/2025).

5. Giá trị đến ở cuối, chi phí phát sinh ở từng lượt hỏi

James lấy ví dụ cách người ta tương tác với một copilot, với ChatGPT hay một trong những trợ lý AI như vậy, thứ mà theo anh rất nhiều người đã dùng và dùng thường xuyên (video đăng ngày 11/04/2025). Khi anh làm một việc với ChatGPT, anh bắt đầu "nói chuyện" với nó và nhờ nó làm việc. Nhưng hiển nhiên là bạn không có ngay thứ mình muốn ở lần đầu. Bạn nhờ một thứ, hỏi một câu, nó trả lời, rồi bạn tinh chỉnh, lặp lại, nắn nó dần thành một thứ cuối cùng mang lại giá trị cho bạn.

Với anh là người dùng, giá trị đến ở cuối quá trình đó, khi anh đã tạo ra hoặc lấy được thứ mình muốn. Nhưng GPT phát sinh chi phí mỗi lần anh hỏi nó một câu. Tất cả các bước ở giữa đều đang đẩy chi phí ở back end lên. Nếu nghĩ về đơn vị mà anh nhận được giá trị, thì đó là câu hỏi: cuối cùng tôi có được sản phẩm của mình không? Đó là một đơn vị ở cuối, trong khi chi phí cho nó có thể là 10, 20, 300, khá khó mà kiểm (theo James, video đăng ngày 11/04/2025).

Ken chen vào: hộp thoại còn khuyến khích bạn thử lại, kiểu "đây có phải thứ bạn muốn không? Nếu không thì mình làm lại nhé". Vậy là, theo Ken, gần như chúng đang tự làm hại mình bằng chính sự khuyến khích đó (video đăng ngày 11/04/2025).

James đáp: "Yep, exactly", nó cứ thế tiếp diễn. Theo anh, ở các mô hình SaaS cũ không có độ lệch lớn như vậy: bạn không nghĩ chi phí sẽ tăng vọt mỗi lần mình làm một thao tác. Nhưng ở đây thì đúng là vậy. Các mô hình kiểu Copilot và ChatGPT vào lúc này, theo James (video đăng ngày 11/04/2025), về cơ bản đều tính tiền theo user. Có thể có một ngưỡng usage nào đó, nhưng chúng không thật sự nói nhiều về usage. Chúng đang đặt cược vào việc người ta sẽ dùng nhiều tới mức nào, và có user sẽ cực kỳ có lãi, có user thì không có lãi chút nào.

Ken nói thêm: với SaaS truyền thống, người ta đã quen với việc compute và storage gần như miễn phí. Có tiếng đáp "Exactly". Ken nói bạn sẽ đối mặt với một bài toán rất khác ở phía chi phí (video đăng ngày 11/04/2025).

6. Vì sao ngay cả SaaS truyền thống cũng rời user-based pricing

Ken muốn chuyển hướng cuộc nói chuyện một chút, dù hiển nhiên mọi thứ vẫn xoay quanh pricing, và có lẽ hai người đã tự nhiên đi tới đây. Anh nói pricing truyền thống, hay phổ biến nhất, của SaaS là theo user: bạn có bao nhiêu seat, bao nhiêu site, bao nhiêu data set. Thường đó là một thứ định lượng, nhưng là đếm. Còn giờ có rất nhiều chuyện đang diễn ra trong SaaS, có AI và không có AI, theo hướng usage-based (theo Ken, video đăng ngày 11/04/2025). Anh nghĩ có lẽ việc chuyển sang usage-based có thể giúp quá trình chuyển sang ứng dụng AI native. Nhưng câu hỏi của anh là: điều gì đang thúc đẩy thay đổi này, kể cả ở các công ty SaaS truyền thống hơn, khi đi theo usage-based pricing, kiểu khái niệm đo lường (metering)?

James nói rất thú vị khi theo dõi chuyện này trong khoảng 10 năm qua: đã có một sự dịch chuyển dần dần về phía usage-based pricing, nhưng cũng có vài lần đổi chiều qua lại khi người ta phản ứng với nó. Theo anh (video đăng ngày 11/04/2025), cuối cùng đã đến lúc có thể nói rằng nếu ai đó có một sản phẩm mới và nói "tôi muốn tính giá theo user", thì ở thời điểm này người đó phải thật sự bảo vệ được lựa chọn ấy, vì cảm giác là có lẽ đó không phải câu trả lời đúng vào lúc này.

Điều đó không có nghĩa là chắc chắn sai. Chắc chắn có những sản phẩm mà per-user pricing là câu trả lời đúng. Nhưng nếu trước đây có thể nói per-user pricing có lẽ hợp với một phần lớn các công ty, thì giờ số công ty mà per-user là câu trả lời đúng đã ít hơn rất nhiều (theo James, video đăng ngày 11/04/2025).

7. Ba tiêu chí chọn price metric

Để giải thích lý do, James xin phép đi qua vài nguyên tắc pricing. Khi quay lại câu hỏi chọn một price metric tốt, có vài tiêu chí mà anh và đồng nghiệp ở Monevate cân nhắc. Theo anh (video đăng ngày 11/04/2025), những tiêu chí có lẽ đáng chú ý nhất ở đây là:

• Value alignment (gắn với giá trị): chọn một metric sao cho khi số đơn vị của metric tăng lên, khách hàng nhận được ngày càng nhiều giá trị từ sản phẩm (theo James, video đăng ngày 11/04/2025).
• Growth oriented (hướng tới tăng trưởng): một metric mà số đơn vị tự nhiên tăng theo thời gian. Theo James (video đăng ngày 11/04/2025), đây đơn giản là chuyện land and expand: mình muốn doanh thu từ khách hàng tăng dần theo thời gian, chứ không đứng yên hay, lạy trời đừng xảy ra, đi xuống.
• Acceptable (được chấp nhận): một thứ có vẻ công bằng và hợp lý để làm căn cứ đặt giá, và predictability (tính dự đoán được) là một phần lớn của nó: tôi có dự đoán được số đơn vị của mình theo thời gian không (theo James, video đăng ngày 11/04/2025)?

Với các tiêu chí đó trong đầu, James lập luận rằng với nhiều công ty, user-based pricing chưa bao giờ thật sự gắn với giá trị. Nó chưa bao giờ là metric gắn với giá trị nhiều nhất, vì không phải lúc nào thêm user cũng mang lại nhiều giá trị hơn đáng kể. Có thể các công ty lớn hơn, có willingness to pay cao hơn, cần nhiều user hơn và vì vậy sẵn sàng trả cho nhiều user hơn. Nhưng thường thì không phải cứ thêm một user là bạn thêm cả đống giá trị. Đôi khi có, nhưng thường là không (theo James, video đăng ngày 11/04/2025).

Cái mà user-based pricing có được, theo anh, là nó thường hướng tới tăng trưởng: công ty lớn lên thì thường cần thêm user, nên số user đi lên. Và nó rất dễ được chấp nhận vì nó có ở khắp nơi. Ai cũng biết sản phẩm SaaS thường được định giá như vậy, và đặt giá theo user có vẻ dễ và hợp lý (video đăng ngày 11/04/2025).

8. Cán cân đã nghiêng: user-based mất điểm, usage-based được chấp nhận

Rồi nhìn vào vài năm gần đây. James nói giờ là thời của tự động hoá nhiều hơn rất nhiều, nên một số ít user có thể làm được nhiều việc hơn so với trước đây nhờ các automation đó. Vì vậy user càng ít gắn với giá trị hơn nữa: không cần thêm ngày càng nhiều user để mở ra cùng một lượng giá trị, vì "tôi làm được nhiều hơn với ít hơn" (theo James, video đăng ngày 11/04/2025).

Cùng lúc đó, ở ít nhất một số ngành, AI đang đi vào và thay đổi mọi thứ, cho phép người ta giảm headcount của cả công ty hay của các team. Nên đôi khi, theo đúng nghĩa đen, số người có thể là user đang giảm. Vậy là user cũng không còn hướng tới tăng trưởng như trước: thường có những lúc người ta sẽ không thêm user, và có lúc còn phải giảm. Tính gắn với giá trị và tính hướng tới tăng trưởng của user-based pricing, so với usage-based, vì thế bị tổn hại thật sự (theo James, video đăng ngày 11/04/2025).

Đồng thời, rào cản lớn với usage-based pricing xưa nay là tính dự đoán được và tính được chấp nhận. Người ta e ngại usage-based pricing: bạn không biết mình sẽ dùng bao nhiêu nên sợ cái giá có thể phải trả nếu chỉ tính theo usage. Nhưng theo James (video đăng ngày 11/04/2025), đã có những mô hình pricing xuất hiện như nhiều dạng hybrid, các hệ thống chia theo dải (banded), và tính tiền theo dung lượng usage (capacity of usage) thay vì chỉ theo usage, nên vấn đề dự đoán được không còn như trước.

Và tất nhiên giờ cũng có nhiều usage-based pricing hơn, nên người ta quen với nó hơn và nó trở nên dễ chấp nhận hơn. Với James, khi nhìn qua các yếu tố này, cán cân đã thật sự nghiêng hẳn trong vài năm qua: mọi lý do khiến người ta có thể còn bám lấy user-based pricing giờ đã nghiêng về phía bên kia (video đăng ngày 11/04/2025).

Theo anh, điều đó có nghĩa là lúc này bạn chỉ thật sự nên tính giá theo user khi giá trị của bạn thật sự scale rất tốt theo số user, chẳng hạn những doanh nghiệp như Zoom và Slack, nơi có rất nhiều cộng tác giữa người với người. Đó là kiểu ví dụ mà anh nghĩ việc tính theo user thật sự hợp lý. Có rất nhiều trường hợp khác nơi nó không còn hợp nữa (theo James, video đăng ngày 11/04/2025).

9. Giải thích cho khách hàng: ví dụ phần mềm kế toán và chiếc seat thứ hai

Ken hỏi: vậy làm sao truyền đạt cách định giá thay thế đó cho mọi người? Anh nói gần như bạn phải giáo dục khách hàng, đúng không (video đăng ngày 11/04/2025)?

James đồng ý là phải giáo dục khách hàng. Theo anh, pricing luôn có một điểm khó: từ phía nhà cung cấp, bạn chọn pricing strategy một phần vì nó sẽ giúp bạn kiếm nhiều tiền hơn về lâu dài, bạn monetize tốt hơn giá trị mình tạo ra, điều mà có lẽ ngược với lợi ích của khách hàng, những người muốn bạn làm nó rẻ nhất có thể. Nhưng không phải lúc nào đó cũng là chuyện chia phần (distributive). Có những lúc định giá theo cách có lợi hơn cho bạn, nhà cung cấp, cũng có lợi hơn cho khách hàng. Ví dụ rõ nhất, theo James (video đăng ngày 11/04/2025), là "bạn muốn ai dùng cũng được, và lý tưởng là chẳng tốn thêm đồng nào".

Anh đưa ví dụ (video đăng ngày 11/04/2025): hình dung bạn là một doanh nghiệp nhỏ có một phần mềm kế toán. Trong phòng tài chính, người sẽ dùng nó gồm một CFO và một finance associate. Nếu trả theo seat, seat thứ nhất sẽ là của CFO. Khi CFO có quyền truy cập, bạn thật sự mở được giá trị của sản phẩm. Thêm một seat nữa cho finance associate thì bạn được thêm bao nhiêu giá trị? Có lẽ không nhiều, vì bạn đã làm được mọi việc cần làm khi CFO dùng được nó. Có thể thêm chút tiện lợi khi người thứ hai cũng vào được, vì có người đó ở trong đó cũng có ích.

Nhưng nếu thật sự bị tính gấp đôi để thêm finance associate so với cho CFO, và đây vốn đã là một thứ giá cao, thì bạn có động cơ thật sự để chịu sự bất tiện và không cho người đó vào (theo James, video đăng ngày 11/04/2025).

Có tiếng nói xen vào: chuyện đó gây bực bội, nó là một lực cản khiến người ta ngại dùng sản phẩm, đúng không? James đáp "Exactly": bạn sẽ chịu thiệt, nhưng chẳng tiện chút nào. Còn trong một thế giới mà bạn chuyển sang một dạng usage-based pricing nào đó, bạn có thể nói: ai bạn muốn cho vào thì cứ cho vào. Mọi ma sát đó được gỡ bỏ, và bạn chỉ tính tiền theo mức cả nhóm dùng sản phẩm (theo James, video đăng ngày 11/04/2025).

Hiển nhiên khi đó lại có những lực cản với việc dùng. Theo James (video đăng ngày 11/04/2025), một phần lớn của việc thiết kế mô hình là làm sao để người dùng không phải đắn đo có nên mở một session, chạy một transaction hay làm bất cứ việc gì đó hay không; chuyện đó quản lý được. Nhưng ý "giờ tôi cho ai vào hệ thống cũng được" thường rất hấp dẫn với khách hàng.

Ken nói điều đó rất hợp lý, và tiếc là không đủ thời gian để đào sâu hơn, vì anh nghĩ đó tự nó đã là một chủ đề rất thú vị.

10. Pricing mới và chuyện công ty SaaS có còn hấp dẫn nhà đầu tư

Ken muốn nói về thay đổi trong pricing, dù đến từ sản phẩm AI native hay SaaS truyền thống: những thay đổi đó đang tác động thế nào tới khả năng thu hút đầu tư (investability) của các công ty SaaS? Anh nói đã có rất nhiều lo lắng về việc tiền từ VC và PE ngày càng khó kiếm, nhưng có vẻ pricing đóng vai trò khiến một công ty dễ hay khó được đầu tư hơn, và hỏi James nhìn chuyện này thế nào (video đăng ngày 11/04/2025).

James nói thật lòng thì mọi người còn đang ở rất sớm trong hành trình này, và cần thêm thời gian mới thấy được nó sẽ diễn ra chính xác ra sao. Nhưng theo anh (video đăng ngày 11/04/2025), giờ có rất nhiều người nói rằng cách nghĩ về ARR, annual recurring revenue (doanh thu định kỳ hằng năm, anh giải thích cho ai chưa quen thuật ngữ), có thể sẽ thay đổi.

Ở các mô hình SaaS truyền thống, ARR là vua. Đó là metric mà ai cũng cố tối ưu, vì nó là một dòng doanh thu đẹp, dự đoán được và thường tăng trưởng. Vì thế nhà đầu tư rất thích nó, và bạn có valuation multiple trên ARR cao hơn nhiều so với trên doanh thu giao dịch (transactional revenue) (theo James, video đăng ngày 11/04/2025).

Điều thú vị với các sản phẩm AI, ít nhất theo cách nhiều sản phẩm đang được định giá lúc này, là bạn thấy nhiều sản phẩm AI native được định giá theo một dạng workload nào đó. Bạn thấy nhiều hệ thống dựa trên credit: user mua credit rồi tiêu chúng để AI chạy các tác vụ như anh vừa kể, mỗi lần nó làm một việc là phát sinh chi phí. Theo James (video đăng ngày 11/04/2025), với các nền tảng AI native này, đó rất nhiều là một nước đi để che phủ chi phí, chưa chắc là một nước đi gắn với giá trị.

Cách đó giữ cho unit economics của các nền tảng ấy chạy được, nhưng lại đẩy bạn vào một dòng doanh thu giao dịch. Vì trừ khi công ty AI thiết kế theo hướng đó, bạn chưa chắc đang cam kết một số lượng token hay một mức usage nhất định mỗi năm; bạn chỉ mua một khối token rồi tiêu tuỳ ý (theo James, video đăng ngày 11/04/2025).

Vì vậy, theo James (video đăng ngày 11/04/2025), giờ nhiều người đang nói tới các kịch bản sau:

• Nhiều công ty loại này bị xem là không hấp dẫn lắm vì có doanh thu giao dịch; James nói kịch bản này tương đối khó xảy ra (theo James, video đăng ngày 11/04/2025).
• Thị trường thôi đòi hỏi doanh thu định kỳ như trước, vì mọi thứ đang đi về phía các mô hình này (theo James, video đăng ngày 11/04/2025).
• Hoặc, như anh nghĩ có thể sẽ là câu trả lời, anh sẽ chẳng ngạc nhiên nếu với AI mọi người đi tới một dạng ARR khác: vẫn là ARR, nhưng là mua dung lượng usage (usage capacity) theo kiểu định kỳ, thay cho các mô hình truyền thống. Anh nhấn mạnh đây chỉ là một giả thuyết (video đăng ngày 11/04/2025).

11. Nhu cầu dự đoán được sẽ không mất đi

James nói anh không nghĩ mong muốn có tính dự đoán được, ở cả phía nhà cung cấp lẫn phía khách hàng, sẽ biến mất. Có lý do khiến mô hình SaaS trở nên thống trị trong mấy năm qua, và về căn bản theo anh là vì khách hàng thích biết mỗi tháng mình trả bao nhiêu (theo James, video đăng ngày 11/04/2025).

Anh kể anh và đồng nghiệp ở Monevate đã làm nghiên cứu với các công ty enterprise, những nơi hiển nhiên có nhu cầu ngân sách khá đặc thù, và thấy rằng trung bình các công ty này sẵn sàng trả thêm 10% đến 15% chỉ để chắc chắn mỗi tháng mình trả bao nhiêu, thay vì để khoản đó dao động lên xuống (theo nghiên cứu James kể, video đăng ngày 11/04/2025).

Từ góc nhìn nhà cung cấp cũng vậy: nhìn chung bạn muốn có kiểu doanh thu đã cam kết đổ về hơn là để nó phụ thuộc vào một thứ bạn không kiểm soát được. James lấy chính mình làm ví dụ: là người cung cấp dịch vụ tư vấn, anh rất muốn có doanh thu định kỳ. Mô hình kinh doanh của anh không vận hành theo cách đó nên không làm được, nhưng nếu mọi thứ khác như nhau, anh thà định giá kiểu đó còn hơn định giá theo từng dự án, nếu có thể (video đăng ngày 11/04/2025).

Vì vậy James cho rằng cả hai mong muốn đó vẫn sẽ còn. Anh đoán khi nhu cầu che phủ chi phí giảm đi, vì chi phí tự nhiên đi xuống, hệ thống sẽ đi tới các mô hình kiểu hybrid usage, nơi bạn vẫn có một dạng ARR nào đó, chỉ là nó trông khác những gì mọi người đã thấy trước đây (theo James, video đăng ngày 11/04/2025).

Ken muốn nhấn mạnh chuyện chi phí dự đoán được ở enterprise. Theo anh, điều đó đang chi phối rất nhiều quyết định, bất kể là nền tảng gì. Ở cấp đó, các công ty có ngân sách. Các hệ thống thường khá lớn, có vòng đời nhiều năm, nếu không muốn nói là hàng chục năm. Họ muốn biết chi phí để "giữ đèn sáng" trong nhà máy của mình, hay bất kể ứng dụng là gì, sẽ là bao nhiêu. Ken nói anh thấy điều đó rất đúng (theo Ken, video đăng ngày 11/04/2025).

12. Đừng đi tắt khi thiết kế pricing strategy: bắt đầu từ mục tiêu

Ken hỏi James về những ý chính và về cách các công ty có thể bảo đảm mình tối đa hoá phần giá trị thu về (value capture). Theo James (video đăng ngày 11/04/2025), nhất là với tất cả những thay đổi đang diễn ra, một nguyên tắc lớn là đừng đi tắt khi thiết kế pricing strategy.

Anh thấy rất nhiều công ty SaaS và công nghệ thiết kế sản phẩm xong, sắp phát hành thì mới nghĩ: "à, phải tìm cách định giá nó đã. Copy cách đối thủ đang làm đi", hoặc cứ nghĩ ra một mức rồi làm. Điều đó biến cả việc định giá thành một việc rất chiến thuật: có thể nó giúp được bạn và chạy được, mà cũng có thể không. Theo James (video đăng ngày 11/04/2025), pricing strategy đúng ra phải là một đòn bẩy chiến lược, giúp bạn tăng trưởng hoặc đạt bất cứ điều gì bạn muốn. Vì vậy nên bắt đầu từ các nguyên lý gốc và thiết kế nó nhằm làm đúng điều bạn muốn.

Thứ nhất trong số những điều anh cho là rất quan trọng: làm rõ bạn muốn đạt được điều gì. Nghe có vẻ hiển nhiên, nhưng theo James (video đăng ngày 11/04/2025), không nhiều công ty làm việc này. Có một khác biệt rất lớn giữa một pricing strategy giúp bạn tối đa hoá sales volume, có thật nhiều khách hàng thật nhanh, và một pricing strategy giúp bạn có margin lợi nhuận rất cao ngay từ đầu. Hai thứ đó trông hoàn toàn khác nhau về mức giá, về cách bạn cấu trúc giá và về mức độ minh bạch. Mọi thứ đều hoàn toàn khác.

Hiển nhiên thường thì người ta không hoàn toàn nhị phân kiểu "tôi muốn đẩy volume" hay "tôi muốn tập trung vào lợi nhuận". Thường là một sự kết hợp, hoặc "tôi tập trung chủ yếu vào một thứ, trong giới hạn về tăng trưởng doanh thu và lợi nhuận". Nhưng chỉ riêng việc lập một danh sách mục tiêu có thứ tự ưu tiên đã giúp, khi bắt đầu xây pricing strategy, bạn cân đo được sự đánh đổi giữa các mục tiêu và tìm ra thứ đạt được sự cân bằng bạn muốn (theo James, video đăng ngày 11/04/2025).

Khi nói tới capturing value, theo James, không nhất thiết là thu hết mọi giá trị, mà là thu một phần giá trị mà bạn thấy là công bằng với điều bạn đang muốn đạt. Nếu bạn đi theo hướng volume, theo định nghĩa bạn sẽ thu ít giá trị hơn so với khi đi theo hướng lợi nhuận. Vì vậy anh cho rằng việc nghĩ kỹ về mục tiêu là cực kỳ quan trọng (video đăng ngày 11/04/2025).

13. Price structure: packaging và price architecture

Phần tiếp theo mà James và đồng nghiệp dành nhiều thời gian là price structure: hệ thống bạn có để phân biệt giá (price differentiate) trên tập khách hàng của mình, cụ thể là cách bạn tính những mức khác nhau cho những khách hàng nhận được lượng giá trị khác nhau từ sản phẩm và có willingness to pay khác nhau (theo James, video đăng ngày 11/04/2025).

Packaging là một phần của nó. Theo James (video đăng ngày 11/04/2025), giới SaaS hay nghĩ tới mô hình good, better, best, nhưng thật ra có rất nhiều mẫu (motif) khác nhau có thể dùng. Và kể cả khi chọn good, better, best, việc xây từng tier, đặt feature nào và capacity threshold nào vào mỗi tier, vẫn là cả một nghệ thuật.

Rồi đến phần price architecture, nối lại chuyện price metric đã bàn ở trên: price metric nào, hay những price metric nào, là đúng với bạn, gắn với giá trị bạn tạo ra, hướng tới tăng trưởng và vân vân. Và bạn scale giá theo metric đó thế nào (theo James, video đăng ngày 11/04/2025):

• Tính cùng một mức cho mỗi đơn vị metric thêm vào (theo James, video đăng ngày 11/04/2025).
• Giảm dần đơn giá khi số lượng tăng, kiểu volume discounting (theo James, video đăng ngày 11/04/2025).
• Hoặc chia dải (band): ví dụ của James là một giá cố định từ 1 đến 10 seat, và một giá cố định từ 11 đến 20 seat (video đăng ngày 11/04/2025).

Theo James, những điều này nghe có vẻ vụn vặt, nhưng là những quyết định rất quan trọng, ảnh hưởng đáng kể tới cách khách hàng tương tác với sản phẩm của bạn và mua nó (video đăng ngày 11/04/2025).

14. Willingness to pay: không có một cách đúng

Điều cuối cùng James nêu ở đây là bản thân willingness to pay, chuyện tìm ra mức giá đúng mà bạn nên đặt. Anh kể là một chuyên gia pricing, anh rất thường được hỏi: "James, cách đúng để lấy willingness to pay là gì?" Câu trả lời thường của anh là đó là câu hỏi sai, vì không có một cách đúng nào (theo James, video đăng ngày 11/04/2025).

Theo James (video đăng ngày 11/04/2025), bạn nên lấy dữ liệu willingness to pay theo vài cách khác nhau rồi đối chiếu chéo (triangulate) giữa chúng để tìm ra mức giá đúng. Lấy dữ liệu willingness to pay rất khó, khó mà có được thứ gì hoàn toàn đáng tin nếu chỉ dựa vào một nguồn. Vì vậy thường tốt nhất là lấy vài phép đo khác nhau, nhìn qua tất cả, rồi ra một quyết định cân bằng dựa trên mọi thứ thu được.

Ken nói với anh willingness to pay là điều bí ẩn trong chuyện này, vì nếu hỏi thẳng, người ta khó mà nói cho bạn mức tối đa (video đăng ngày 11/04/2025). Có tiếng nói tiếp: họ sẽ trả giá thấp hết mức (lowball). Rồi một người trong hai nói "Yeah, exactly", và một người trong hai nói thêm rằng bạn không thể hỏi thẳng như thế, điều đó là không thể.

15. Case study Help Scout: vì sao phải đổi

Ken muốn bàn một điều cuối để chuyện này thật hơn với thính giả. James từng có một khách hàng mà anh giúp chuyển từ user-based sang usage-based pricing, một trong những điều hai người đã bàn trước buổi ghi hình. Ken mời James kể về case study đó: những cân nhắc khi bước vào, thay đổi thực tế diễn ra thế nào, và khách hàng của công ty đó phản ứng ra sao (video đăng ngày 11/04/2025).

James nói công ty đó là một nền tảng customer satisfaction, customer experience tên là Help Scout. Anh gọi đây là một công ty rất thú vị và là một trong những công ty anh rất thích làm cùng. Trong tất cả khách hàng anh làm cùng khoảng năm, sáu năm qua, anh không nghĩ ra công ty nào lấy khách hàng làm trung tâm như Help Scout: họ đặt trọng tâm vào việc khách hàng có trải nghiệm mua tốt, trải nghiệm dùng tốt, khách hàng là trên hết (theo James, video đăng ngày 11/04/2025).

Dẫu vậy, theo James, điều đó cũng khớp với sứ mệnh của anh và đồng nghiệp ở Monevate là giúp các công ty làm việc này: bạn nhận ra rằng nếu không monetize sản phẩm hiệu quả và không tự đặt mình vào thế thành công về sau, thì bạn chẳng giúp được khách hàng nào (video đăng ngày 11/04/2025).

Không đi vào quá nhiều chi tiết, James kể Help Scout biết cách mình đang định giá không hiệu quả và cần thay đổi. Công ty có một motion PLG, packaging kiểu good, better, best, và tính giá theo user. Đây là kiểu nền tảng customer support, nên user ở đây thường là các nhân viên customer support dùng nền tảng để xử lý thắc mắc của khách hàng (theo James, video đăng ngày 11/04/2025).

Vấn đề Help Scout gặp, theo James (video đăng ngày 11/04/2025), đúng là những thách thức của user-based pricing đã bàn ở trên. Thứ nhất, khách hàng của họ đôi khi phản ứng tiêu cực với việc phải trả cho ngày càng nhiều user: khách lớn hơn, cần nhiều người trên nền tảng hơn, nhưng điều đó không phải lúc nào cũng tương ứng với nhiều giá trị hơn. Vậy là có ma sát, và cách định giá đó không giúp gì cho khách hàng.

Và tất nhiên Help Scout cũng nhìn về phía trước, thấy AI và automation, và nghĩ rằng customer support nói chung là một trong những mảng mà AI thật sự có khả năng làm thay đổi mạnh. Vậy số user mà khách hàng cần có giảm dần theo thời gian không, và doanh thu của Help Scout có gặp rủi ro vì thế không, khi số user sẽ nhỏ đi? Công ty đi theo hai hướng song song: điều gì đúng cho mình và điều gì đúng cho khách hàng về sau, và biết rằng mình cần thay đổi (theo James, video đăng ngày 11/04/2025).

16. Contacts helped: metric mới, kết quả và lời kết

James nói anh sẽ tóm khoảng 10 tuần làm việc vào vài phút. Cuối cùng, anh làm việc với team Help Scout và cùng quyết định price metric đúng cho công ty về sau là contacts helped (theo James, video đăng ngày 11/04/2025).

Với một bộ phận customer support, metric này là: bạn đã tương tác với bao nhiêu khách hàng của khách hàng, đã giúp bao nhiêu người, đã giúp họ giải quyết thắc mắc. Hiển nhiên đó là usage-based, vì nó theo dõi lượng thực sự được dùng. Nhưng theo James (video đăng ngày 11/04/2025), nó rất gắn với giá trị: nó khớp đúng với cách nền tảng được dựng lên để giúp khách hàng, gắn với giá trị hơn nhiều so với chỉ đếm số người dùng nó. Nó dựa trên lượng đầu ra bạn có được nhờ dùng công cụ.

Theo James (video đăng ngày 11/04/2025), metric này chạy rất tốt về mặt value proposition và cũng chạy rất tốt từ góc nhìn khách hàng: nó giúp Help Scout xuống được những mức giá thấp hơn cho các khách hàng nhỏ, những nơi không có nhiều khách hàng cần phục vụ.

Và một trong những điều khiến James bất ngờ hơn cả khi làm loại việc này: hoá ra metric mới dự đoán được tốt hơn so với user. Trước đó Help Scout tính theo active user, tức số nhân viên customer support đang dùng nền tảng, và con số đó thường dao động khá nhiều mỗi tháng. Còn số khách hàng mà bạn giúp thì ổn định hơn nhiều. Vì vậy, theo James (video đăng ngày 11/04/2025), nó chạy rất tốt cho Help Scout ở góc độ gắn với giá trị và bảo vệ doanh thu về sau, và cũng chạy rất tốt từ góc nhìn khách hàng, giúp khách hàng không phải thay đổi số tiền trả nhiều từ tháng này sang tháng khác.

Ken nói điều đó nghe hợp lý một cách trực giác. Với tổ chức dùng phần mềm và ban quản lý của họ, họ thấy khá cụ thể chi phí để phục vụ tập khách hàng của mình là bao nhiêu, nên có thể đưa chi phí đó vào pricing của chính họ. Với Ken, có vẻ điều đó lành mạnh hơn cho khách hàng (video đăng ngày 11/04/2025).

James đồng ý: đây là một trong những trường hợp hiếm hoi mà nó thật sự là win-win. Anh nói vẫn còn rất sớm, Help Scout mới ra mắt nó vài tháng trước, nhưng sẽ rất thú vị để xem nó diễn ra thế nào (theo James, video đăng ngày 11/04/2025). Ken nói có lẽ sáu hay chín tháng nữa hai người phải xem lại kết quả.

Ken nói đây là chỗ hay để khép lại tập, một cuộc trò chuyện tuyệt vời về một trong những chủ đề anh thích, pricing và packaging. Cuối tập, Ken cảm ơn James Wilton đã làm khách mời của SaaS Backwards, và James cảm ơn Ken đã mời.