AMA: RevOps với AI, usage-based và consumption-based pricing

1. Từ webinar thành AMA, và chuyện CEO bước ra từ cuộc họp board

Đây là một buổi AMA (ask-me-anything) của RevOps Co-op. Theo mô tả video đăng ngày 15/08/2025, Camela Thompson là Head of Marketing ở RevOps Co-op, còn James McArthur là VP of Product Advocacy ở Nue.io; hai người nói về những gì thực tế xảy ra với AI, usage-based pricing và consumption-based pricing. Hai người nói chuyện qua video call: khung của Camela gắn nhãn "Community Team", khung của James gắn tên anh.

James mở đầu: Camela và anh là host của buổi hôm nay. Vốn dĩ hai người vẫn sẽ là host, nhưng giờ buổi này sẽ chuyển thành một AMA về revenue model, CPQ, usage và consumption.

Camela mời mọi người cứ đặt câu hỏi trong phần comment và Q&A. Chị nói sẽ bắt đầu bằng vài câu chuyện "trauma", rồi chị sẽ hỏi James xem những chuyện đó lẽ ra đã có thể tránh được như thế nào.

Chị cũng tò mò muốn biết trong số người tham dự có bao nhiêu người đã từng bị thông báo rằng công ty sắp chuyển sang consumption-based, hay value-based, hay một thứ gì đó tương tự, ngay sau một cuộc họp board lớn, hoặc sau khi bạn nghi là CEO của mình vừa đọc Forbes. Chị nghĩ mình không phải người duy nhất từng gặp chuyện đó.

Camela nói chị lớn tuổi hơn, và đã làm RevOps từ lâu. Nên khi usage-based bắt đầu thành một xu hướng, đó là điều đầu tiên CEO của chị nói khi bước ra từ một cuộc họp board: "chúng ta phải làm usage-based". Và ngay cả khi chị và đồng nghiệp chỉ ra rằng công ty không hề track usage, cả nhóm vẫn phải tìm cách làm cho được. Chị có cảm giác đây chính là nơi sinh ra rất nhiều pricing model (theo Camela, video đăng ngày 15/08/2025). Chị hỏi James: anh có hay gặp chuyện này không, và làm sao để đi trước nó?

2. Hai con đường dẫn tới usage pricing

James nói có hai luồng suy nghĩ dẫn các công ty tới usage. Luồng thứ nhất: ai đó đọc một bài báo về việc usage pricing có thể cải thiện revenue retention. Ý tưởng là tính tiền những khách hàng thật sự dùng sản phẩm, theo đúng mức họ dùng sản phẩm (theo James, video đăng ngày 15/08/2025).

Luồng thứ hai là những công ty đang có subscription model và không chắc mô hình đó có đang đi đúng hướng với mình không. Họ nói kiểu: "tôi muốn chắc là mình đang thu được nhiều doanh thu nhất có thể", hoặc "tôi có một tính năng thử nghiệm, không biết có ai thật sự dùng không, nhưng tôi muốn kiếm tiền từ nó" (theo James, video đăng ngày 15/08/2025).

Anh kể anh và đồng nghiệp ở Nue nói chuyện với rất nhiều khách hàng có usage nhưng thật ra không rate nó. Những khách hàng này chỉ tính một khoản tiền và nói "đây là lượng usage bạn đã mua", mà không có rating engine nào đứng sau (theo James, video đăng ngày 15/08/2025).

Cái khó, theo James (video đăng ngày 15/08/2025), là trong thế giới RevOps, nơi ta "kiểm soát được những gì mình kiểm soát được", rất khó chuyển khách hàng qua lại giữa ba paradigm đó. Đúng như Camela nói: lãnh đạo đọc một bài báo, và bỗng nhiên bạn phải roll out usage pricing. Bạn rate nó thế nào? Bạn meter nó thế nào? Product DB của bạn kết nối vào cái gì?

3. Rating, metering và vì sao RevOps ít phân tích product usage

Những câu hỏi đó, theo James (video đăng ngày 15/08/2025), có nghĩa là bạn phải kéo engineer vào, và anh nói "đó luôn là một chuyến đi nhanh". Đó là một vòng lặp không hồi kết, và với phần lớn công ty thì nó kết thúc trong buồn bã, vì khi triển khai CPQ hay usage pricing, bạn phải tính tới: người dùng có thật sự quan tâm thứ này không? Họ có dùng nó không? Định nghĩa thành công của họ là gì?

Rồi bạn sẽ báo với khách hàng thế nào rằng billing model của họ đã đổi hoàn toàn chỉ sau một đêm, rằng từ giờ họ sẽ bị tính tiền cho tất cả những thứ này theo mức họ dùng. Nó không còn là subscription nữa, mà là "dùng tới đâu trả tới đó". Và bạn sẽ nói chuyện với khách thế nào khi một người bên phòng kế toán của họ chạy 18 câu query, và bỗng nhiên hoá đơn tháng đầu là $10,000 trong khi lẽ ra là $200 (ví dụ của James, video đăng ngày 15/08/2025)?

Camela tiếp lời: "Ừ, và tôi không hề được báo trước, vậy tôi sẽ vui tới mức nào khi chuyện đó vừa xảy ra?"

Chị quay lại chuyện engineer mà James vừa chạm tới. Chị kể chị đã làm một số nghiên cứu: chị và nhóm ở RevOps Co-op đã làm một khảo sát rất lớn, và chị kinh ngạc vì có quá ít revenue operator đang phân tích product usage và đưa nó vào hệ thống của mình (theo Camela, video đăng ngày 15/08/2025). Chị hỏi James: anh nghĩ vì sao? Nó thuộc về một phòng ban khác à? Hay chúng ta chỉ đang không ưu tiên nó đúng mức? Bởi chìa khoá của usage-based pricing là hiểu usage, đúng không?

James đồng ý, nhưng nói rằng tiếc là một product DB được thiết kế tốt hiếm khi phù hợp để ghi lại mỗi lần ai đó làm một việc gì. Khi build sản phẩm, bạn nghĩ về UI, UX: chuyện gì xảy ra khi khách làm X, chuyện gì xảy ra khi khách làm Y (theo James, video đăng ngày 15/08/2025).

