Thuần hoá usage, consumption và outcome-based pricing trong thời AI

1. Mở đầu: một webinar về usage, consumption và outcome-based pricing

Đây là một webinar trò chuyện giữa James McArthur, VP of Product Advocacy ở Nue, và Chris Brubaker, SVP of Finance ở Postscript (chức danh theo mô tả video đăng ngày 25/08/2025). Slide mở đầu mang logo Nue, công ty của James, và video được đăng trên kênh RevOps Co-op.

James chào mọi người tới webinar hôm nay. Chủ đề là mọi ngóc ngách (the ins and outs) của usage pricing, consumption pricing và outcome-based pricing. Và vì thứ gì cũng dính tới nó, anh nói, có lẽ lúc này lúc khác hai người cũng sẽ nói tới AI. Anh giới thiệu khách mời là Chris Brubaker từ Postscript và chào Chris. Chris cảm ơn vì được mời. James nói anh rất hào hứng với buổi này, rồi tự giới thiệu: anh là James McArthur, VP of Product Advocacy ở Nue (theo video đăng ngày 25/08/2025).

James nói mục tiêu hôm nay là gộp góc nhìn của hai người lại. Buổi này xoay quanh Postscript và hành trình của Chris: chiến lược ban đầu là gì, hành trình bắt đầu ra sao, những chỗ đã đi sai (trong phạm vi Chris có thể nói), những chỗ đã đi rất đúng (trong phạm vi Chris muốn ăn mừng), hiện giờ nhóm Chris đang ở đâu và Chris đang nghĩ gì về thế giới pricing này. Cuối cùng, nếu còn thời gian, hai người sẽ nói về việc AI đang thay đổi nó ra sao (theo video đăng ngày 25/08/2025). James hỏi Chris thấy thế có ổn không, và Chris đáp rằng nghe rất ổn.

2. Chris Brubaker và bài học outcome-based pricing ở OpCity

James mời Chris kể về bản thân trước, rồi tới hành trình của anh ở Postscript. Chris giới thiệu: anh tên Chris, là Senior Vice President of Finance ở Postscript, và đã làm ở đây khoảng bốn năm (theo video đăng ngày 25/08/2025). Anh nói chức danh của mình hơi gây hiểu nhầm, vì ngoài finance và accounting, anh còn phụ trách cả analytics và revenue operations. Nhờ vậy anh được trải rộng khắp mảng pricing, usage metrics và những thứ tương tự.

Lần đầu Chris thật sự tiếp xúc với outcome-based pricing là khoảng tám năm trước (tính từ lúc video đăng ngày 25/08/2025), ở một công ty tên OpCity, một công ty công nghệ bất động sản. Anh lấy ví dụ: khi bạn vào một trang như Zillow và gửi thông tin của mình để xem một căn nhà, trước đây thông tin đó cứ thế bị bắn vào hư không. OpCity đứng ngay sau bước đó: về cơ bản công ty này ghép các lead từ những website tìm nhà với các agent bất động sản.

Theo Chris (video đăng ngày 25/08/2025), mô hình giá của OpCity là thế này: các agent không trả gì trước để dùng dịch vụ. Thay vào đó, họ trả một phần trăm hoa hồng (commission) của mình ở phía sau, nếu họ chốt được một trong những lead mà OpCity tạo ra cho họ. Chris nói đó là nơi anh học được sức mạnh của outcome-based pricing và usage-based pricing: nó có thể căn chỉnh động lực (align incentives) giữa người dùng sản phẩm và công ty, để mọi thứ cùng tiến về đúng một hướng.

Anh giải thích: tất cả những gì OpCity muốn là giỏi hơn trong việc giúp agent bán được nhà, thay vì phí thời gian nói chuyện với những người sẽ không mua. Từ đó, anh đã áp dụng bài học này suốt sự nghiệp của mình (theo video đăng ngày 25/08/2025).

3. Postscript: từ credit sang usage thật, rồi tới SMS Sales

Khi Chris về Postscript khoảng bốn năm trước (tính từ video đăng ngày 25/08/2025), công ty đang dùng một mô hình kiểu credit cũ (legacy credit-based model). Về cơ bản đó là consumption-based pricing, một hỗn hợp giữa SaaS và consumption: khách mua trước một "ngân hàng" credit, và credit bị trừ dần khi họ gửi tin nhắn. Chris giải thích Postscript gửi tin nhắn văn bản thay cho các nhà bán lẻ online tới khách hàng và subscriber của họ.

Nhưng ngay từ khá sớm trên hành trình đó, theo Chris (video đăng ngày 25/08/2025), nhóm anh nhận ra mô hình credit và consumption thường gây khó hiểu cho khách hàng. Khách thấy nó không giúp họ hiểu cách tạo ra kết quả tốt cho việc kinh doanh của mình. Vì vậy qua nhiều năm, Postscript chuyển dần sang một mô hình usage thật sự (a true usage model): có giá riêng cho từng loại tin nhắn và từng cách dùng sản phẩm.