Còn để thật sự rate và meter khách hàng theo những gì họ đang làm, theo James (video đăng ngày 15/08/2025), bạn phải nghĩ qua các use case scenario của họ, phải đứng ở phía bên kia, nhìn từ góc khác. Và góc nhìn đó không bao giờ xuất hiện khi bạn đang nghĩ "làm sao build sản phẩm tốt nhất có thể". Lúc đó bạn không nghĩ "đâu là điểm dễ kiếm tiền nhất trong sản phẩm này", rồi "tôi cần biết mỗi lần ai đó làm việc đó, ai làm, làm lúc nào, làm thế nào". Nó không nằm trong tầm nhìn của product.

James nói thêm, cho dù chuyện này đáng giá bao nhiêu: anh đã từng ở có lẽ ba công ty khác nhau nơi product và revenue thật sự nói chuyện với nhau (video đăng ngày 15/08/2025).

4. Change management: báo sớm, báo thường xuyên, cho xem dashboard trước

Camela dựng một tình huống: giả sử CEO nói như vậy. Chị nhắn một người tham dự rằng chị đã thấy comment của họ, hoàn toàn đồng ý, và sẽ quay lại ý đó sau một chút. Rồi chị tiếp: giả sử bạn ở một công ty mà CEO nói "tôi là người quyết định, chúng ta sẽ làm usage-based pricing". Một trong những thứ chị thấy nổ tung rất nhiều là việc thiếu change management và thiếu chuẩn bị thông điệp cho khách hàng rằng thay đổi này đang tới (theo Camela, video đăng ngày 15/08/2025). Chị hỏi James đã thấy mọi người làm gì để giảm thiểu chuyện đó, trước khi bàn tới phần kỹ thuật của việc triển khai usage-based, hay cả consumption-based, mà trong đầu chị thì hai thứ này khá giống nhau.

James nói nó giống như việc sẽ không có phim hành động nào xảy ra nếu ngay từ đầu mọi người chịu nói chuyện với nhau. Camela thêm: "hoặc Harry Potter, nếu tụi nhỏ chịu nói chuyện với một người lớn". James: "Đúng vậy, đúng vậy. Nếu bạn không chạy lòng vòng ôm hết thông tin trong tay mà thật sự trao đổi với ai đó, thì sẽ có người giúp được." (video đăng ngày 15/08/2025)

Điều hiệu quả, theo James (video đăng ngày 15/08/2025), là giao tiếp sớm và thường xuyên. Kiểu: "chúng tôi đang chuyển đổi subscription của bạn. Chuyện này chưa xảy ra ngay bây giờ. Nó sẽ diễn ra trong sáu tháng tới. Chúng tôi sẽ cập nhật cho bạn khi có thay đổi."

Camela chen vào: "Nhưng hãy thật sự gửi những bản cập nhật đó, làm ơn, làm ơn. Đó là chỗ khác mà mọi thứ hay đổ vỡ." (video đăng ngày 15/08/2025)

James tiếp (video đăng ngày 15/08/2025): ba tháng trước khi release, hãy roll out usage nhưng chỉ cho khách xem một dashboard về việc họ đang thật sự dùng sản phẩm thế nào. Đừng tính tiền ngay. Chỉ cho họ thấy họ đang dùng sản phẩm nhiều tới đâu. Rồi để AE liên hệ, kiểu: "này, bạn đang dùng sản phẩm 10,000 lần mỗi tháng. Như vậy sẽ là $500 usage mỗi tháng", hoặc "$5,000 usage mỗi tháng", và nói "mình cùng sắp xếp chuyện này nhé". Rồi việc đàm phán có thể bắt đầu.

Như vậy, theo James (video đăng ngày 15/08/2025), ngay từ đầu bạn có thể làm việc với khách hàng sao cho họ thật sự hiểu: thứ nhất, họ sẽ bị tính bao nhiêu, và thứ hai, những gì cấu thành khoản đó. Hãy chắc là bạn có sẵn tài liệu về mọi khía cạnh usage mà bạn sẽ tính tiền, ngay từ khoảnh khắc bạn công bố. Đừng để tin đồn lan ra kiểu "họ sắp tính phần trăm doanh thu đấy" trong khi thật ra bạn sẽ tính theo API call.

Hãy giao tiếp nhiều với khách hàng, giao tiếp nhiều với prospect. Không ai thích bất ngờ. Và "không ai" ở đây, James nói, là mọi người làm tài chính từng tồn tại. Nếu anh mang tới CFO của công ty anh một hoá đơn $5,000 bất ngờ, có thể anh sẽ bị giết. Anh nói không phải là CFO nhất định sẽ giết anh một cách công khai, nhưng có thể lắm (video đăng ngày 15/08/2025).

Nên ý chính, theo James (video đăng ngày 15/08/2025), là giao tiếp sớm, giao tiếp thường xuyên, giao tiếp nhiều nhất có thể, và chắc là bạn đang xây sự dự đoán được vào những gì mình làm, để theo thời gian khách hàng biết 100% họ sẽ trả bao nhiêu và họ sẽ bị tính tiền như thế nào: có phải mỗi lần rep của họ đăng nhập không, và đó có phải thứ họ có thể gỡ bằng permission set không? Có phải mỗi lần ai đó tải một file xuống không? Họ có hiểu được điều đó không? Đồng thời, hãy làm việc với các team engineering.

Camela nói chị rất thích ý roll out dashboard ít nhất ba tháng trước, vì hy vọng điều đó có nghĩa là bạn có năng lực analytics ở đâu đó, dù có thể giao diện không đẹp. Nhờ vậy việc hiểu mọi thứ đang đi về đâu với các khách hàng chủ chốt sẽ dễ hơn một chút, và khả năng forecast của bạn cũng dễ hơn một chút (theo Camela, video đăng ngày 15/08/2025).

5. Surprises là thứ giết usage-based billing

Camela đọc câu hỏi của một người tham dự: bạn có thấy usage-based billing có thể là một vấn đề lớn cho pricing, bundling và forecasting vì usage khó đoán không (câu hỏi trong video đăng ngày 15/08/2025)? Chị nói phần vừa rồi phần nào giải thích được, nhưng mời James nói thêm.