Khách hàng theo dõi rõ ràng mình đang tiêu bao nhiêu, và cuối kỳ được tính tiền theo mức dùng thực tế. Không có credit bị lãng phí, không có chuyện chuyển credit sang kỳ sau (rollover), không có những thứ như vậy, và Chris nói điều đó đã giúp ích rất nhiều (theo video đăng ngày 25/08/2025).

Theo thời gian, Postscript còn thêm một vài mô hình giá khác, trong đó có những mô hình outcome-based hơn, nằm trong một dự án mà nhóm anh gọi là SMS Sales. Ở đó có một nhóm kết hợp AI với con người trong vòng lặp (AI plus human in the loop) giúp khách hàng chốt deal: chuyển những người đã đăng ký danh sách nhận tin nhắn nhưng chưa mua gì thành khách hàng thật, rồi khách hàng trả cho Postscript một khoản commission trên giao dịch đó (theo video đăng ngày 25/08/2025).

James khen điều đó rất hay, và nói Chris đã có một hành trình thú vị. Anh gọi Chris là một ca "department of all" điển hình, vì Chris ôm cả nhiều mảng. Chris khởi đầu với outcome-based pricing, thứ mà theo James ai cũng thích. James nói chính anh cũng luôn yêu ý tưởng outcome-based pricing, vì nó giống như mọi bên cùng thành công khi cùng làm. Nhưng nếu bạn không sở hữu cái outcome đó, mọi chuyện trở nên khó. Rồi việc Chris chuyển sang mô hình usage truyền thống, James thấy cũng thú vị (theo video đăng ngày 25/08/2025).

4. E-commerce trưởng thành, COGS và token AI

James nhắc lại: tất cả đã sống qua năm 2022, đã sống sót qua năm 2023, và bây giờ mọi thứ có vẻ ổn hơn, dù vẫn còn hơi ngoằn ngoèo. Cùng với đó là một sự dịch chuyển liên tục, và Chris đang tự trải qua một phần của nó: với sự ra đời của AI, theo James (video đăng ngày 25/08/2025), các công ty SaaS lại quay về một thế giới phải định giá dựa trên COGS (COGS-based pricing). Cũng là một thế giới mà ai cũng tung ra 100 sản phẩm mới mỗi tuần, và khách hàng kỳ vọng một mức linh hoạt đáng kinh ngạc. James hỏi: những điều đó đã đóng vai trò bao nhiêu trong việc Chris đẩy về các mô hình khác biệt này và về usage-based pricing?

Chris nói nó đóng một vai trò rất lớn. Riêng ngành của Postscript, bán cho ngành e-commerce, theo Chris (video đăng ngày 25/08/2025) đã có một vài năm đặc biệt khó khăn sau giai đoạn tăng vọt như tên lửa của 2020 và 2021. Và khi thị trường trưởng thành, người trong ngành nghĩ về việc kinh doanh của mình thông minh hơn nhiều. Từ chỗ có rất nhiều người gửi áo thun đi từ gara nhà mẹ, ngành chuyển sang những doanh nghiệp e-commerce thật sự ở tầm enterprise, với mức tăng trưởng mà Shopify đang cho thấy.

Theo Chris (video đăng ngày 25/08/2025), khi khách hàng là những người vận hành trưởng thành hơn, những người nghĩ kỹ từng chi tiết, họ bắt đầu nghĩ: tôi không muốn trả tiền cho thứ không tạo ra kết quả cho việc kinh doanh của tôi. Vì vậy, căn giá trực tiếp theo usage và theo outcome của khách giúp bạn làm những việc như tính ROI tốt hơn. Nó giúp bạn chứng minh giá trị sản phẩm. Nó cũng giúp khách hàng yên tâm rằng họ đang trả tiền cho thứ mang lại giá trị cho họ.

Chris nói Postscript đi trước đường cong AI một chút, vì trong mảng nhắn tin văn bản, công ty phải chịu một mô hình COGS thật sự, khác với SaaS thông thường. Nên công ty bị buộc phải làm chuyện này sớm hơn. Nhưng chắc chắn với AI, khi Postscript thêm AI vào sản phẩm, việc hiểu thật rõ mình tiêu bao nhiêu token để vận hành sản phẩm, định giá phần đó sao cho hấp dẫn với khách mà vẫn bảo đảm công ty có lãi và hiệu quả, đã thêm rất nhiều nếp nhăn (wrinkles) vào bài toán (theo video đăng ngày 25/08/2025).

5. Mỗi loại tin nhắn một mức giá

James nói nghe như mọi chuyện bây giờ đã phức tạp hơn rất nhiều. Anh thích mối liên hệ trực tiếp này: Postscript làm tin nhắn văn bản từ lâu, nên luôn có phí nhà mạng (carrier fees). Sẽ luôn có phí nhà mạng. Sẽ không bao giờ có khoảnh khắc nhà mạng nói "thôi, lần này tôi khao" (theo James, video đăng ngày 25/08/2025).

James thấy thú vị ở chỗ, khi Postscript mở rộng ra, usage ngày càng phức tạp theo cách người ta dùng, vì nhắn tin văn bản đã không còn giống như năm năm trước. Anh chen một câu "shout out" cho "ZIRP era". Anh nói khi bàn tới outcome-based pricing trong thế giới nhắn tin văn bản, nơi cửa xả lũ đã mở (và mở từ lâu rồi), thì lượng dữ liệu của cả những tin nhắn cơ bản cũng đã tăng vọt. Anh hỏi Postscript đang xử lý độ phức tạp đó thế nào, khi người ta dùng tin nhắn cho nhiều việc hơn bao giờ hết: giờ còn muốn gửi cả video, và đủ thứ khác đang được đưa vào. Điều đó ảnh hưởng ra sao tới cách Postscript kinh doanh, xét về mặt linh hoạt (theo video đăng ngày 25/08/2025)?

Chris nói một trong những điều tuyệt vời của mô hình usage là Postscript có thể nhắm thật chính xác mức giá cho từng thứ. Trước đây, có thể bạn dùng một mô hình theo kiểu khác, hoặc một mô hình phí cố định (fixed fee), nơi bạn phải cố đoán trước usage của khách và cả tỷ lệ pha trộn giữa các loại usage đó. Còn bây giờ, theo Chris (video đăng ngày 25/08/2025), Postscript có thể nói thẳng:

• Gửi một tin nhắn cơ bản chỉ có chữ và emoji thì tốn chừng này (theo video đăng ngày 25/08/2025).
• Gửi tin có hình ảnh thì tốn chừng này (theo video đăng ngày 25/08/2025).
• Gửi tin có video thì tốn chừng này (theo video đăng ngày 25/08/2025).
• Gửi bằng sản phẩm AI infinity testing, nơi AI liên tục lặp lại để viết lại nội dung tin nhắn và test nó với các nhóm đối chứng (control group), thì tốn thêm một chút nữa (theo video đăng ngày 25/08/2025).

Chris nói các mức đó phản ánh những cấu trúc chi phí nền khác nhau mà Postscript phải xử lý. Anh thêm, không phải để tự khen FP&A, nhưng cần một đội finance thật vững và thật chu đáo để hiểu được, bóc tách và mô hình hoá các cấu trúc chi phí đó. Như vậy mới bảo đảm bạn trang trải được chi phí và cài sẵn được margin, trong khi không bắn quá đích và biến sản phẩm thành thứ kém hấp dẫn với khách hàng (theo video đăng ngày 25/08/2025).

6. FP&A và RevOps, "offensive line" của cả đội

James nói FP&A, cùng với RevOps (mà Chris được quản cả hai, nên James "cộng điểm" cho Chris), giống như hàng offensive line của các đội. Anh dùng hình ảnh này vì hai người vừa nói chuyện fantasy football ngay trước buổi webinar. Ý anh là bạn chỉ để ý tới họ khi mọi thứ thật sự hỏng (theo James, video đăng ngày 25/08/2025).

James nói có một lý do rất thật vì sao 95% người ta chỉ kể được tên một cầu thủ lineman trong NFL, và người đó thậm chí đã không còn chơi nữa (con số và nhận xét của James, video đăng ngày 25/08/2025). "Và tất cả các bạn đều biết tôi đang nói tới ai", anh nói, rồi thêm: "Go, Birds."

Quay lại chuyện chính, James nói việc Chris và nhóm nghĩ ra đủ các mô hình đó là rất hay. Nhưng anh muốn nghe về những gì nằm bên dưới, vì nối chuyện này vào việc quote chắc chắn không dễ. Anh nói anh đến từ một công ty CPQ, nên khó mà không hỏi theo hướng đó. Câu hỏi của anh: Postscript nối mọi thứ vào cách công ty thật sự kinh doanh như thế nào, từ khâu quote cho tới tận khâu invoice (theo video đăng ngày 25/08/2025)?

7. Từ quote tới invoice: order form, calculator và một Slack app

Chris nói nhóm anh đã học được rất nhiều bài học dọc đường. Bắt đầu từ trên cùng: trước đây Postscript có một mô hình quote rất đơn giản. Về cơ bản, nhóm quote giá cho thứ người ta dùng nhiều nhất, còn phần còn lại thì làm sao cũng được, với giả định khối lượng phần đó đủ thấp để không tạo khác biệt lớn tổng thể. Cách đó đứng được một thời gian. Rồi khi các công ty khách hàng thông minh hơn và sáng tạo hơn trong cách dùng sản phẩm, cách đó không còn bền vững nữa (theo video đăng ngày 25/08/2025).

Chris gửi lời khen tới team ops của Postscript: team đã làm một việc rất tốt trong việc xây order form theo cách linh hoạt, để nhóm có thể nạp hết các loại thông tin khác nhau đó và trình bày rõ ràng cho khách hàng. Team enablement đã làm rất nhiều việc để coach các AE và BDR về cách nói về việc kinh doanh, về giá trị của từng loại tin nhắn và những cách khác nhau để dùng sản phẩm. Rồi tất cả được nối vào FP&A và RevOps, hai bên bám rất sát phần quote to contract (theo video đăng ngày 25/08/2025).