James: "Ừ, 100%. 100%." Theo anh (video đăng ngày 15/08/2025), khi bạn bill usage, những bất ngờ là thứ giết bạn. Anh hỏi có ai ở đây có tài khoản AWS không. Kiểu, bỗng nhiên bạn cài một ứng dụng vào tài khoản AWS của mình, và "ồ, cái đó vừa ngốn hết usage của cả tháng, $1,000 đấy". Và bỗng nhiên bạn tiêu nhiều hơn rất nhiều so với mức mình định ở một chỗ nào đó. Chính những bất ngờ là thứ giết khả năng làm usage-based của bạn.

Camela thêm: "để quên một thứ gì đó chạy ở back end". Chị kể chị từng làm trong ngành storage nhiều năm, và công ty chị làm usage-based billing. Số lần khách hàng bị sốc vì ai đó quên tắt một thứ gì đó, hoặc tích hợp mà không nói với phần còn lại của team, là rất nhiều (theo Camela, video đăng ngày 15/08/2025).

James đáp: "Ừ, anh và nhóm cũng có một phiên bản của chuyện đó." Anh và nhóm từng có một khách hàng quyết định query 512,000 record của họ mỗi 25 mili giây. "Năm trăm mỗi 25 mili giây. Bạn nghĩ chuyện đó làm gì với hoá đơn AWS của tụi anh? Nó vọt lên tận trời." (theo James, video đăng ngày 15/08/2025)

Điều xảy ra, theo James (video đăng ngày 15/08/2025), là bạn không bao giờ biết khi nào những chuyện như vậy sẽ xảy ra. Nhưng với tư cách một doanh nghiệp muốn xuất hoá đơn hay bill ai đó cho khoản đó, một lần nữa, giao tiếp là chìa khoá. Có một hệ thống mà những gì rep của bạn quote có thể được định vị đúng như usage billing, rồi có một hệ thống rating và metering trả trước cho khách thấy chính xác họ sẽ bị bill bao nhiêu ngay từ đầu: có nhiều khả năng giao tiếp với khách hàng hơn thì tốt hơn đáng kể so với cách ngược lại.

6. Forecast và compensation khi bán theo usage

Camela nói câu hỏi lớn mà chị luôn nghĩ tới là: sales forecast usage thế nào từ quote cho tới opportunity, và trả compensation thế nào trên usage? Chị biết trong khảo sát chị và nhóm đã làm, salespeople căng thẳng rất nhiều về việc dự đoán chuyện này (theo Camela, video đăng ngày 15/08/2025). Chị hỏi James hai hay ba model hoặc nguyên tắc anh khuyên dùng để xử lý bài toán forecast và compensation.

James nói một cái đã được bàn rồi. Anh nhớ có lần nói chuyện với một người ở Twilio cách đây vài năm, và ý là có rất nhiều cách nghĩ về compensation khi bán theo usage, vì khoản trả trước (upfront) sẽ không hoạt động như cũ. Nếu bạn bán committed usage, tức là bạn biết chính xác khách đó sẽ rate bao nhiêu trong năm, hãy trả cho rep một khoản upfront trên phần committed, phần mà rep cam kết được khách, rồi trả thêm bonus trên phần vượt. Như vậy là đảm bảo thành công cho khách hàng đó (theo James, video đăng ngày 15/08/2025).

Nếu bạn làm pure usage-based, theo James (video đăng ngày 15/08/2025), hãy lập một rubric cho khách hàng net new, ví dụ: khách hàng có 1,000 nhân viên thường dùng sản phẩm ở mức này trong một khoảng thời gian nhất định. Camela thêm: "hoặc theo một use case cụ thể, bất cứ thứ gì tương quan với usage". James: "Đúng vậy. Rồi dùng cái đó làm khoản upfront." Với renewal, expansion và những thứ tương tự thì câu chuyện dễ hơn nhiều: hãy nhìn vào lịch sử của khách, nhìn vào mức bạn có thể khiến họ cam kết hoặc mức họ sẵn sàng, mức rate bạn đã đàm phán cho thời gian tới, rồi trả comp cho rep dựa trên đó.

Nhưng lưu ý, theo James (video đăng ngày 15/08/2025): bất cứ thứ gì bạn làm theo kiểu nhìn về phía trước sẽ dẫn tới chuyện bạn phải làm pullback. Bạn sẽ phải kéo lại commission của một rep vào lúc này hay lúc khác. Vậy hãy có một chiến lược để xử lý chuyện đó. Một trong những phần khó nhất của usage hay consumption-based model là nhìn về phía trước: chưa ai từng dự đoán chính xác được usage của bất kỳ ai.

Nên hãy lập một rubric về mức bạn nghĩ một khách hàng sẽ thật sự dùng, rồi trả bonus dựa trên việc khách vượt lên trên mức đó trong suốt năm. Rep của bạn sẽ không mấy hào hứng khi chuyển từ subscription model sang usage model. Theo James (video đăng ngày 15/08/2025), cách làm tốt nhất là có một rubric dự đoán dựa trên use case, genre hoặc ICP, rồi liên tục đánh giá. Liên tục, trong sáu tháng đầu sau khi roll out, anh nói là mỗi tuần một lần, mọi người ngồi lại: tuần này ta thấy gì? Cái gì hiệu quả? Cái gì không? Ta đang làm thế nào? Rồi điều chỉnh model để trả comp tốt hơn cho phần dự đoán, với mọi deal net new tới sau đó.

Camela nói nếu nghĩ kỹ thì chúng ta vốn đã khá quen với sự mơ hồ mà không biết. Sales forecasting dựa trên việc dự đoán hành vi người mua, và theo thời gian ta đã dùng machine learning cùng nhiều phương pháp để làm việc đó tốt hơn. Với usage-based, ta về cơ bản đang làm điều tương tự; nó chỉ được gọi bằng tên khác và trông đáng sợ hơn (theo Camela, video đăng ngày 15/08/2025).

7. Usage-based khác consumption-based: Clay và thẻ Starbucks

Camela hỏi James phân biệt usage-based với consumption-based thế nào.

Theo James (video đăng ngày 15/08/2025), usage-based là mức một người đang dùng sản phẩm. Đó là pay-as-you-go: mỗi lần người dùng này làm việc này, ta tính $0.05 một lần. Còn consumption là: người này đã mua trước $10,000 credit. Với giá năm cent mỗi API call, 10 cent mỗi đơn vị storage, sẽ mất chừng đó thời gian để họ dùng hết (draw down) số đó.