Nhắc tới AI mà James nêu, Chris kể một trong những cách giúp nhóm anh làm việc này một cách scale được và bền vững: nhóm đã bỏ ra rất nhiều thời gian để xây một cái calculator thật vững, giúp hiểu unit economics của từng deal dựa trên cách khách dùng sản phẩm, giá của từng thứ, khối lượng và tốc độ tăng trưởng của khách, và những yếu tố như vậy (theo video đăng ngày 25/08/2025).

Theo Chris (video đăng ngày 25/08/2025), nhóm test calculator đó bằng tay một thời gian: RevOps thu thông tin, về cơ bản dựng một flow để lấy thông tin từ các AE, còn FP&A chạy bằng tay và kiểm xem mọi thứ có hợp lý không. Khi nó đã đủ thành công thức, nhóm vào Cursor và build cả một Slack app tự động hoá quy trình đó.

Chris rút ra: khi bạn hiểu đủ dữ liệu bên dưới, bạn có thể làm từng bước để đơn giản hoá quy trình thật sự, đưa nó vào một công thức, rồi đặt ra các ngưỡng rõ ràng: cái gì chấp nhận được, cái gì cần người xem lại (human review), và cái gì rõ ràng sẽ không bao giờ ổn. Nhờ đó bạn cắt giảm thời gian RevOps, FP&A và AE ngồi rà từng deal bằng tay, kiểm tra, bàn bạc, giữ phần việc đó cho những deal thật sự cần chú ý và để phần còn lại chạy theo công thức (theo video đăng ngày 25/08/2025).

8. Xây một xa lộ, chừa lối ra cho sự cố

James nói đây là chuyện anh hay nói khi làm các buổi training: mục tiêu là xây một xa lộ. Trong các đợt triển khai (implementations), việc số một là xây một xa lộ. 90% lưu lượng đi qua mà không có vấn đề gì. Còn lại là những lần cần dừng đi vệ sinh khẩn cấp hay đổ xăng khẩn cấp: những sự cố mà bạn cần làm lối ra cho người ta rẽ ra, để lấy được thứ họ cần khi có chuyện bạn không lường trước. James nói nghe như Chris đang làm rất tốt việc cài sẵn những lối ra đó (theo James, video đăng ngày 25/08/2025).

Rồi James muốn bàn một điều Chris vừa nhắc, vốn là một chủ đề lớn khi nói về usage: Postscript giao tiếp với khách hàng thế nào? Làm sao đi trước tình huống cậu thực tập sinh marketing mới vừa gửi 10.000 tin nhắn và việc đó sẽ tốn của khách $8.000, vì cậu ấy kèm cái video dài nhất lịch sử loài người vào tin nhắn? Ví dụ giả định của James trong video đăng ngày 25/08/2025. Postscript đi trước chuyện đó với khách hàng bằng cách nào?

9. Tránh bill shock: usage real-time, ngưỡng cảnh báo và estimator

Chris nói Postscript cố gắng thật chủ động với khách hàng. Nhóm anh đã build app theo cách theo dõi usage của khách, để khách thấy nó theo thời gian thực mỗi khi đăng nhập vào app, nên khách không bị bất ngờ vì một hoá đơn cuối tháng. Postscript cũng cài sẵn các trigger theo ngưỡng billing (billing threshold triggers). Và vì Postscript là một công ty nhắn tin, khách nhập số điện thoại, nhập ngưỡng muốn theo dõi, và nếu vượt ngưỡng đó, khách nhận được một tin nhắn (theo video đăng ngày 25/08/2025).

Chris thừa nhận Postscript không có cách nào chủ động chặn cậu thực tập sinh marketing gửi chiến dịch đó. Nhưng ít ra, ngay lần đầu chuyện xảy ra, khách sẽ nhận được một tin nhắn kiểu: "Này, ngân sách tháng này của bạn là $2.000. Bạn đã tiêu sáu rồi, và hôm nay là ngày 19 tháng 8." Khách sẽ phản ứng: ơ, chuyện gì vậy? Và vì hôm qua họ không nhận tin nhắn đó, chắc chắn mọi thứ đã xảy ra trong hôm nay. Vậy là khách có thể vào xem và tìm ra nguyên nhân (ví dụ của Chris, video đăng ngày 25/08/2025).

Postscript cũng chủ động hiển thị chi phí: theo Chris (video đăng ngày 25/08/2025), nhóm đã build các estimator, để khi bạn vào dựng một campaign flow, bạn phải định nghĩa các segment, nên bạn biết đại khái mình sẽ gửi cho bao nhiêu người. Con số đó có thể đổi giữa lúc dựng và lúc gửi, nhưng không đổi với số lượng lớn. Estimator cho bạn biết chính xác có bao nhiêu tin nhắn trong flow đó, ước lượng tổng khối lượng dựa trên các nhánh, và hiện ra chi phí ước tính.

Chris nói nó không hoàn hảo. Nó sẽ không nói "chiến dịch này tốn $604" rồi đúng là tốn $604. Có thể là $599, có thể là $612. Nhưng ít nhất nó cho một ước lượng hợp lý từ trước, để khi người làm marketing làm việc của mình, họ có ý niệm chiến dịch sẽ ảnh hưởng tới ngân sách tháng thế nào (theo video đăng ngày 25/08/2025).

10. Pricing committee bốn người

James khen điều đó rất hay, rồi hỏi tiếp: khi build những calculator đó, anh đoán đó là một nỗ lực tập thể rất lớn, và chủ yếu nằm ở phía product. Đội của Chris tham gia tới đâu? RevOps tham gia tới đâu? Chris đưa việc này vào workflow của đội mình như thế nào (theo video đăng ngày 25/08/2025)?

Chris kể về cơ bản Postscript có một kiểu pricing consulting committee, gồm một người từ product marketing, một người từ product, một người từ RevOps và một người từ finance. Bốn người đó ngồi lại với nhau và bàn những chuyện này. Bất cứ thứ gì ảnh hưởng tới tiền, hoặc hiển thị một ký hiệu đô la ở bất cứ đâu trong app, đều phải qua committee đó. Từ đó committee có thể rẽ nhánh và giao workflow cho các bên (theo video đăng ngày 25/08/2025).

Chris lấy ví dụ: khi build cái estimator lần đầu, engineering ước lượng phạm vi việc (scoped it), rồi mang tới committee và hỏi: cần nghĩ tới những gì cho phần tính toán? Công thức còn thiếu mảnh nào không? Có thể chạy vài bài test bằng tay để xem phép tính có đúng không? Rồi committee phân các việc đó cho những team hợp lý nhất để sở hữu từng workflow, dựa trên việc ai còn capacity. FP&A và RevOps làm dự phòng cho nhau khi một bên không đủ capacity (theo video đăng ngày 25/08/2025).

James nói đó là một cặp đôi hoàn hảo mà anh luôn có. Anh là một revenue operator, nhưng với anh, FP&A luôn là chỗ dựa khi bàn chuyện pricing, hoặc khi nghĩ xem cách tốt nhất để làm một việc mà không lỗ là gì. Anh thích mối quan hệ đối tác đó, và nói nghe như Chris cũng đang xây các quy trình governance một cách rất thông minh (theo James, video đăng ngày 25/08/2025).

11. Thống nhất định nghĩa, go/no-go và dám đổi giá

James hỏi tiếp: Chris làm sao đưa được mọi người vào phòng để đồng ý với tất cả các định nghĩa khác nhau? Anh biết bắt mọi phòng ban đồng ý những thứ cụ thể giống như lùa mèo (herding cats). Vậy làm sao, một là, không rơi vào analysis paralysis với tất cả những chuyện này, vì nó rất nhiều; và hai là, làm sao khiến mọi người đồng ý những định nghĩa cơ bản rồi tiến lên (theo video đăng ngày 25/08/2025)?

Chris nói đó là một việc lớn, anh sẽ không nói giảm nó. Nó cần rất nhiều stakeholder management và những mối quan hệ thật vững. Theo Chris (video đăng ngày 25/08/2025), trong RevOps và trong FP&A, tiêu chí lớn nhất để biết bạn có thành công trong sự nghiệp hay không là: bạn có xây được những mối quan hệ đó và quản lý được stakeholder không. Và khi đã có tiếng về chuyện đó, việc để RevOps hay finance dẫn dắt một số dự án như vậy dễ hơn, và họ có thể đưa nó về đích.

Chris nói bạn cũng phải là những người vận hành cực giỏi: có checklist, có spreadsheet, có timeline, và trình bày rõ cho mọi người: đây là cách chúng ta sẽ test, định nghĩa, thiết lập việc này; đây là cách chúng ta truyền đạt nó tới các team; và đây là timeline chúng ta làm. Như vậy lúc nào bạn cũng có các checkpoint go/no-go (theo video đăng ngày 25/08/2025).

Và theo Chris (video đăng ngày 25/08/2025), bạn cũng phải hiểu rằng mình có thể iterate. Bạn không cần làm đúng pricing ngay lần đầu. Bạn muốn nó tốt. Bạn không muốn thất vọng, và không muốn làm hỏng các bài test adoption sản phẩm vì pricing tệ. Nhưng đổi pricing sau này cũng không sao. Nên hãy học cách chạy những bài tập đó, chạy các thử nghiệm với cỡ mẫu (sample size) phù hợp, để rồi mở rộng ra, test và iterate tiếp từ đó.

12. Cái giá của một hệ thống billing tự build

Chris thẳng thắn nói một trong những thách thức lớn mà Postscript gặp là nhóm anh đã build rất nhiều thứ ngay trong app. Postscript không dùng Nue, hay bất kỳ phần mềm nào giống Nue. Nên khi đổi quy trình, team RevOps phải đổi cách quote flow đi qua quy trình ký hợp đồng, hoặc phải build một flow riêng (bespoke) vì đó là giai đoạn thử nghiệm ad hoc. Nhóm phải đổi quy trình quote để nạp được thay đổi đó vào cái Slack app đã build (theo video đăng ngày 25/08/2025).