Consumption, theo James (video đăng ngày 15/08/2025), hoặc là committed usage có phần drawdown dẫn vào một overage model, hoặc là drawdown dựa trên credit hay tiền mặt trên nhiều sản phẩm. Và điều đó đòi hỏi một hệ thống quản lý được cash pool và credit pool. Cho ai chưa biết: một credit pool giống như những gì bạn có ở Clay, nơi bạn vào và họ cho bạn 10,000 credit một tháng; mỗi hành động bạn làm tốn hai credit, năm credit, tuỳ hành động. Đó là một credit burndown model kinh điển.

Cash burndown thì là Starbucks: bạn nạp $25 vào thẻ Starbucks, mỗi lần ghé vào bạn mua ly đồ uống năm, sáu đô. Camela chen vào: "với một số người trong chúng ta thì là vài ngày sau". James: "Ừ." Hôm sau bạn phải mua lại, nạp lại credit, nạp lại cash pool của mình. Đó là những consumption model kinh điển mà anh và nhóm làm việc cùng (theo James, video đăng ngày 15/08/2025).

Nói chung, theo James (video đăng ngày 15/08/2025), với phần lớn doanh nghiệp thì cash burndown sẽ là model đơn giản nhất, vì một lần nữa, nó là đô la đổi đô la. Còn nếu bạn ở trong tình huống có một credit model kiểu Clay, bạn sẽ muốn đi theo credit burndown.

Camela đọc câu hỏi của một người tham dự: liệu mọi người có hiểu các thuật ngữ này giống như vừa trình bày không? Chị nói có lẽ là không, vì doanh nghiệp nào cũng có cách riêng, nhưng những gì James nói là cách hiểu chị nghe thấy nhất quán nhất (theo Camela, video đăng ngày 15/08/2025).

8. Partial comp thay cho pullback: ba bucket

Camela nói người tham dự đã hỏi ở phần trước có vài comment thú vị. Chị đọc comment đầu tiên, về compensation khi làm usage-based: chẳng phải trả comp từng phần (partial comp) sẽ tốt hơn làm pullback sao? "Tôi không biết sales rep nào biết cách xoay xở với kiểu kia." (comment Camela đọc trong video đăng ngày 15/08/2025)

James: "Hoàn toàn đúng." Anh nói anh 100% đánh giá cao, hay đúng hơn là yêu thích, những comp plan có một phần upfront. Khi nói về usage hay consumption, hãy để phần upfront là phương tiện chính, rồi gần như một cơ cấu bonus trong đó 20 hoặc 30% là phần thứ hai, rồi thêm khoảng 20 hoặc 30% theo team. Kiểu ba bucket mà rep có thể rơi vào (theo James, video đăng ngày 15/08/2025).

Bucket thứ nhất được trả ngay. Theo James (video đăng ngày 15/08/2025), bạn không bao giờ kéo lại phần đó, vì đó là upfront commit, trừ khi khách churn kiểu một tuần sau. Bucket thứ hai được trả khi khách dùng sản phẩm, nên bạn sẽ không bao giờ phải kéo lại. Bucket thứ ba thuần tuý dựa trên hiệu suất của team, khuyến khích mọi người làm việc cùng nhau, và không ai đi làm "sói đơn độc".

9. Khảo sát về subscription, và rào cản của outcome-based pricing

Camela đọc một comment khác và nói chị muốn "rant" một chút đi kèm. Comment viết: người ta giả định AI sẽ đưa chúng ta tới outcome-based, nhưng có quá nhiều vấn đề cần giải quyết, nên usage sẽ là model chính trong một thời gian (comment Camela đọc trong video đăng ngày 15/08/2025).

Camela nói trong các khảo sát chị và nhóm đã làm, subscription vẫn rất rõ là model dẫn đầu mà các doanh nghiệp SaaS dùng. Chị nghĩ khoảng 75% trở lên vẫn dùng nó; phần còn lại, chị nghĩ khoảng 11% dùng usage, và có một nhóm kết hợp usage với subscription (theo khảo sát Camela dẫn trong video đăng ngày 15/08/2025). Nên subscription vẫn là thứ chị thấy nhiều nhất, dù là vì hệ thống còn thiếu sót hay vì loại sản phẩm doanh nghiệp đang có. Chị hỏi: outcome-based có những rào cản lớn nào? Chị nói chị đang giữ một bài rant để dành cho James. Những rào cản lớn nào ngăn chúng ta tới chỗ có thể làm outcome-based pricing một cách đáng tin cậy?

Theo James (video đăng ngày 15/08/2025), rào cản lớn nhất của outcome-based pricing là trust. Khách hàng có tin rằng những outcome bạn nói mình đang mang lại là thật sự đang được mang lại không? Outcome-based pricing có nghĩa là bạn có một cửa sổ nhìn vào những gì khách đã đạt được nhờ dùng sản phẩm. Hai bên đều đồng ý về định nghĩa rằng đó là một thành tựu. Và cuối cùng, lùi hẳn ra, bạn có một cách đo lường chủ động điều đó mà không cần một cuộc trao đổi hai chiều vào cuối tháng.

James so sánh với return on ad spend của Google ngày trước: Google yêu cầu đáp ứng những tiêu chí cực kỳ cụ thể trước khi bạn có thể bật nó lên (theo James, video đăng ngày 15/08/2025). Camela thêm: "Rồi sau đó họ gặp rắc rối vì làm giả số liệu. Thế đấy." (theo Camela, video đăng ngày 15/08/2025)

Camela nói chị rất bực chuyện này, vì chị đã ở đó cái thời proof of concept còn là chuẩn mực trong ngành phần mềm, thậm chí khi người ta vẫn còn bán phần cứng. Vấn đề lớn nhất chị và đồng nghiệp gặp phải là thành công luôn là một mục tiêu di động với khách hàng, nó quá chủ quan. Ngay cả khi đã có "chúng ta sẽ đạt cái này, cái này và cái này", nếu khách không cảm thấy một cách nhất định về nó, thì bằng cách nào đó vạch đích lại dịch chuyển mỗi lần (theo Camela, video đăng ngày 15/08/2025).

Chị không thấy outcome-based sẽ khác chỗ đó thế nào, nhất là khi bạn cố gắn nó với doanh thu của khách. Bạn sẽ có quyền truy cập vào dữ liệu đó bằng cách nào? Trừ khi bạn là kiểu một nền tảng e-commerce đang xử lý giao dịch cho họ, thì có lẽ (theo Camela, video đăng ngày 15/08/2025).

Có tiếng đáp: "100%." James nói tất cả chúng ta đều đã làm việc với một CFO không thích chi tiền ra. Giờ hãy tưởng tượng phải đàm phán một hoá đơn outcome-based với CFO đó, khi bạn là một nhà cung cấp SaaS: bạn ngồi đó và nói "này, tụi tôi đã làm được việc này", còn họ đáp "tôi không thấy. Anh đang nói gì vậy?". Và rồi bạn phải đàm phán lại mọi hoá đơn đi ra khỏi cửa. Nó chỉ dẫn tới việc bạn tự đẩy mình xuống một cái hố tuyệt vọng và kinh hoàng, chẳng có lợi cho ai, có lẽ trừ chính bạn. Bạn thật sự đang mở cửa cho việc đàm phán mọi hoá đơn bạn gửi đi (theo James, video đăng ngày 15/08/2025). Có tiếng đáp: "Ừ, chính xác."

10. Subscription là gì, và vì sao usage đặt doanh thu vào rủi ro

Camela đọc câu hỏi của một người tham dự: subscription có nghĩa là một khoản phí cố định hằng tháng không? Chị trả lời: không nhất thiết. Subscription có thể là theo năm, theo quý, theo tháng, nhưng thường là một platform fee hoặc một khoản phí dự đoán được. Chị lấy ví dụ Marketo: họ có kiểu subscription cộng consumption, trong đó bạn nhìn vào khối lượng contact base, rồi bạn dự trù sẽ phải đàm phán một khoản phụ phí 7% khi renewal (theo Camela, video đăng ngày 15/08/2025).

James nói có một câu hỏi trước đó, anh không nhớ xuất hiện ở đâu, về việc vì sao một công ty sẽ chọn subscription thay vì usage-based. Theo anh (video đăng ngày 15/08/2025), nó gắn với định nghĩa subscription: trong ngành này, đó là lý do predictable revenue từng khiến mọi người phấn khích đến vậy ngày trước. Có những hoá đơn dự đoán được đi ra cho khách hàng mỗi tháng là cực kỳ quan trọng.

Nên khi chuyển sang usage, theo James (video đăng ngày 15/08/2025), bạn đang đặt 100% doanh thu của mình vào rủi ro. Theo nghĩa đen: nếu bạn roll out một model 100% usage-based và không ai dùng sản phẩm, bạn vừa mất hết doanh thu. Còn với một doanh nghiệp subscription, hiển nhiên bạn tính khách X platform fee cộng X số user mỗi tháng; về cơ bản bạn đang dự đoán, đang bảo đảm, khoản doanh thu đó hằng tháng ở một mức độ nhất định.

Anh và nhóm thậm chí đã thấy có người chuyển từ usage quay lại subscription, vì họ đã đánh giá quá cao mức người ta sẵn sàng trả cho việc dùng sản phẩm (theo James, video đăng ngày 15/08/2025). Nên để thật sự chọn usage, hãy chắc là sản phẩm của bạn "sticky" với chữ S viết hoa. Người dùng phải yêu sản phẩm của bạn. Họ phải cảm thấy thiếu nó khi nó không có ở đó.

Với bất kỳ ai đang nghĩ tới usage-based model, theo James (video đăng ngày 15/08/2025), hãy nhận ra rằng subscription dự đoán được 100%: nó cho bạn cùng một khoản mỗi tháng, hoặc mỗi quý, mỗi năm, hay mỗi tuần, tuỳ cách bạn tính phí. Anh chen ngay: đừng gửi hoá đơn hằng tuần, không ai thích thế. Còn với usage, bạn đang tự đặt mình vào rủi ro.

Camela nói chị nghĩ điều đó trả lời câu hỏi của một người tham dự khác, về kiểu kết hợp subscription với usage dạng "use it or lose it". Theo chị (video đăng ngày 15/08/2025), khó khăn hay rủi ro lớn của kiểu đó là khách sẽ không dùng hết phần "use it or lose it", và bạn chỉ đang đẩy credit về phía sau. Đo lường cũng là một thách thức lớn: bạn có đang đo đủ tốt việc khách có dùng hay không? Và bạn cấu trúc phép tính burndown thế nào để xác định khi nào khách mất phần đó? Nên chị thấy có hai chỗ rủi ro ở đó.

11. Legacy system, Steelbrick và những credit không ai meter

Camela muốn tới một câu hỏi: những pitfall phổ biến mà James thấy ở các công ty dùng legacy system khi triển khai những revenue model mới đòi hỏi linh hoạt hơn là gì? Và anh định nghĩa legacy system thế nào? Chị gợi ý: "Steelbrick?". James: "Steelbrick. Steelbrick là một legacy system." (video đăng ngày 15/08/2025)

Ngày nay, theo James (video đăng ngày 15/08/2025), legacy system phần lớn là bất kỳ hệ thống nào được build trước khi headless application thật sự trở thành một thứ phổ biến. Là bất kỳ hệ thống nào được build theo paradigm "gọi điện và bán một thứ, mỗi lần một thứ". Khi nói về legacy system, đó là bất cứ thứ gì thiếu linh hoạt, bất cứ thứ gì được build dựa trên ý tưởng một salesperson nhấc điện thoại và "quay số kiếm tiền". Bất cứ khi nào thứ đó tồn tại và chảy qua billing platform của bạn, bạn đang nhìn vào một legacy system.

Với anh và nhóm ở Nue, theo cách anh và nhóm định nghĩa (video đăng ngày 15/08/2025), một modern system là hệ thống có đủ linh hoạt để chứa nhiều pricing model khác nhau, tất cả những thứ đó, trên mọi mặt. Và điều anh và nhóm đang thấy là rất nhiều khách hàng tới và nói: "ừ, tụi tôi đã có subscription, đang chuyển sang kiểu credit, kiểu consumption subscription, kịch bản use it or lose it". Có rất nhiều người nói: "ừ, nhiều năm nay tụi tôi vẫn nói là gói của mình đã bao gồm 5,000 thứ gì đó, nhưng chưa bao giờ tính tiền cho nó". Và có những người làm subscription nhưng bao gồm 5,000 API credit mà họ không thật sự meter; không ai biết số credit đó đang ở đâu.