Billing engine của Postscript do đội engineering build hoàn toàn theo kiểu tự làm. Nên engineering phải chạy một sprint để cập nhật billing module. Chris nói anh bảo là lúc nào cũng có thể test và iterate, nhưng với Postscript, làm việc đó rất tốn kém (theo video đăng ngày 25/08/2025).

Theo Chris (video đăng ngày 25/08/2025), ngày nay có những công cụ thật sự giúp được chuyện này. Nên nếu bạn ở một công ty có nhiều usage-based pricing, hay thử nghiệm pricing nhiều, thì nếu anh được quay lại build công ty này từ đầu, anh sẽ dựa vào một công cụ để cho phép iterate nhanh hơn, nạp được thông tin đó và thay đổi mà không cần cái flow chart khổng lồ bắt đầu từ AE enablement và đi suốt qua engineering và accounting để nạp toàn bộ quy trình. Hiện giờ nhóm anh phải chạm vào quá nhiều người.

13. Linh hoạt, và sáu tuần cho một thay đổi

James cảm ơn Chris đã trả lời trước câu "nếu có một cây đũa thần" mà anh định hỏi. Anh nói khi Chris build hệ thống đó, những thứ như vậy đơn giản là chưa tồn tại, và các công cụ đang thay đổi rất nhanh. Với những ai đang cố vung cây đũa thần đó hay nhìn vào tương lai, điều James nghe được từ Chris là: đừng lo phải làm đúng hoàn toàn, đừng lo phải biết hết mọi thứ mình đang làm, nhưng hãy chuẩn bị cho khả năng scale. Hãy chuẩn bị cho sự linh hoạt nhiều nhất có thể (theo James, video đăng ngày 25/08/2025).

Chris đồng ý, nhấn mạnh sự linh hoạt. Theo anh (video đăng ngày 25/08/2025), từ sớm, nhất là khi bạn mới bắt đầu thử nghiệm usage hay outcome-based pricing, nhưng cả trong một thế giới mà bạn tung sản phẩm mới hay tier mới, khả năng iterate, test và tinh chỉnh chúng là then chốt. Nó có thể là khác biệt giữa một năm tốt và một năm tạm được, vì bạn có thể chủ động thực hiện các thay đổi đó.

James nói thêm: vì nếu bạn mất sáu tuần cho một thay đổi trên sản phẩm, thì mỗi lần điều chỉnh, mỗi điều chỉnh nhỏ, thật ra là sáu tuần công. Chris đáp "Yep" và nói cái đó cộng dồn lại (compounds). James đáp: đúng vậy (theo video đăng ngày 25/08/2025).

14. Commission khi sản phẩm chưa biết định giá thế nào

James chuyển sang giai đoạn tiếp theo, phần mà mọi revenue operator và người làm finance cuối quý đều nhăn mặt trong lòng: commission, và nó liên quan thế nào tới tất cả chuyện này. Anh hỏi hành trình commission của Chris đã thay đổi ra sao, vì usage và commission là một trong những câu hỏi khó mà revenue operator và các team finance phải trả lời. Anh mời Chris kể trong phạm vi Chris có thể hoặc muốn nói, và nói hai người có thể bàn ở mức chung chung hơn nhiều (theo video đăng ngày 25/08/2025).

Chris nói anh sẽ cố giữ ở mức đủ khái quát để không tự chuốc rắc rối. Anh gửi lời khen tới đội AE của Postscript: một đội cực kỳ linh hoạt và thấu hiểu, đã cho nhóm anh rất nhiều sự rộng lượng để thử nghiệm. Theo thời gian, nhóm đã xây được niềm tin với đội AE rằng nhóm sẽ tìm ra cách, và đội AE sẽ làm rất tốt cho chính mình khi điều đó xảy ra (theo video đăng ngày 25/08/2025).

Theo Chris (video đăng ngày 25/08/2025), điều then chốt là: khi mọi thứ còn ở giai đoạn đầu, chưa được chứng minh, khi bạn chưa thể dựng một funnel model thật sự và giao một quota đạt được mà không phải xoay xở đủ kiểu, thì compensation nên dựa nhiều hơn vào SPIFF, cộng thêm vào OTE của đội sales. Không công bằng khi bắt ai đó phải kiếm 20% OTE của mình từ một sản phẩm mà chính công ty còn chưa biết định giá thế nào. Đặt gánh nặng đó lên đội sales là vô lý. Nên Postscript cố bám theo tư duy đó nhiều nhất có thể, rồi iterate và điều chỉnh từ đó.