Nên khi nghĩ về modern hay legacy system, theo James (video đăng ngày 15/08/2025): legacy system là hệ thống khiến rep của bạn muốn mở một file Excel ra để tính xem họ thật sự đang tính bao nhiêu, thật sự sẽ quote bao nhiêu cho một khách, hoặc khiến team tài chính của bạn phải nói "tôi không thể truy ngược cái này về quote". Có rất nhiều hệ thống như vậy ngoài kia.

Camela nói chị đã kể tên một cái rồi. James: "Ừ, Steelbrick là một cái dễ thấy." Camela: "Ừ. Nó là một trong những thứ được mua về rồi bị bỏ mặc." James thêm: "đã bị tắt đi" (trao đổi giữa hai người trong video đăng ngày 15/08/2025).

12. Cơ cấu comp phổ biến và chuyện rollover

Camela đọc câu hỏi của một người tham dự: cơ cấu compensation thực tế nhất là gì, kiểu base cộng tier cộng accelerator, hay theo quan sát của anh thì sao (câu hỏi trong video đăng ngày 15/08/2025)?

Theo James (video đăng ngày 15/08/2025), phổ biến nhất là base cộng incentive cộng team. Nói chung, trong thế giới usage, đó là khoản payout committed trả trước, cộng usage incentive, rồi cộng thêm mục tiêu KPI nào đó của tổ chức. Dù với phần lớn sales team thì nó đúng nghĩa đen là "cứ đi ra kiếm doanh thu, đừng làm phiền tụi tôi". Nên hai bucket kia là chính. Nhưng anh muốn thấy thêm một mục tiêu team ở trên, vì ai cũng làm tốt hơn khi chơi cùng nhau.

Camela chuyển sang một câu hỏi khác và nói mọi người đã nghe chị nghĩ gì về chuyện này rồi, giờ mời James nói.

James nói anh cũng không thích nó. Theo anh (video đăng ngày 15/08/2025), bạn ký một deal với khách hàng. Lý do duy nhất để làm rollover là khi bạn liên tục sai về việc "committed" thật sự nghĩa là gì, hay về mức khách thật sự sẽ dùng sản phẩm: khi đó hãy làm rollover, rồi rút nó lại với khách hàng mới ngay khi bạn có một baseline vững để hiểu người ta thật sự sẽ làm gì. Bởi rollover tạo ra một khoản liability cho phần usage đó. Và mỗi lần như vậy bạn sẽ phải quay lại và nói kiểu "được rồi…", mà không ai muốn có cuộc nói chuyện đó. Bạn không muốn là người đó, anh cũng không muốn là người đó. Nên hãy làm cho mọi thứ dễ dàng với khách ngay từ đầu, rồi theo thời gian thì rút lại dần.

13. Pass-through cho chi phí cloud infrastructure

Camela đọc câu hỏi của một người tham dự: rất muốn nghe lời khuyên về việc tính phí pass-through usage cho chi phí cloud infrastructure; best practice ở đây là gì (câu hỏi trong video đăng ngày 15/08/2025)?

James nói anh chưa bao giờ thật sự phải làm việc đó, nên nói trước cho rõ: đây là cuộc trò chuyện về "những gì tụi anh đang thấy". Theo anh (video đăng ngày 15/08/2025), nếu bạn làm cost pass-through thì đó là cost plus model: cộng thêm phần của bạn, đưa chi phí quản lý vào, rồi chuyển nguyên trạng cho khách. Bạn có thể làm một lần kéo dữ liệu mỗi tháng, kiểu: vào ngày 31 hoặc 30, ta sẽ tải lên tất cả các khoản pass-through, và xuất hoá đơn cho khách vào ngày 1. Bạn có thể làm theo model đó. Nếu bạn dựng được một luồng dữ liệu liên tục vào metering system và rating system của mình, bạn có thể làm chi tiết hơn. Nhưng thật lòng, với mọi khoản pass-through thì là cost plus.

Camela đọc tiếp một comment: phần khó khi ước tính infrastructure usage là phải thu thập dữ liệu usage của khách hàng (comment Camela đọc trong video đăng ngày 15/08/2025).

Theo James (video đăng ngày 15/08/2025), bạn phải track nó qua sản phẩm của mình. Nếu không track được qua sản phẩm, bạn không thể tính usage, vì bạn đang đặt mình vào một tình huống kinh khủng: lúc nào cũng là cuộc cãi nhau kiểu "hãy tin khách hàng". Lỡ bạn thấy một khách đang rất thành công, rồi họ quay lại và gửi cho bạn con số bằng 50% mức usage bạn kỳ vọng thì sao? Không ai muốn thế. Nên khi nói tới việc lấy dữ liệu usage: nếu không track được nó bên trong product DB, bạn không thể bill cho nó, hoặc không nên. Anh nói anh sẽ không nói là "không thể": cứ làm, cứ sống với những giấc mơ hoang dại của mình, cứ làm theo ý bạn, nhưng anh thì sẽ không làm.

14. Outcome-based làm đúng trông thế nào: ví dụ HubSpot

Camela nhắc mọi người cứ gửi câu hỏi, chị đang theo dõi chat và Q&A. Rồi chị hỏi James: anh đã thấy ai triển khai outcome-based pricing theo cách mà anh thấy hợp lý chưa?

James nói anh nghĩ là không, trừ khi bạn là một nền tảng… trừ khi, như Camela nói, bạn đang ghi nhận được chính những outcome khách muốn. Ví dụ nếu bạn tính phần trăm doanh thu và bạn là một hệ thống track được doanh thu của khách, thì đó là một outcome mà tất cả đều đồng ý được, vì doanh thu là doanh thu (theo James, video đăng ngày 15/08/2025).

Camela hỏi: "Bạn cũng là một CRM à? Có thể. Tôi biết HubSpot thấy được mọi thứ." James: "Ừ, họ kiểu như vậy." Anh kể về email tới contact mà bạn nhận được từ HubSpot, kiểu "chúc mừng, bạn đã được nâng lên tier subscription tiếp theo vì giờ bạn đã chạm 80,000 contact". Và bạn kiểu: "tôi đâu có định thế. Có ai vừa làm gì à?" (ví dụ của James, video đăng ngày 15/08/2025).

Nhưng đúng là có rất nhiều ví dụ outcome-based pricing thành công ngoài kia, theo James (video đăng ngày 15/08/2025); có điều chúng đúng nghĩa đen là những trường hợp outcome được gắn sẵn vào chính hệ thống đang tính tiền cho nó. Bạn không thể nhìn vào những thứ bên ngoài rồi nói "được, đây là thứ ta sẽ tính outcome". Một lần nữa: nếu bạn không track được nó, bạn không thể bill nó, hoặc không nên bill nó.

Camela xen vào một câu ngắn: "they were exposed". James nói đó là mặt còn lại: nếu bạn định làm thì đừng nói dối về nó (video đăng ngày 15/08/2025).

Camela đưa ra một "lời khuyên tư vấn không mất tiền" cho những ai cũng đang dùng HubSpot: một người đã được enrich mà chưa opt-in nhận liên lạc thì không phải là marketing contact. Hãy tiết kiệm tiền và làm đúng luật. Được enrich không có nghĩa là marketing được phép liên lạc. "Không có gì." (theo Camela, video đăng ngày 15/08/2025) Có tiếng nói thêm: hãy dùng sales contact của bạn một cách khôn ngoan, one-to-one, dùng cách workaround đó.

15. Forecast khi có nhiều loại doanh thu

Camela nói chị đang xem lại các câu hỏi trước. Nếu không thấy thêm câu hỏi nào, buổi này có thể kết thúc sớm một chút. Chị hỏi James có điều gì anh muốn chắc chắn được nói tới trước khi mọi người ra về không, giả sử không có thêm câu hỏi. James nói vẫn còn một câu hỏi nữa.

Camela kể chồng chị làm sales ops. Chị đã giới thiệu anh ấy tới James, và James đã thuyết phục anh ấy rằng lúc đó chưa cần CPQ. Chị nói James rất thẳng thắn về việc cái gì hiệu quả và cái gì không (theo Camela, video đăng ngày 15/08/2025). Chị để James trả lời câu hỏi còn lại, rồi hai người sẽ khép lại bằng một bài rant về CPQ trong bối cảnh này. James đáp: "sẽ hay đấy", có khi còn quá giờ. Có tiếng đáp: "Ừ. Cứ để anh ấy nói."

James đọc câu hỏi của một người tham dự: lời khuyên tốt nhất để track forecast với tất cả những loại doanh thu khác nhau này là gì? Theo anh (video đăng ngày 15/08/2025), trước hết hãy lùi lại một bước và dựng chính xác các benchmark revenue model cho từng use case. Camela thêm điều kiện: "giả sử bạn có dữ liệu và không phải lần đầu roll out." James: "Đúng."

Nếu không có dữ liệu, theo James (video đăng ngày 15/08/2025), hãy làm một "strategic wild-ass guess" (SWAG): bạn đi vào và lấy càng nhiều dữ liệu càng tốt để dựng một baseline cho những gì bạn nghĩ nó sẽ là. Nhìn vào chi phí licensing truyền thống, PLG truyền thống, tất cả những thứ khác nhau đó, rồi tính: được, nếu tôi convert X phần trăm thì đây là dự đoán của tôi. Đây là số người ta đang có trên plan này. Nếu tôi đưa thêm X người tiếp cận dựa trên các model hiện có, tôi sẽ có mức tăng 5%. Làm như vậy, từ góc độ forecast.

Camela bổ sung (video đăng ngày 15/08/2025): hãy lập model. Làm một bản moderate rồi một bản conservative. Rồi khi bắt đầu, hãy đo thường xuyên sau khi roll out, nhất là ở mốc ba tháng; nếu bạn lệch xa, hãy cho mọi người biết.

16. Bài "rant" về CPQ

James chuyển sang CPQ trong bối cảnh này. Anh nói anh có quan điểm mạnh về CPQ vì đã trải qua rất nhiều lần triển khai CPQ tệ hại, và cũng đã trải qua vài lần triển khai CPQ tốt. Anh cũng đã xây một chương trình triển khai ở Nue, nên anh nói rõ là mình hiển nhiên rất thiên vị (video đăng ngày 15/08/2025).

Nhưng theo James (video đăng ngày 15/08/2025), thế giới CPQ đã mang tiếng xấu một cách không cần thiết. Nếu những công nghệ cốt lõi ta dùng mỗi ngày đều chạy hoàn hảo, ta đã không ở đây; B2B SaaS đã không tồn tại. CPQ cũng vậy. Nhiều năm nay CPQ là kiểu hệ thống mà bạn mua về, rồi team admin của bạn vào và build cả đống customization lên trên, tạo ra một mạng nhện hỗn độn quái gở. Thế là rep của bạn không biết mình đang bill cái gì, không biết mình đang tính bao nhiêu, không biết sản phẩm nào được bán cho ai, và nó tạo ra rất nhiều nhầm lẫn cho các team.

Theo James (video đăng ngày 15/08/2025), qua nhiều năm chuyện đó đã được giải quyết bởi những administrator giỏi. "Giỏi… đúng vậy", anh nói, anh thích câu đó, sẽ in nó lên áo. Anh kể anh đang nghĩ nên treo gì lên tường, và anh sẽ treo dòng "Rube Goldberg hell". Nhưng đã có những architect giỏi, developer giỏi, admin giỏi bước vào và nói: không, hãy giữ nó đơn giản. Build đơn giản, build lặng lẽ, build dễ dàng.

Đồng thời, theo James (video đăng ngày 15/08/2025), nhiều năm nay CPQ được nhắc tới tách rời khỏi billing, mà thẳng thắn thì một thế giới nơi bạn bán một thứ cho ai đó mà không tính tới việc nó sẽ thật sự được bill ra sao là điên rồ. Nếu bạn đang tạo quote, tạo order mà không nghĩ tới hoá đơn sẽ được gửi đi, không dùng cùng proration model với billing system, không có một luồng pass-through một-một tới sales order… Có tiếng xen vào: "Kiểu, bạn đang làm gì vậy?" James tiếp: tất cả những gì bạn đang làm là tạo thêm việc cho team tài chính. Bạn đang tạo ra nỗi đau, đủ thứ.