Chris lấy ví dụ quý này: cuối Q2, Postscript ra mắt một sản phẩm mà nhóm biết sẽ thành công, nhưng không biết sẽ onboard được các shop nhanh tới đâu, cũng không biết usage của các shop sẽ ra sao. Nhóm biết khách sẽ dùng, nhưng số tiền khách chi cho sản phẩm đó có thể chênh lệch rất lớn. Vì vậy nhóm đặt một kiểu chương trình bounty cho AE, BDR và CSM (vì CSM cũng cross-sell nó vào các nhóm khách hiện có). Về cơ bản nhóm nói: khách chi bao nhiêu cho sản phẩm không quan trọng, gắn được sản phẩm này vào là được X. Nhóm chạy chương trình đó tới cuối năm, và hứa rằng tới cuối năm sẽ có hình dung tốt hơn nhiều về khối lượng, để chia tier và cho đúng quota credit từ đó trở đi (theo video đăng ngày 25/08/2025).

Chris nói anh đã thấy các công ty khác làm theo kiểu usage-based hơn nhiều, nơi sales được commission trên usage trong tương lai. Anh thẳng thắn nói Postscript không thích mô hình đó, và các AE của Postscript cũng không thích, vì nó làm thu nhập của họ dao động quá mạnh, và khiến họ tập trung quá nhiều vào những thứ đã bán từ hai, ba, bốn quý trước thay vì vào cơ hội trong pipeline (theo video đăng ngày 25/08/2025).

James nói điều đó hoàn toàn hợp lý. Anh tóm lại: về cơ bản là giữ cho đơn giản và công bằng; và nếu định thử nghiệm, hãy đặt phần đó vào nhóm "cộng thêm" của commission (theo James, video đăng ngày 25/08/2025).

15. Product-market fit khi scale một usage model

James nói Chris đã chạm tới chuyện này, và đây là câu hỏi cuối của anh: việc thật sự có product-market fit, không phải phiên bản thời ZIRP era của nó mà là có thật, quan trọng tới mức nào khi nói về usage? Và việc bạn cần biết khách hàng của mình, biết khách sẽ dùng sản phẩm thế nào, quan trọng tới đâu (theo video đăng ngày 25/08/2025)?

Chris nói nó thật sự là chìa khoá. Trong giai đoạn thử nghiệm, bạn sẽ phải tìm ra rất nhiều thứ. Nhưng khi scale một usage model, theo Chris (video đăng ngày 25/08/2025), product-market fit là cách duy nhất để bạn lên kế hoạch cho công ty từ năm này sang năm khác. Với kiểu SaaS mà anh đặt đối lập với usage-based, bạn có thể dựa phần nào vào việc biết mình có bao nhiêu tiền trong ngân hàng và số đó kéo dài bao lâu. Nếu bạn thấy tín hiệu churn rate tăng vọt vì không có product-market fit như mình tưởng, bạn có thời gian để pivot, vì tiền đã nằm trong ngân hàng. Bạn đã biết pipeline của mình trông thế nào.

Với usage-based, nhất là các sản phẩm usage-based thân thiện với khách hàng, Chris nhắc tới các công ty khổng lồ: theo Chris (video đăng ngày 25/08/2025), Snowflake không quan tâm nếu công ty bạn gặp khó khăn và sắp giảm usage đi 50%, vì bạn đã cam kết trả trước cho họ 90% mức usage mà bạn từng nghĩ mình sẽ dùng. Và bạn phải trả khoản đó. Nhưng với những công ty usage thật sự đặt khách hàng lên trước, nơi phần usage vượt mức cam kết tạo ra phần lớn doanh thu, mọi thứ có thể đổi chiều trong nháy mắt.

Theo Chris (video đăng ngày 25/08/2025), có product-market fit, thật sự hiểu khách hàng, dành đủ thời gian nói chuyện với khách, hiểu khách và dự báo việc kinh doanh của khách tạo ra khác biệt rất lớn. Năm nay, các khách hàng e-commerce của Postscript đứng trước một tình huống khiến COGS của một số khách tăng từ 10 tới 50%. Nếu nhóm anh không chủ động nói chuyện với khách và hiểu điều đó ảnh hưởng tới việc kinh doanh của khách ra sao, nhóm đã có thể đưa ra một số quyết định sai trong năm nay. Và nếu không có product-market fit thật vững, có thể nhóm đã mất hẳn một số khách hàng.

16. Skydive hay roller coaster, và lời cảm ơn

James nói đó là một cái kết rất hay cho buổi này, về cơ bản là: giao tiếp, giao tiếp, giao tiếp. Tất cả là về khách hàng. Vì nếu bạn build một sản phẩm usage mà không đặt khách hàng làm trung tâm, thì rốt cuộc thứ bạn xây giống một cú nhảy dù (skydive) hơn là một chuyến tàu lượn (roller coaster), mà lý tưởng là chuyến tàu lượn lúc nào cũng đi lên (theo James, video đăng ngày 25/08/2025).

Chris nói đó là lý do NDR dao động mạnh trong các doanh nghiệp usage. Lúc thuận lợi, các doanh nghiệp này sẽ có NDR mạnh nhất, bỏ xa phần còn lại. Lúc khó khăn, chúng sẽ bị ảnh hưởng một chút. Nhưng điều đó cũng có nghĩa là khách hàng của bạn đang trả tiền cho đúng giá trị họ nhận được (theo Chris, video đăng ngày 25/08/2025).