Nên khi nói về CPQ, James xếp chúng vào hai nhóm (video đăng ngày 15/08/2025): những hệ thống đã sẵn sàng cho một thế giới mới, nơi PLG, self-service và tất cả những thứ đó tồn tại, và những hệ thống hoàn toàn chưa. Bất cứ thứ gì mà vừa bước vào bạn đã tự động phải bắt đầu viết Apex hay flow để nó chạy được ở mức cơ bản, nghĩ tới Salesforce native, là đã hỏng.

Bất cứ thứ gì không xử lý được thay đổi, như thay đổi định kỳ, cập nhật số lượng, upsell, expansion, contraction, theo James (video đăng ngày 15/08/2025), thì bạn sẽ làm gì? Giờ bạn là một công ty chỉ bán new business. Bạn không thể thật sự thay đổi gì. Lại là chuyện cancel-and-replace một lần nữa. Và bất cứ thứ gì không kết nối với billing system của bạn, bạn sẽ phải hoàn lại cho khách rất nhiều tiền, hoặc team tài chính sẽ muốn giết bạn, một trong hai. Đó là quan điểm cứng rắn của anh về các CPQ system, và anh nhắc lại là mình rất thiên vị.

James nói hy vọng bài rant của anh ổn với Camela. Camela nói nỗi bực lớn nhất của chị là các hệ thống này đều được build cho việc thu hút khách mới, và hiếm khi tính tới expansion, upsell, phần đó của sales cycle, việc track lifecycle và tất cả những thứ tương tự. Theo chị (video đăng ngày 15/08/2025), con người chúng ta có xu hướng rất thiển cận.

17. Định giá tính năng AI: cost plus và hệ số sáu đến tám lần

Camela đọc câu hỏi của một người tham dự: rất muốn nghe suy nghĩ về pricing model nên áp dụng khi đưa các tính năng AI, như tin nhắn tự động cho CRM, vào các subscription tier. Phần lớn những gì người đó thấy là các công ty đưa các tính năng này vào thành pro tier, nhưng muốn biết James nghĩ thế nào khi đi theo usage (câu hỏi Camela đọc trong video đăng ngày 15/08/2025).

Theo James (video đăng ngày 15/08/2025), mỗi lần dùng AI là bạn đang phát sinh một chi phí. Nó gần như một hardware model, nơi bạn có COGS thật cho từng hành động mà người dùng làm. Bạn đang bán một sản phẩm dùng một lần, nhiều lần. Và như vậy bạn đang bước vào cost plus model.

Với James (video đăng ngày 15/08/2025), cách anh thường làm với phần lớn mọi thứ là: nếu chi phí của tôi là $0.05, có lẽ tôi nên bán nó với giá $0.30, nghĩ theo mức bán lẻ gấp 6 lần chi phí. Nên làm việc dựa trên cost plus là điểm anh sẽ bắt đầu.

Nếu bạn còn nhỏ và đang lớn dần vào chuyện này, như khi bạn chưa biết, theo James (video đăng ngày 15/08/2025), vì nhiều khả năng lúc này bạn chưa ở OpenAI enterprise tier hoặc chưa có một MCP đẳng cấp thế giới để build vào, thì thứ bạn có là việc lập model để biết: thứ này sẽ tốn của tôi bao nhiêu khi tôi đạt mức độ phủ X? Sẽ tốn bao nhiêu khi tôi đạt mức Y? Hãy nhìn vào tập khách hàng hiện có, nghĩ xem họ sẽ dùng nó nhiều tới đâu, rồi đặt giá ở mức đó, vì bạn đang đưa ra một giả định.

Một lần nữa, theo James (video đăng ngày 15/08/2025), đó là một SWAG, nhưng hãy làm theo hệ số. Hãy nghĩ tới sáu đến tám lần chi phí của bạn ở mảng đó, vì: thứ nhất, bạn cần trang trải chi phí nhân sự để bán thứ đó, khoảng 20 tới 40 cent trên mỗi đô la. Bạn còn phải trang trải chi phí vận hành, lại thêm 20 tới 40 cent trên mỗi đô la nữa, tới lúc đó bạn ở mức kiểu 5% margin, hoặc thấp hơn. Nhưng bạn có thể nghĩ từ góc độ đó. Thật lòng, anh sẽ đưa nó về một hard goods model, đặt nó vào khung đó, nghĩ về profit margin theo cùng cách bạn nghĩ ở đó, rồi build usage model quanh đó và build cho đúng.

Camela nói việc nhìn vào những gì đã hiệu quả với người khác, những gì người ta phàn nàn và vì sao họ phàn nàn, rồi điều chỉnh theo sai lầm của người khác, là điều rất đáng làm (theo Camela, video đăng ngày 15/08/2025).

James đồng ý, và nói nó giống như việc có những hãng xe ngoài kia đang lỗ $300,000 trên mỗi chiếc xe $100,000 bán ra. Anh sẽ không nêu tên, nhưng đó là một hãng sản xuất xe điện (theo James, video đăng ngày 15/08/2025). Nhưng khi nhìn vào chuyện đó, hãy nghĩ về chi phí thật của bạn và cả mức thị trường chịu được. Vì đừng tính $2 cho mỗi lần tương tác, như vậy là điên rồ. Hãy thực tế và nghĩ từ model đó.

18. Mô hình định giá agent của Salesforce và lời kết

Camela nói có rất nhiều bàn tán về mô hình định giá agent của Salesforce, mà Salesforce mới thay đổi vào thời điểm video đăng ngày 15/08/2025, và theo chị là thay đổi có lý do chính đáng. Chị hỏi James còn gì muốn bổ sung trước khi để mọi người về sớm vài phút không.

James nói không, anh rất quý mọi người vì đã ở lại tới cuối. Buổi này rất tuyệt, cảm ơn mọi người đã ở lại cùng, và anh rất hào hứng. Lời cuối là một câu cảm ơn mọi người.