James đáp "Yeah", và nói thêm rằng nghe như đây là một lời quảng bá cho phòng FP&A: nếu bạn ở trong một doanh nghiệp usage-based, hãy có một phòng FP&A giỏi (theo James, video đăng ngày 25/08/2025).

James cảm ơn Chris đã tới và nói buổi này rất tuyệt. Anh cũng cảm ơn tất cả những ai đã nghe. Cuối buổi, James nói anh rất vui được ở đây và được nói chuyện với mọi người, cảm ơn mọi người và chúc một ngày tốt lành. Có tiếng nói tiếp: "Thanks, y'all."

17. Key takeaways: bắt đầu từ khách hàng

Chris nói ý then chốt đầu tiên: khi nghĩ về các mô hình usage và outcome-based pricing, điều cốt yếu là nói chuyện với khách hàng, hiểu khách hàng, và hiểu khách coi trọng điều gì. Vì chỉ ném thêm một thành phần usage vào business model của bạn thì chẳng có nghĩa lý gì, trừ khi khách hàng nối được giá trị họ nhận từ sản phẩm của bạn với đường cong usage đó. Nếu bạn không làm được điều đó, theo Chris (video đăng ngày 25/08/2025), bạn chỉ đang bám theo một trào lưu mà không thật sự hiểu usage-based pricing sinh ra để làm gì.

James nói: gần như thể usage-based pricing từ đầu tới giờ vẫn chính là outcome-based pricing. Có tiếng đáp "Right." James tiếp: mọi điều Chris nói đều quy về việc đặt khách hàng lên trước, và thật sự đặt khách lên trước, chứ không phải kiểu "làm sao kiếm nhiều tiền nhất có thể từ khách hàng", mà là "từ góc nhìn của khách hàng, làm sao chúng ta cùng khách tăng trưởng" (theo James, video đăng ngày 25/08/2025).

Chris đáp: đúng vậy. Và theo Chris (video đăng ngày 25/08/2025), sự tăng trưởng của khách hàng sẽ làm được cho việc kinh doanh của bạn nhiều hơn hẳn về dài hạn so với việc cố vắt thêm 5 hay 10% doanh thu trên mỗi widget, mỗi token hay bất cứ thứ gì.

Ý tiếp theo của Chris dành cho các team FP&A và RevOps, với giả định phần lớn quote-to-cash nằm trong hai mảng đó: khi bạn quyết định bắt đầu thử nghiệm, xây dần, hay chuyển hẳn sang một mô hình usage-based hoặc outcome-based pricing, hãy luôn dừng lại một nhịp để nghĩ về một, hai, thậm chí bốn quý tới, về dải thay đổi có thể tác động tới team của bạn, và về cách bạn build. Như vậy bạn bỏ ra một chút thời gian từ đầu để build nó theo cách linh hoạt, giúp bạn nhanh nhẹn và thật sự bám sát (theo Chris, video đăng ngày 25/08/2025).

18. Đường cong midwit và câu chuyện trước IPO

Chris nói nó giống một đường cong, như meme midwit. Ở đầu này: đừng build gì cho billing cả, có phần mềm làm việc đó rồi. Ở giữa: bạn biết việc kinh doanh của mình là gì, hãy tự build, vì bạn sở hữu nó và muốn làm gì với nó cũng được. Rồi ở đầu kia: không, có phần mềm làm việc này tốt hơn và hiệu quả hơn bạn, nên đã có phần mềm cho việc đó rồi (theo Chris, video đăng ngày 25/08/2025).

James nói nó gần như là chuyện quy mô. Ở giai đoạn đầu, kiểu "do things that don't scale", bạn sẽ build bất cứ thứ gì build được để đưa sản phẩm ra cửa, và phải làm nhanh; điều đó không nhất thiết là đi chi $50.000 cho một hệ thống CPQ (theo James, video đăng ngày 25/08/2025). Ở giữa, đúng như Chris nói, là: chúng ta cần khởi động, cần dựng một cái gì đó, cần tinh gọn việc này; chúng ta có người giỏi, hãy cùng làm. Và ở trên cùng là: chúng ta cần audit được cho hai năm tới vì đang ở giai đoạn trước IPO, đã tới lúc phải sắp xếp mọi thứ cho đàng hoàng. Bạn không làm việc đó bằng một hệ thống tự chế được.

Chris chen vào: bạn đâu muốn ngồi xem cái Google Sheet của anh, nơi ghi tất cả các quote và duyệt chúng (video đăng ngày 25/08/2025).

James đáp "Yeah, yeah" và kể một chuyện: hồi trước anh tư vấn cho một khách hàng, và khách nói: chúng tôi còn sáu tháng nữa là lên kế hoạch IPO, chúng tôi cần có hai năm dữ liệu được ghi lại, audit được, đủ cả. Vậy các anh có thể tải hai năm dữ liệu đó vào hệ thống của chúng tôi không? Nhóm của James trả lời: được, bao nhiêu vậy? Và khách đáp: "ồ, chỉ khoảng…" (theo video đăng ngày 25/08/2025).