# Monetization cho AI và usage-based billing cùng Arnon Shimoni (Solvimon)

[Paul David](https://homus.dev/speakers/paul-david) · [Literal Humans](https://homus.dev/orgs/literal-humans), [Arnon Shimoni](https://homus.dev/speakers/arnon-shimoni) · [Literal Humans](https://homus.dev/orgs/literal-humans)

> Vì sao seat nhường chỗ cho usage-based, bẫy của token và credit, tính tiền agent theo outcome, nỗi lo của CFO, và invoice như một touch point.

Topics: AI Pricing, Agents, Startups

Canonical: https://homus.dev/talks/revolutionising-ai-monetisation-and-usage-based-billing-with-arnon-shimoni-vp-of-growth-at-solvimon

## 1. Mở đầu: một ly cà phê ở Amsterdam và gian hàng "tiền bay"

Đây là một tập của podcast Tech Can't Save Us do Literal Humans thực hiện. Host là Paul David, founder và CEO của Literal Humans; khách mời là Arnon Shimoni, VP of Growth tại Solvimon, một nền tảng billing và monetization có trụ sở ở Hà Lan (vai trò và mô tả công ty theo phần mô tả của video đăng ngày 09/07/2026).

![Arnon Shimoni (bên trái, áo len nâu) và Paul David (bên phải, áo len sáng màu) ngồi trước tấm phông xanh đậm](https://homus.dev/photos/bkV9yBnlPUs-0003.jpg)

Đầu tập podcast: Arnon (bên trái, áo len nâu) và Paul (bên phải, áo len sáng màu, đeo kính) ngồi cạnh nhau trước tấm phông xanh đậm, hai bên có cây lá.

Paul chào khán giả và giới thiệu Arnon. Arnon cảm ơn và nói rất vui được có mặt. Paul kể hai người gặp nhau ở Amsterdam vài tuần trước, uống một ly cà phê ở Soho House, và anh đã "tuyển" Arnon làm khách mời vì Arnon có nhiều điều hay để nói. Lúc đó Paul nghĩ: phải đặt một cái máy quay trước mặt anh chàng này mới được. Arnon đáp rằng anh rất vui được lên hình (video đăng ngày 09/07/2026).

Chủ đề của tập là cách làm mới monetization cho AI và billing theo mức sử dụng (usage-based billing). Paul giới thiệu Solvimon là một nền tảng billing và monetization thế hệ mới, được thiết kế để giúp các công ty SaaS hiện đại xử lý sự phức tạp của usage-based pricing và các mô hình kinh doanh lai (hybrid), "trong số nhiều thứ khác" (theo lời Paul trong video đăng ngày 09/07/2026). Có tiếng xen vào rằng đó là một mảng kinh doanh lớn. Paul nói podcast chưa bàn nhiều về usage-based pricing, nên lần này có thể đào sâu.

Paul giới thiệu Arnon là một người lâu năm trong marketing và go-to-market, và anh rất hào hứng vì có thêm một người cùng làm GTM lâu năm như mình. Theo Paul, Arnon đã góp tay xây dựng từ đầu mảng monetization cho AI agent. Có tiếng xen vào: "Talk about that." Với hơn mười năm kinh nghiệm trong product management và marketing B2B, Arnon đứng sau chiến lược doanh thu và thanh toán của "vài công ty nhỏ mà bạn có thể đã nghe tên", như Paid, Storytel và Pleo (lời giới thiệu của Paul, video đăng ngày 09/07/2026).

Paul kể một trong những kỷ niệm anh thích về Pleo: ở một hội nghị, Pleo dựng một gian hàng có tiền bay vòng vòng bên trong. Arnon xác nhận gian hàng đó rất hay. Paul nói anh đã nghĩ "mấy người này là thiên tài", vì có rất nhiều người bước vào gian hàng, chụp lấy tiền, rồi gửi video cho mọi người họ quen; anh nghĩ chính anh cũng đã đăng nó lên LinkedIn. Anh khen một màn làm rất tốt, và có lời khen thêm rằng đó là một chiến lược rất hay. Arnon nói thật ra không phải anh làm. Paul đáp: "Thì đó là team của anh mà." Rồi Paul vào câu hỏi đầu tiên (video đăng ngày 09/07/2026).

## 2. Từ license mua đứt tới seat, rồi tới usage-based: một chiến lược tăng trưởng

Paul nói podcast thường mời khách vẽ ra bức tranh của lĩnh vực họ đang làm. Anh hỏi Arnon về sự chuyển dịch sang usage-based billing: vì sao nó gây xáo trộn lớn như vậy cho SaaS truyền thống?

Arnon bắt đầu từ quá khứ. Trước đây, người ta mua phần mềm kiểu Microsoft Word: bạn có nó trên máy tính, bạn chạy nó, thế là xong. Khi phần mềm bắt đầu được giao qua Internet, việc mua một license vĩnh viễn không còn hợp lý nữa. Thế là bạn mua một seat, và đó là kiểu SaaS bình thường (video đăng ngày 09/07/2026).

![Arnon vừa nói vừa đưa tay ra, Paul ngồi nghe](https://homus.dev/photos/bkV9yBnlPUs-0203.jpg)

Arnon trả lời câu hỏi đầu tiên về usage-based billing, tay đưa ra trước khi giải thích; Paul ngồi nghe ở bên phải.

Theo Arnon, mô hình seat đã tạo ra biên lợi nhuận rất tốt cho rất nhiều công ty, vì phần mềm khá khó xây. Bạn sẽ mất rất nhiều thời gian để xây nó. Ngày nay nhiều người nói "ồ, nó chỉ là một lớp nằm trên database". Cũng được, anh nói, nhưng hồi đó nó vẫn thật sự khó xây. Nên mô hình theo seat trở thành chuẩn: bạn mua một chỗ ngồi ở bàn, một chỗ ngồi trong sản phẩm, và phần lớn sản phẩm vẫn vận hành như vậy cho đại đa số trường hợp (theo Arnon, video đăng ngày 09/07/2026).

Với nhiều người, nó lại giống một sự lãng phí: sao tôi phải trả cho một seat nếu tôi không dùng nó? Vì vậy, để cố lấy thêm chút tiền từ đó, nhiều công ty chuyển sang usage-based: bạn chỉ trả cho những gì bạn dùng. Nghe thì công bằng, ít nhất là trên lý thuyết. Arnon cho rằng nó có nhiều giới hạn, và có nhiều công ty đã làm nó rất sai; hai người sẽ bàn chuyện đó sau (theo Arnon, video đăng ngày 09/07/2026).

Nhưng theo anh, sự chuyển dịch này về cơ bản là để kiếm thêm tiền. Đó là một chiến lược tăng trưởng cơ bản: làm sao để doanh thu tiếp tục tăng khi công ty khách hàng không tuyển thêm được bao nhiêu người nữa? Phía khách hàng nghĩ: tôi không muốn mua seat cho họ. Thế là bên bán muốn lấy tiền theo một cách khác: tính tiền theo mức sử dụng (theo Arnon, video đăng ngày 09/07/2026).

Paul hỏi lại: vậy anh đang nói chuyển sang usage-based có thể là một chiến lược tăng trưởng? Arnon khẳng định: nó là một chiến lược tăng trưởng. Paul nói anh muốn hiểu rõ hơn, vì là một doanh nghiệp dùng những nền tảng như vậy, anh có cảm giác "ồ, mình có seat này mà không thật sự dùng", nên có vẻ như mình đang dùng ít đi (video đăng ngày 09/07/2026).

## 3. Ví dụ Figma và cái bẫy khiến người dùng ngại dùng sản phẩm

Arnon lấy ví dụ Figma, một công cụ để thiết kế. Bạn có thể cấp cho người ta một seat: tuyển ai đó, đưa cho họ một seat và để họ dùng. Nhưng nhiều người không thật sự cần. Họ chỉ xem, hoặc muốn thêm một comment. Thế là bạn phải bắt đầu phân biệt các loại seat, chuyện đó trở nên phức tạp, rồi phải nâng cấp, hạ cấp seat (theo Arnon, video đăng ngày 09/07/2026).

Vậy sao không tính tiền theo những gì bạn dùng? Ví dụ khi bạn tạo một artboard mới, bên bán có thể giới hạn số frame, số nhóm (grouping) hay bất cứ thứ gì bạn làm. Đó là chỗ usage-based xuất hiện: người dùng nghiêm túc hơn thì trả nhiều hơn, còn người chỉ thử chơi thì không phải trả nhiều. Nghe hợp lý (theo Arnon, video đăng ngày 09/07/2026).

Nhưng anh cho rằng trong đó có một cái bẫy rất nguy hiểm: nó có xu hướng tạo ra động cơ ngược, khiến bạn ngại dùng sản phẩm. Paul thốt lên: "Thú vị đấy." Arnon giải thích: nếu bạn nghĩ mỗi lần tạo một frame mới là phải trả tiền, bạn sẽ "hack" và dùng sản phẩm sai cách. Bạn sẽ nhồi mọi thứ vào một frame, hoặc để mọi thứ trong một file thay vì tách ra (theo Arnon, video đăng ngày 09/07/2026).

Cái bẫy Arnon mô tả với ví dụ Figma (video đăng ngày 09/07/2026): khi mỗi frame mới tốn tiền, người dùng "hack" sản phẩm thay vì dùng nó như nhà làm sản phẩm muốn.

Paul hỏi: anh có thấy điều đó giới hạn người dùng, hay làm thay đổi cách người ta dùng sản phẩm không? Arnon nói là có cả hai. Theo anh, bạn phải rất khéo khi thiết kế các bước nâng cấp từ đó. Nếu anh chỉ là người dùng thỉnh thoảng, đúng là anh có thể hack sản phẩm và dùng nó theo cách không đúng ý định, để lách các chiến lược tăng trưởng và monetization này. Nhưng nếu anh ở trong một công ty lớn và không thật sự để tâm, thì anh cứ dùng thôi. Và anh nghĩ đó là điều mà nhiều công ty như Figma, HubSpot và rất nhiều công ty khác đang đặt cược: rằng bạn sẽ không bận tâm nghĩ "mình có đang dùng hay không" (theo Arnon, video đăng ngày 09/07/2026).

Paul nói thật thú vị khi Arnon nhắc tới Figma, vì đó đúng là công cụ team anh dùng để thiết kế, và có lẽ team anh đang có nhiều seat hơn cần (theo lời Paul, video đăng ngày 09/07/2026). Tháng nào anh cũng nhận hóa đơn Figma, nhìn số seat, rồi gửi cho chief of staff và senior designer của mình: "Các bạn ơi, chuyện gì đang xảy ra vậy? Mình có cần trả nhiều như vậy cho seat của tôi chỉ để thỉnh thoảng xem công việc đang làm không?" Anh nói anh rất thích ví dụ này.

## 4. Free plan của Pleo: thêm một user, hóa đơn nhảy vọt

Arnon nói đó chính là vấn đề: cái kiểu usage-based này phải được thiết kế đúng. Và không chỉ usage-based, mô hình seat cũng phải được thiết kế đúng. Anh đã tận mắt thấy chuyện gì xảy ra khi thiết kế sai (theo Arnon, video đăng ngày 09/07/2026).

Ví dụ từ Pleo: anh và đồng nghiệp ở Pleo ra mắt một free plan, giới hạn tối đa năm user. Nếu bạn có tới năm user, bạn dùng free plan, không phải trả gì. Giá trị khá tốt. Nhưng khi muốn thêm người thứ sáu, không có đường nâng cấp nào khác ngoài việc chuyển sang gói Pro. Và gói Pro có giá 10 euro hoặc 10 bảng mỗi user. Thế là bạn đột nhiên đi từ không đồng lên trả 60, chỉ vì thêm một user (câu chuyện của Arnon về Pleo, video đăng ngày 09/07/2026).

Bậc thang Arnon kể về free plan của Pleo (video đăng ngày 09/07/2026): không có đường nâng cấp trung gian, nên user thứ sáu kéo cả hóa đơn từ 0 lên 60.

Theo Arnon, trong đầu người ta không còn là "à, mỗi user 10 euro". Mà là "việc tôi thêm một user giờ tốn 60 euro". Nên giá trị không còn ở đó, giá trị không khớp với cái giá. Anh coi đó là ví dụ về một thiết kế không tốt lắm, và anh đã đấu tranh rất nhiều để thay đổi nó (video đăng ngày 09/07/2026).

Paul nói thú vị. Anh bảo sẽ dần chuyển sang công việc ở Solvimon, nhưng vẫn muốn ở lại thêm với phần vẽ bức tranh chung.

## 5. Pricing không cần đơn giản, nhưng phải minh bạch; Solvimon ra đời từ Adyen

Paul đặt hai câu hỏi về bối cảnh. Thứ nhất, kiến trúc của Solvimon phản ánh thế nào nhu cầu "revenue stack" ngày càng phức tạp của nhiều công ty, khi họ hoạt động ở giao điểm giữa độ chính xác cấp ngân hàng và sự linh hoạt của SaaS B2B (cách Paul mô tả, video đăng ngày 09/07/2026). Thứ hai, làm sao giúp các công ty bắc cầu giữa dữ liệu usage phức tạp và một invoice mà họ mong là đơn giản, minh bạch cho khách hàng cuối.

Arnon khen câu hỏi hay và có rất nhiều ý. Anh bắt đầu từ cuối, vì Paul nói invoice nên đơn giản và minh bạch. Anh kể có một từ đang xuất hiện rất nhiều vào lúc đó: "clarity". Anh nói anh rất ghét từ này, vì cứ thấy nó mãi (theo Arnon, video đăng ngày 09/07/2026).

Theo anh, pricing không cần đơn giản. Pricing phức tạp, nhiều lớp, nhiều khía cạnh là chuyện bình thường. Anh nghĩ đó chính là điều làm nó tốt, vì đó là cách để tăng trưởng; anh nói lại rằng anh đang nghĩ từ góc nhìn doanh nghiệp. Nhưng người dùng, người mua từ bạn, phải hiểu nó vận hành ra sao. Bạn phải minh bạch về cách mình làm, và phản ánh điều đó trong thứ bạn gửi cho họ cuối mỗi tháng, tức invoice (theo Arnon, video đăng ngày 09/07/2026).

Anh nói pricing không cần đơn giản, vì "đơn giản" thường ngụ ý kiểu "ồ, tôi sẽ làm ba gói good, better, best". Ai cũng làm thế, và nó ổn trong một thời gian, đưa bạn tới một mức nào đó, nhưng phần lớn công ty nhận ra rằng họ phải "tốt nghiệp" khỏi nó. Và theo Arnon, đó là chỗ Solvimon hoạt động (video đăng ngày 09/07/2026).

Anh kể Solvimon ban đầu được tạo ra bởi hai người, hai co-founder, đến từ Adyen. Họ đã xây một hệ thống billing tài chính cho Adyen, bên trong Adyen. Nên nó giống một spin-off. Paul nhận xét: lúc nào cũng là "cái mảnh bên trong cái mảnh" trở thành thứ đó. Arnon đồng ý (theo Arnon, video đăng ngày 09/07/2026).

So sánh Arnon đưa ra (video đăng ngày 09/07/2026): cách ngân hàng và fintech tính tiền bên trong phức tạp hơn nhiều so với các công cụ SaaS quen thuộc.

Arnon giải thích: cách ngân hàng và fintech vận hành bên trong phức tạp hơn Figma, Miro hay HubSpot rất nhiều. Có đủ thứ: bạn trả bấy nhiêu phần trăm ở chỗ này, chỗ kia; rồi có cap, có graduated levels, stair-step và sticky stair-step. Có cả đống kiểu pricing rất kỳ lạ mà phần lớn người ta chưa từng nghe. Nhưng đó là cách nhiều fintech vận hành và kiếm tiền (theo Arnon, video đăng ngày 09/07/2026).

Nên Solvimon về cơ bản là một spin-off để xử lý sự phức tạp đó, vì nhiều công ty cần nó. Anh sửa lại: hãy gọi là flexibility, không phải complexity. Các công ty muốn có sự linh hoạt để thử nhiều đòn bẩy và yếu tố khác nhau, và theo anh, điều đó rất khó làm với Stripe hoặc với các thành phần dựng sẵn (off-the-shelf) khác (theo Arnon, video đăng ngày 09/07/2026).

## 6. Sai lầm của nhiều startup AI: dựa quá nhiều vào token và credit

Paul chuyển sang phần sản phẩm: các công ty AI-native thiết kế monetization thế nào để không bóp nghẹt tăng trưởng. Anh nói Solvimon chuyên thiết kế chiến lược monetization cá nhân hóa cho các công ty AI, rồi hỏi: những sai lầm lớn nhất anh thấy khi startup lần đầu rời bỏ mức phí cố định (flat fee) hoặc subscription theo seat là gì? (video đăng ngày 09/07/2026).

Arnon nói sai lầm thứ nhất là dựa rất, rất nhiều vào usage-based. Paul hỏi dựa quá nhiều vào usage-based trông như thế nào. Arnon giải thích: nhiều công ty bắt đầu tạo ra các "proxy" cho đầu vào, tức credit và token (theo Arnon, video đăng ngày 09/07/2026). Paul chen vào: ai cũng mê token. Arnon nói thêm: rồi người ta quen dần với nó. Paul hỏi: token là gì cơ chứ? Arnon: "Chính xác, vấn đề là ở đó."

Theo Arnon, đó là rất nhiều lớp che mờ (obfuscation). Anh đưa ví dụ: bạn trả, chẳng hạn, 10 cent cho mỗi triệu input token và có thể 8 cent cho mỗi triệu output token. Trong đầu anh không có cách nào quy đổi những con số đó. Rồi những token đó lại được trả qua credit: bạn mua trước credit để "đốt" dần token theo thời gian (ví dụ của Arnon, video đăng ngày 09/07/2026).

Chuỗi Arnon mô tả (video đăng ngày 09/07/2026): người mua trả qua credit, credit đổi ra token, token là proxy cho compute; theo anh, người mua đang trả chi phí của bên bán chứ không trả cho giá trị.

Arnon nói cách đó tốt cho công ty bán, vì họ đã tách giá trị của thứ bạn mua ra khỏi chi phí. Nhưng nó trở nên quá phức tạp để hiểu. Và thế là không còn cái gọi là "clarity" hay sự minh bạch trong thứ bạn mua (theo Arnon, video đăng ngày 09/07/2026).

Theo anh, đó là usage-based nặng, nhưng là usage tính trên đầu vào, trên thứ thực chất là proxy cho compute. Bạn đang trả chi phí của bên bán. Bạn không trả cho thứ bạn nhận được, không trả cho giá trị. Bạn đang trả hóa đơn OpenAI của họ, hoặc chi phí GPU inference nếu họ tự chạy. Anh cho rằng đó là một cách tiếp cận rất sai (theo Arnon, video đăng ngày 09/07/2026).

Anh so sánh: nó giống như đi nhà hàng mà phải trả tiền cho từng loại gia vị trong món ăn. Anh không muốn thế; hãy giấu chuyện đó đi. Anh mua một món ăn. Anh mua nó vì anh muốn cảm thấy điều gì đó, muốn nó đặc biệt. Anh không quan tâm từng hạt gạo trong món đó tốn bao nhiêu (video đăng ngày 09/07/2026).

Paul nói ở đây cũng có sự giằng co, vì các công ty luôn tìm cách tối ưu, vắt thêm từ cách họ định giá, value-based pricing và những thứ tương tự. Có tiếng nói tiếp: "Big believer in value-based pricing." Paul nói "chắc chắn rồi", rồi kể team anh đang làm một việc rất thú vị với một công ty health tech: ở đó có khoản hoàn 27 đô la từ Medicaid, và rất thú vị khi đào vào câu hỏi: bạn đang mang lại gì, và nếu team Paul mang tới cho bạn nhiều người đủ điều kiện Medicaid hơn thì sao (ví dụ của Paul, video đăng ngày 09/07/2026). Có tiếng nói: đó là "holy grail", thật tuyệt.

Paul nói giúp founder suy nghĩ theo hướng đó là một trong những phần anh thích trong công việc. Khi họ bắt đầu nghĩ về toàn bộ mô hình doanh thu của mình và mở khóa được nó, điều đó giúp họ scale. Và theo anh, việc đó vượt ra ngoài những gì team anh mang lại với vai trò người làm chiến lược GTM và marketer (video đăng ngày 09/07/2026).

## 7. Đổi giá mà không làm hỏng: grandfathering, entitlement, front of house và back of house

Paul nói muốn đào sâu vào chuyện người dùng cuối và giá trị họ nhận được. Câu hỏi là Solvimon giúp các công ty đổi giá, hoặc ra mắt tính năng mới cho một số khách hàng, mà không vô tình làm hỏng mọi thứ cho những người còn lại như thế nào. Anh nói đó có vẻ là một đường dây rất căng. Arnon đáp: "Câu này khó." (video đăng ngày 09/07/2026).

Theo Arnon, điều nhiều công ty làm là ra mắt bảng giá mới rồi chuyển tất cả mọi người sang trong một lần (video đăng ngày 09/07/2026). Paul nói thêm rằng nếu anh có chuyện kinh dị nào thì cứ kể. Arnon nói anh không muốn đi vào các câu chuyện kinh dị cụ thể, vì chúng quá kỹ thuật và anh thật ra không nghĩ chúng thú vị lắm.

Anh giải thích khái niệm grandfathering: bạn được "giữ" ở một gói cũ. Các công ty điện thoại làm việc này suốt. Theo anh, nó tạo ra rất nhiều phức tạp, vì khi muốn chuyển sang gói tiếp theo, đôi khi không có đường nào cả. Trong hệ thống bạn dùng để chạy billing và mọi thứ, bạn phải tạo một quy trình: chuyển từ gói này sang gói kia nghĩa là gì (theo Arnon, video đăng ngày 09/07/2026).

Lý do phải làm vậy là vì nó không chỉ là "à, tôi chuyển từ good lên better". Bạn đang chuyển từ "tôi được chừng này phút" sang "chừng kia phút". Bỗng nhiên tôi đang dùng 4G, giờ tôi được 5G. Arnon gọi đó là entitlement: bạn bỗng có quyền dùng thứ mới. Nên con đường nâng cấp đó phải được định nghĩa ở đâu đó (video đăng ngày 09/07/2026).

Nhiều công ty làm việc đó thủ công, theo Arnon (video đăng ngày 09/07/2026). Họ viết nó vào code: nếu nâng cấp từ cái này sang cái kia thì chuyện này xảy ra. Họ code nó vào các trang pricing, và đó là một khía cạnh, "front of house". Rồi còn "back of house": chuyện gì đang diễn ra trong hệ thống billing.

Những chỗ một lần nâng cấp gói phải chạm tới, theo cách Arnon liệt kê (video đăng ngày 09/07/2026).

Theo Arnon, đôi khi bạn phải cập nhật nó trong CRM để biết khách đang nâng cấp và họ nhận được gì. Đôi khi bạn phải tạo một quote cho khách ký, vì đó là giá đặc biệt một nhân viên sales đã thỏa thuận. Đôi khi nó là product-led, khách tự vào và tự làm. Rồi bạn còn phải ghi lại tất cả trong một ERP, vì bạn đang tạo ra các khoản liabilities khác nhau gắn với doanh thu. Anh gọi chuyện đó là điên rồ, là thứ phần lớn mọi người không nghĩ tới, và chính anh cũng không muốn nghĩ tới; anh thật sự ghét nó (video đăng ngày 09/07/2026).

Anh nhắc tới những chi tiết bookkeeping nhỏ nhặt tận cùng, và nói đó là thứ rất chán, phần anh ít thích làm nhất. Nhưng bạn phải nghĩ về cả stack đó, từng mảnh của câu đố. Theo anh, phần lớn công ty sẽ lo một hoặc hai bước và quên phần còn lại (theo Arnon, video đăng ngày 09/07/2026).

## 8. Compliance: cách làm của Mỹ, cách làm của châu Âu

Arnon nói quên phần còn lại vẫn ổn khi bạn là công ty nhỏ đang tăng trưởng, vì bạn chưa thật sự phải tuân thủ (compliant) điều gì. Một công ty lớn không có sự xa xỉ đó: họ bị kiểm toán thường xuyên và phải compliant. Theo anh, xử lý cả stack đó là việc Solvimon làm, và đó là kế hoạch từ ngày đầu (video đăng ngày 09/07/2026).

Anh nói có thể bàn xem đó có phải cách tiếp cận đúng khi xây một công ty hay không, vì như hai người đã nói khi gặp ở Amsterdam, có một "cách của Mỹ": cứ xây, không cần compliant, khi nào phải xử lý thì xử lý. Paul chen vào: cứ thế lướt qua. Còn cách của châu Âu thì giống "hãy xây một thứ compliant 100% rồi mới đưa ra thị trường". Arnon nghĩ điều đó có thể là một vấn đề, và hẹn bàn ở câu hỏi sau (theo Arnon, video đăng ngày 09/07/2026).

Hai cách xây công ty Arnon đặt cạnh nhau khi nói về compliance (video đăng ngày 09/07/2026).

Quay lại câu hỏi của Paul, Arnon nói: cả dòng chảy từ lúc ai đó nghĩ "có lẽ mình muốn nâng cấp, muốn xem gói tiếp theo là gì", tới "lên gói thật sự tốn bao nhiêu, mà không chỉ chi phí, liệu mình có làm được không", theo anh là thứ nhiều công ty chưa giải quyết tốt. Solvimon xử lý nó từ đầu tới cuối trong một nền tảng. Anh nói Solvimon không phải bên duy nhất làm vậy, nhưng chắc chắn là một trong số rất ít (theo Arnon, video đăng ngày 09/07/2026).

Paul nhắc lại chuyện khác biệt văn hóa. Anh kể hai người đã gặp vài công ty khác ở Amsterdam làm climate tech, và họ rất thận trọng, cẩn thận, nhưng cũng có kế hoạch và có chủ đích trong việc xây quanh, xây cho những "regulatory moat" đang hình thành, đặc biệt ở các mảng như dệt may bền vững và tối ưu tòa nhà. Họ đưa chuyện đó vào mô hình kinh doanh: "chúng tôi có thể giúp tất cả các doanh nghiệp này làm compliance và được trả tiền cho việc đó, bằng cách giao sản phẩm theo cách giảm rủi ro cho việc kinh doanh của họ, vì chúng tôi trở thành lựa chọn ít rủi ro nhất để họ giữ compliant" (theo lời kể của Paul, video đăng ngày 09/07/2026).

Paul thấy chuyện đó rất thú vị, và theo anh đó là một cách nghĩ rất khác so với phần lớn những gì anh thấy ở Mỹ. Anh khen Arnon nêu một ý rất hay (video đăng ngày 09/07/2026).

## 9. "Holy grail": tính tiền theo outcome, từ AI SDR tới agent xử lý hồ sơ vay mua nhà

Paul nói muốn đào vào cách Solvimon định vị mình. Anh hỏi: Solvimon xử lý những yêu cầu billing đặc thù của các agent tự hành (autonomous agent) như thế nào? Theo Paul, khán giả của podcast muốn hiểu làm sao sắp xếp tất cả các mảnh đó lại với nhau cho chạy được (video đăng ngày 09/07/2026).

Arnon bắt đầu từ "holy grail": bạn định giá theo outcome. Anh nói đã nói nhiều về chuyện này từ năm ngoái. Anh chỉ muốn trả tiền cho những việc agent làm cho anh mà cuối cùng có giá trị (theo Arnon, video đăng ngày 09/07/2026).

![Arnon giơ tay giải thích, Paul ngồi nghe](https://homus.dev/photos/bkV9yBnlPUs-1723.jpg)

Arnon giơ tay khi kể ví dụ về agent xử lý hồ sơ vay mua nhà (video đăng ngày 09/07/2026); Paul ngồi nghe ở bên phải.

Paul xin một ví dụ. Arnon nói về một sales agent, kiểu AI SDR, mà theo anh tới lúc đó có lẽ đã có khoảng 60 sản phẩm như vậy (video đăng ngày 09/07/2026). Nó có thể nói: "Tôi đã lục khắp Internet và tìm được 70 lead cho bạn." Anh không muốn trả tiền cho 70 lead. Anh không biết con số đó nghĩa là gì, không biết lead tốt hay không. Bước tiếp theo là "để tôi chấm điểm chúng cho bạn". Được, nhưng đó vẫn là một kiểu đầu vào.

Nhưng nếu agent đặt được một cuộc gặp cho anh, thì một cuộc gặp có giá trị hơn nhiều so với "đây là danh sách 70 lead". Và nếu cuộc gặp đó tốt, anh có thể bảo agent: "Này, cuộc gặp này thật sự tốt, hãy học từ nó. Tôi sẵn sàng trả nhiều hơn cho kiểu cuộc gặp này so với kiểu kia." Đó là một ví dụ (theo Arnon, video đăng ngày 09/07/2026).

Ví dụ AI SDR của Arnon (video đăng ngày 09/07/2026): càng gần kết quả thật, thứ agent giao càng đáng để trả tiền.

Ví dụ thứ hai là một công ty anh từng làm việc cùng khi còn ở Paid năm ngoái. Một người ở Florida, theo Arnon, đã thay đổi hoàn toàn cách các ngân hàng xử lý khoản vay mua nhà (mortgage). Người đó xây một agent xử lý hồ sơ vay, và đáng tiếc là đã thực sự thay thế một số người trong ngân hàng. Arnon nói những người đó không bị sa thải, họ đang làm việc khác. Nhưng thay vì mất rất nhiều giờ, đôi khi nhiều ngày, để xử lý một hồ sơ, giờ người đó làm xong trong vài phút bằng một agent (câu chuyện của Arnon, video đăng ngày 09/07/2026).

Paul bắt đầu hỏi về những nhân viên ngân hàng đó. Arnon xác nhận agent đang làm việc cho ngân hàng. Theo anh, thay vì, anh không rõ lắm, 17 người, giờ có hai người làm mảng mortgage, và những người còn lại có thể đi làm việc khác (video đăng ngày 09/07/2026).

Giá trị ở đây, theo Arnon, là agent được trả tiền cho mỗi hồ sơ vay thành công. Ngân hàng kiếm tiền từ khoản vay, và người xây agent lấy một phần từ đó (video đăng ngày 09/07/2026). Paul nói thêm: thay vì được trả tiền chỉ để xáo giấy tờ và xử lý một hồ sơ có thể không bao giờ được duyệt. Arnon nhấn lại: người đó chỉ được trả tiền cho những hồ sơ vay thành công. Paul nói: vậy là có động lực để làm nhiều hơn, và làm thật đúng. Arnon: "Chính xác."

Ví dụ mortgage Arnon kể (video đăng ngày 09/07/2026): tiền chỉ chảy về người xây agent khi một hồ sơ vay thành công.

Arnon nói khi nghĩ về điều đó, nó tạo ra một động lực chung (shared incentive): bên bán phần mềm muốn phần mềm tốt hơn, agent tốt hơn và cải thiện theo thời gian; còn ngân hàng, hay người mua nói chung, có một động lực chung để làm tốt hơn. Trong khi với phần mềm SaaS cổ điển, bạn mua một phần mềm không nhất thiết thay đổi nhiều theo thời gian (theo Arnon, video đăng ngày 09/07/2026).

## 10. Moral hazard, deal desk và những hợp đồng nằm ngoài khuôn

Paul hỏi: có rủi ro đạo đức (moral hazard) nào không, kiểu "nắn" số liệu để giúp hồ sơ được duyệt? Arnon nói có, tất nhiên. Nhưng chuyện đó lúc nào cũng có, đó là trường hợp khi bạn trả hoa hồng cho sales. Paul đáp "chắc chắn rồi". Arnon nói anh cũng đã thấy chuyện đó xảy ra: có thể đó không phải thương vụ tốt nhất, có lẽ nó không nên được chốt, nhưng nó đã chốt, và nhân viên sales nhận phần của mình. Điều đó không có nghĩa đó là thương vụ đúng vào thời điểm đúng (theo Arnon, video đăng ngày 09/07/2026).

Anh nói thêm, như một đoạn rẽ nhỏ: điều anh đang thấy lúc đó là các deal desk đang gặp rất nhiều khó khăn với những nhân viên sales được tự do chốt bất kỳ thương vụ nào với bất kỳ điều kiện nào. Và đó là một việc khác Solvimon đang bắt đầu xử lý: cho sự linh hoạt để chốt những thương vụ vượt ra ngoài phạm vi bình thường mà công ty định ra từ đầu (theo Arnon, video đăng ngày 09/07/2026).

Lý do, theo anh, là đó rốt cuộc là những thương vụ có giá trị. Kiểu: "Đúng, khi thiết kế pricing, mình không nghĩ tới việc thương vụ này sẽ được cấu trúc ra sao, nhưng nhân viên sales này đã sáng tạo, chốt được một thương vụ rất tốt, có lãi. Hãy làm cho nó chạy được. Hãy bảo đảm hệ thống hỗ trợ nó, và mình không phải hack nó vào." Arnon nói đó là cách anh đang nghĩ, và là cách anh và nhóm ở Solvimon đang xây sản phẩm vào lúc đó (video đăng ngày 09/07/2026).

Quay lại agent: nếu bạn coi agent là một thứ tự hành, làm việc giúp bạn, thì theo Arnon, đúng là bạn muốn trả tiền cho kết quả. Anh không muốn trả cho chuyện "tôi đã đốt 70.000 token để lục Internet tìm một thứ" không có giá trị gì với anh. Và quay lại câu hỏi trước đó, anh nói đó là rủi ro của usage-based pricing khi usage là proxy cho đầu vào chứ không phải cho thứ bạn nhận được. Anh nghĩ đó là sai lầm mà nhiều công ty đang mắc phải (video đăng ngày 09/07/2026).

Paul hỏi: anh có thấy sự chuyển dịch sang trả tiền theo outcome đang bắt đầu lan ra không, nó có giống một sự thay đổi văn hóa không? Arnon nói đó là một câu khó. Paul hỏi vì sao lại khó đến vậy (video đăng ngày 09/07/2026).

## 11. Vì sao outcome pricing khó: attribution, giá trị khác nhau, và người CFO

Arnon nói trong nhiều trường hợp rất khó quy công (attribution). Lấy lại ví dụ sales agent: agent có thể nói "tôi đã đặt cuộc gặp này", nhưng rồi một người khác nói "không, tôi đã đưa cho agent toàn bộ dữ liệu, tôi đã chọn lọc, tôi mới đáng được ghi công. Sao lại trả tiền cho cái đó? Tôi tự làm cũng được". Thế là attribution trở nên hơi mù mờ (theo Arnon, video đăng ngày 09/07/2026).

Paul gợi ý: có lẽ chia phần. Arnon nói nhưng rồi mỗi khách hàng lại có cảm nhận khác nhau về việc "cái này đáng giá bao nhiêu với tôi". Paul hỏi: nếu quy định rõ ra thì chẳng phải chuyện đó không còn quan trọng sao? Arnon trả lời nó vẫn cực kỳ mang tính cá nhân (video đăng ngày 09/07/2026).

Anh lấy ví dụ: nếu anh ở trong một ngành biên lợi nhuận rất thấp, agent đặt một cuộc gặp cho anh và anh có được một thương vụ 30 đô la từ đó, anh không muốn trả cùng mức cho một cuộc gặp đem lại thương vụ 70.000 đô la. Nên hai bên phải thỏa thuận một outcome đáng giá bao nhiêu. Theo anh, điều đó rất khó, vì nó thay đổi theo thời gian, thay đổi theo outcome thực sự được giao, và nó phải nằm trong một thỏa thuận. Viết thỏa thuận đó và bảo đảm nó nằm trong hệ thống xử lý nó, theo Arnon, hoàn toàn không đơn giản (ví dụ của Arnon, video đăng ngày 09/07/2026). Paul nói: "Nhiều việc lắm."

Ví dụ Arnon dùng (video đăng ngày 09/07/2026): cùng một outcome "đặt được cuộc gặp" nhưng giá trị với khách khác nhau rất xa, nên hai bên phải thỏa thuận outcome đáng giá bao nhiêu.

Arnon nói đó là một rủi ro. Nhưng còn có một lực quán tính: "Tôi, với tư cách CFO chẳng hạn, muốn trả một khoản cố định. Tôi không muốn sự linh hoạt mà tôi không biết mình sẽ trả bao nhiêu." Paul chen vào: chi phí biến đổi (variable costs) thì kiểu như vậy. Arnon nói anh mong những CFO nghĩ theo cách đó đang dần biến mất, vì usage-based là có thật và bạn không phải lúc nào cũng biết mình sẽ trả bao nhiêu. Nhưng anh cho rằng một CFO nói "tôi không muốn trả cho những outcome thành công giúp doanh nghiệp tôi tốt hơn và đem lại nhiều doanh thu hơn" là một cái nhìn rất thiển cận (theo Arnon, video đăng ngày 09/07/2026).

Paul đồng tình: bạn muốn chịu một chút thiệt lúc đầu với các chi phí có phần biến đổi, kiểm soát chúng trong giới hạn hợp lý, nhưng nhìn thấy cái lợi dài hạn. Arnon đồng ý, nhưng nói đồng thời nó làm cuộc sống của CFO khó hơn rất nhiều vì không có khả năng dự báo (forecasting). Theo anh, đó là ý anh muốn nói khi bảo cả revenue stack phải được xây với điều đó trong đầu (video đăng ngày 09/07/2026).

Paul nói vậy nó gần như là một lời giải kỹ thuật, giúp người CFO hiểu và cảm thấy kiểm soát được những chi phí biến đổi ngắn hạn. Arnon nói tiếp: vì bạn biết chuyện gì xảy ra cuối tháng, họ bị gọi lên gặp hội đồng quản trị: "Sao các con số lại chênh lệch dữ vậy? Anh không biết cách khóa sổ à? Anh không biết làm việc này à? Anh dự kiến chừng này, mình chỉ có chừng này, hoặc mình đã trả nhiều hơn chừng này. Anh đang làm gì vậy?" Và CFO phải trả lời cho chuyện đó, một vị trí rất khó. Nên anh không trách họ (video đăng ngày 09/07/2026).

Arnon nói cần làm tốt hơn với công cụ, cần cải thiện cả workflow của CFO. Theo anh, đó là một phần của sự thiển cận ở nhiều công cụ người ta mua cho billing, cho doanh thu, cho entitlement management, cho tăng trưởng trên website như các trang pricing: chúng không tính tới cả dòng chảy đó. Chúng chỉ giải quyết một phần nhỏ. Người mua là một người làm growth, một người làm product, hoặc CTO, và họ không nghĩ tới các hậu quả phía sau (downstream effects) (theo Arnon, video đăng ngày 09/07/2026).

## 12. Downstream effects: những hậu quả không ai đoán trước

Arnon kể đó là một trong những điều khó nhất anh học được khi bắt đầu xây các hệ thống này ở Pleo: có quá nhiều downstream effects mà bạn đơn giản là không thể đoán trước (video đăng ngày 09/07/2026).

Paul nhắc lại: không thể đoán trước. Rồi anh hỏi: vậy làm sao người ta nghĩ về chúng nếu không đoán trước được? Arnon nói bạn có thể nói về chúng, nhưng rồi người ta quên. Paul nói thêm: người ta rất thiển cận, trí nhớ ngắn, và không có mấy tầm nhìn xa (video đăng ngày 09/07/2026).

Rồi Paul chuyển sang chiến lược tăng trưởng, chủ đề anh nói cả hai đều muốn bàn: những rào cản và cơ hội phía trước cho Solvimon và team của Arnon trong năm 2026. Anh nói Solvimon định vị mình là nền tảng cho những công ty đã vượt quá billing đơn giản (theo lời Paul, video đăng ngày 09/07/2026). Anh hỏi: rào cản lớn nhất là làm cho các công ty nhận ra họ đã vượt quá hệ thống hiện tại, hay là rào cản kỹ thuật khi chuyển họ khỏi các hệ thống cũ, chẳng hạn Stripe?

## 13. Rào cản tăng trưởng: migration, Notion hay Obsidian, và vì sao Stripe là lựa chọn mặc định

Arnon nói migration lúc nào cũng là một nỗi khổ, nhưng đó là nỗi khổ với mọi thứ. Ví dụ bạn đang dùng Notion và nghĩ "tôi không muốn dùng Notion nữa, tôi muốn dùng Obsidian", thì đó vẫn là một cuộc migration (theo Arnon, video đăng ngày 09/07/2026).

Paul hỏi luôn: nhân tiện, anh có khuyên dùng Obsidian không? Arnon nói nó ổn, partner của anh rất thích nó, còn anh vẫn dùng Notion. Paul nói team anh cũng đang nghĩ về chuyện đó. Arnon nói anh vẫn là "team Notion", và hai người có thể nói về cả bộ công cụ công nghệ của anh. Paul nói "làm thế đi". Có tiếng nói rằng gửi một danh sách để chia sẻ sẽ là một phần thêm hay, và có tiếng đáp "chắc chắn rồi" (video đăng ngày 09/07/2026).

Theo Arnon, phần khó là sự hiểu biết. Nếu bạn đang xây một công ty mới vào lúc đó, anh không trách bạn khi chọn Stripe. Nó dễ nhất, và nó rất "đúng thời" (in the zeitgeist). Anh đưa ví dụ: nếu anh vào Cursor và bảo "thêm một trang billing", hay "tôi muốn nhận thẻ tín dụng", thì nó sẽ mặc định chọn Stripe. Paul đáp: tất nhiên rồi (theo Arnon, video đăng ngày 09/07/2026).

Arnon nói chuyện đó cũng ổn, anh không trách họ. Theo anh, sản phẩm của Solvimon có nhiều rào cản hơn. Nó không được thiết kế cho một người chỉ muốn nhận thẻ tín dụng và xử lý 30 subscription một tháng; nó không dành cho chuyện đó (theo Arnon, video đăng ngày 09/07/2026). Paul tóm lại: đó là phần việc phải làm trước, kiểu "bạn sẽ bỏ thêm chút thời gian và công sức bây giờ, nhưng lợi ích ở phía sau", giống điều Arnon nói về CFO và chi phí biến đổi.

Arnon nói nhưng bạn không xây cho quy mô lớn trước khi thấy được traction ban đầu. Sẽ thật ngớ ngẩn nếu anh đi triển khai Salesforce khi còn chưa chứng minh được mô hình kinh doanh. Nên anh sẽ dùng Pipedrive, Attio, hoặc có thể HubSpot. Theo anh, ngay cả HubSpot cũng đang hơi lớn so với vai trò của nó (video đăng ngày 09/07/2026).

Lập luận của Arnon về thời điểm migrate (video đăng ngày 09/07/2026): công cụ lớn đến khi cần, nhưng với revenue stack, câu hỏi "chuyển sang gì tiếp" thường không được đặt ra.

Đồng thời, anh hiểu rằng bạn có thể không muốn bắt đầu với nó. Và khi tới một giai đoạn cần tính năng đó, bạn migrate sang. Nhưng theo anh, với revenue stack, câu hỏi "tiếp theo mình chuyển sang cái gì" thường không nằm trong đầu ai, vì mọi thứ chưa đau. Nó bị coi như một vấn đề engineering. Bạn chỉ cần bảo lead engineer đã làm phần tích hợp ban đầu: "Tôi muốn thêm một trang pricing nữa", hay "tôi muốn đổi giá, làm giúp tôi". Và người đó sẽ làm trong Stripe dashboard hoặc sửa ít code cho nó chạy (theo Arnon, video đăng ngày 09/07/2026).

## 14. Khi nào thì đau: AI pricing, token và chuyện Stripe mua Metronome

Paul hỏi: vậy anh đang nói nó nên được coi là một vấn đề tăng trưởng, đó là sự chuyển dịch phải không? Arnon nói điều anh nghĩ là: tới lúc đó thì nó đã đau lắm rồi. Và bạn hoảng, vì áp lực từ trên xuống, từ hội đồng quản trị: "Chúng tôi muốn thấy bảng giá mới. Sao các anh không tách riêng AI pricing?" (theo Arnon, video đăng ngày 09/07/2026).

Theo Arnon, AI là một yếu tố kích hoạt rất rõ cho chuyện này, vì nhiều tính năng AI không nên được gộp vào subscription bình thường, do chúng tốn rất nhiều tiền. Rồi lựa chọn mặc định là "làm token và credit đi". Nhưng làm thế nào? Anh cho rằng Stripe không giỏi token và credit (video đăng ngày 09/07/2026).

Arnon nói Stripe vừa mua Metronome, và anh nghĩ đó là một chiến lược phòng thủ rất hay trước OpenAI. Anh nghĩ Stripe sợ OpenAI sẽ tự xây hệ thống billing riêng (nhận định của Arnon, video đăng ngày 09/07/2026). Paul nói: vậy là họ kiểu "chộp lấy nó". Arnon nói: thế là Stripe chộp nó từ tay OpenAI.

Chuỗi Arnon mô tả (video đăng ngày 09/07/2026): khi áp lực tới từ board và AI, billing trở thành một bài toán tăng trưởng doanh thu.

Nhưng rồi, theo Arnon, nó trở thành một vấn đề tăng trưởng, không phải tăng trưởng theo nghĩa marketing cổ điển, mà là tăng trưởng doanh thu. Bạn cần cho thấy kết quả, và lúc đó mới thật sự đau (video đăng ngày 09/07/2026).

## 15. Mở rộng theo khu vực: EU dễ, Mỹ khó vì thuế

Paul nói muốn bàn về dự định của Solvimon mở rộng ra ngoài EU, khi công ty đang tiến vào việc tự động hóa các quy trình billing và có trụ sở ở Hà Lan. Anh muốn hiểu phần quy định đã nhắc ở trước, những khó khăn tăng trưởng theo khu vực khi scale ở châu Âu so với ở Anh hay Mỹ, và cách các thị trường đó nghĩ về usage-based billing như một chuẩn. Anh hỏi về chiến lược tăng trưởng theo khu vực "sau vòng gọi vốn không còn mới lắm" của Solvimon (theo lời Paul, video đăng ngày 09/07/2026).

Arnon nói EU thật ra rất dễ làm việc, và anh nghĩ người ta không ghi nhận nó đủ. Có cái "one-stop shop". Paul hỏi: sao người ta không ghi nhận đủ? Arnon nói anh không biết. Có thể vì ngôn ngữ khác nhau, định dạng hơi khác nhau, nhưng ngoài ra thì trong EU, một invoice là một invoice. Nó khá được chuẩn hóa. Có cơ sở dữ liệu one-stop shop của EU để kiểm tra mã số VAT của các công ty khác. Nên nó chạy rất tốt, và bạn không phải làm nhiều để đi từ một nước EU sang tất cả các nước còn lại (theo Arnon, video đăng ngày 09/07/2026).

Paul nhận xét: theo một nghĩa nào đó, quy định thu hẹp sân chơi lại. Arnon nói đúng, nó khá dễ (video đăng ngày 09/07/2026).

So sánh của Arnon về hai thị trường (video đăng ngày 09/07/2026): trong EU, khác biệt chủ yếu là ngôn ngữ và định dạng; ở Mỹ, thuế là phần khó.

Theo Arnon, Solvimon được xây theo hướng toàn cầu ngay từ đầu, nên công ty có khách hàng ở Mỹ. Phục vụ khách ở Mỹ thật ra khó hơn nhiều vì tình hình thuế: nó phụ thuộc vào bạn bán gì, bán tới đâu, bạn đặt ở đâu, và bạn đã đạt "nexus" hay chưa; nó thực sự rất phức tạp. Vì vậy Solvimon hợp tác với các công ty như Avalara và Sphere để xử lý chuyện thuế. Anh nghĩ đó là phần khó nhất của bức tranh toàn cầu (video đăng ngày 09/07/2026).

Ngoài ra, Arnon nói Solvimon hợp tác với Adyen, một đối tác thanh toán rất tốt, lo cho công ty trên khắp thế giới, nên không có vấn đề gì. Solvimon cũng làm việc với Stripe: chỗ nào Adyen không phủ thì Stripe phủ, nên công ty có độ phủ đầy đủ (theo Arnon, video đăng ngày 09/07/2026).

## 16. Lạc quan về châu Âu: gu thẩm mỹ, nhân tài và chuyện thôi "dunking on Europe"

Về chuyện đi đâu tiếp, Arnon nói anh thật sự lạc quan (bullish) về Liên minh châu Âu và châu Âu nói chung. Có rất nhiều công ty thật sự "hot" ở châu Âu, và anh nghĩ họ đang được các công ty Mỹ như Stripe phục vụ chưa tới. Theo anh, Stripe Tax chưa thay đổi ít nhất từ năm 2022 và không thật sự tốt cho châu Âu. Nên bạn phải mang thêm một đối tác thứ ba vào, còn Solvimon thì lo việc đó từ ngày đầu, tích hợp sẵn trong hệ thống, bạn không phải mua thêm một hệ thống khác (nhận định của Arnon, video đăng ngày 09/07/2026).

Arnon nói anh thật sự lạc quan về việc hoạt động ở châu Âu. Anh nghĩ châu Âu có gu thẩm mỹ rất tốt: nhìn tất cả những thiết kế thú vị đến từ châu Âu, rồi thời trang, toàn là Pháp, Ý, một chút Anh. Có một cảm quan về phong cách và về gu ở đây mà anh nghĩ đang bị đánh giá thấp rất nhiều, và anh muốn dựa vào điều đó. Anh nói anh không chắc đó có phải một chiến lược tăng trưởng tốt không; đó chỉ là giả thuyết hiện tại của anh, và anh muốn xem nó diễn ra thế nào (video đăng ngày 09/07/2026).

Paul nói có lý do để hai người sống ở bên này, và anh cũng lạc quan về nó. Anh nghĩ châu Âu hay bị chê: về văn hóa thì "họ không đủ khát khao, không đủ đói", rồi "các vòng gọi vốn không đủ lớn". Arnon nói thật lòng thì anh hơi mệt với chuyện "dunking on Europe", cứ chê bai châu Âu (video đăng ngày 09/07/2026).

Paul đồng tình. Anh kể người ta hay hỏi anh: sao lại chuyển từ Mỹ sang London để khởi nghiệp? Và anh đáp: "Mọi người, nhìn quanh đi." Theo anh có rất nhiều tiềm năng, cả tiềm ẩn lẫn thực sự, ở đây. Anh không thích chuyện chê bai châu Âu, thấy nó hơi ngớ ngẩn. Anh nói phần lớn khách hàng của Literal Humans ở Mỹ, và anh hiểu, anh vẫn có thể chơi ở bên đó (theo lời Paul, video đăng ngày 09/07/2026). Arnon nói đó là nơi có tiền, và anh hiểu điều đó. Paul nói anh trân trọng điều Arnon nói: đừng vội vàng, hời hợt kiểu "chúng ta ở đây để chê châu Âu".

Những cái tên Arnon nêu khi nói về hệ sinh thái công nghệ ở châu Âu (video đăng ngày 09/07/2026).

Arnon kể hôm trước anh vừa tới một sự kiện của ElevenLabs, theo anh là một công ty "từ đây". Paul hỏi họ từ đâu. Arnon nói anh nghĩ họ từ đây, anh nghĩ họ từ London. Anh nói ở sự kiện có rất nhiều nhân tài: người Ý, người Hy Lạp, người Tây Ban Nha, kiểu họ tuyển từ khắp châu Âu. Rồi còn có Harvey, Legora, Lovable và một công ty nữa. Theo anh, có rất nhiều công ty thú vị từ khu vực này (theo Arnon, video đăng ngày 09/07/2026). Paul đồng tình. Arnon nói anh hoàn toàn không xem nhẹ điều đó, và anh nghĩ không ai nên xem nhẹ.

## 17. Bài học GTM: đừng tự động hóa mọi thứ, và invoice là một touch point

Paul nói hai người sắp phải dừng, nhưng anh muốn hỏi thêm một câu ngắn: Arnon đã có nhiều vai trò, ở vài công ty khác nhau, làm việc trên toàn cầu. Anh có thể chia sẻ một hai bài học về lãnh đạo, về chiến lược GTM, những bài học cốt lõi anh mang theo vào vai trò ở Solvimon không? (video đăng ngày 09/07/2026).

Arnon nói trong khoảng một năm, một năm rưỡi gần đây, đã có một xu hướng kiểu "hãy thử tự động hóa mọi thứ, làm mọi thứ bằng AI, tạo toàn bộ nội dung bằng AI". Anh nghĩ điều đó bỏ lỡ điểm chính, vì nếu bạn làm được thì ai cũng làm được. Paul đồng tình. Arnon kể bạn thấy đủ kiểu bài "comment 'plan' để nhận kế hoạch của tôi về cách làm mọi thứ dễ dàng với Claude". Anh nói về mặt công nghệ thì nó thú vị, anh tò mò về nó và cũng sẽ thử (theo Arnon, video đăng ngày 09/07/2026).

Nhưng anh nghĩ chúng ta đang đánh mất một thứ rất, rất căn bản, một lần nữa là cái gu mà con người có. Khi ai cũng làm giống nhau thì bạn chẳng làm gì cả. Nhìn nhiều thương hiệu ra đời vào lúc đó, nhiều cái được thiết kế bằng cùng những công cụ: "Ồ, tôi bỏ ra 50 đô la và vibe code một website trên Lovable, Replit, hay gì đó." Và chúng trông na ná nhau. Khi mọi thứ trông giống nhau thì bạn đã thua, bạn đang chiến đấu từ thế bất lợi (theo Arnon, video đăng ngày 09/07/2026).

Bài học GTM Arnon nêu (video đăng ngày 09/07/2026): nếu bạn tự động hóa được thì ai cũng tự động hóa được, và gu là thứ khó sao chép.

Paul nói nó giống chuyện "zig khi mọi người khác zag". Anh kể ngay hôm đó anh vừa nói chuyện với các senior consultant của mình về invoice. Anh và các consultant tự hỏi: sao mình chưa tự động hóa? Rồi anh hình dung: bạn có khách hàng lớn nhất, họ trả đúng hạn. Có thể ngày đến hạn rơi vào Chủ nhật hay gì đó, và ngày hôm sau họ chưa trả đúng hạn như thường lệ, giữa tháng, thế là họ nhận một invoice tự động. Và họ kiểu: "Thôi nào, anh biết tôi trả đều đặn mà, tôi là khách lớn nhất của anh, mình làm ăn với nhau bao năm rồi." (video đăng ngày 09/07/2026).

Theo Paul, đúng là mình có thể tự động hóa, nhưng có nên không? Tác động tới con người của việc tự động hóa đó là gì? Vì giờ bạn vừa gửi tới khách hàng lớn nhất một tín hiệu rằng bạn đã tự động hóa, bạn chỉ đang đòi nợ. Bạn phải thật sự nghĩ: mình đang tự động hóa cái gì, và tác động sẽ ra sao? Arnon đồng ý (video đăng ngày 09/07/2026).

Arnon nói khi làm marketing, mọi thứ mình đưa ra đều là một điểm tiếp xúc với khách hàng. Và theo anh, invoice bị đánh giá thấp hoàn toàn như một điểm tiếp xúc với ai đó. Nó là một touch point. Bạn nên dùng nó để cho thấy một chút về bản thân, một chút về văn hóa của mình (theo Arnon, video đăng ngày 09/07/2026). Paul: "Chính xác."

## 18. Value receipt, "surprise and delight" và lời kết

Có tiếng nói tiếp: nếu bạn gửi đi một invoice thậm chí không có logo của mình, chỉ có tên công ty, thì hãy thêm một lời nhắn cá nhân. Rồi có tiếng nói về một việc đang được xem xét: bán tự động hóa một kiểu báo cáo tác động (impact report), để khi nhận invoice, khách có luôn ba điểm dữ liệu về tác động mà bên bán đã tạo ra cho doanh nghiệp của họ (video đăng ngày 09/07/2026).

Arnon kể anh đã làm việc đó năm ngoái ở Paid. Anh và nhóm ở Paid gọi nó là "value receipt", một thứ đi kèm invoice. Paul nói anh rất thích ý này và team anh sẽ dùng nó. Arnon giải thích: trong value receipt, anh và nhóm đưa vào giá trị quy đổi ra công sức con người của những gì AI agent đã làm cho khách. Nếu bạn xây một agent, bạn phải báo cáo các chỉ số này, đó là cách anh và nhóm ở Paid tính tiền, và anh và nhóm đính kèm luôn nó. Khách có thể quyết định dùng nó hay không, nhưng theo anh, bạn phải cho thấy giá trị của mình (câu chuyện của Arnon về Paid, video đăng ngày 09/07/2026).

Value receipt mà Arnon kể đã làm ở Paid năm ngoái, cùng "growth hack" anh gợi ý cho invoice (video đăng ngày 09/07/2026).

Arnon còn gợi ý một "growth hack" cho invoice: hãy đặt vào đó một thứ vui, một thứ mới, hoặc một thứ để mong chờ, để khách mở invoice ra chứ không nghĩ "ồ, để xem sau". Nó có thể là thứ ngớ ngẩn như một câu đùa, và bạn có thể tự động hóa việc đó (theo Arnon, video đăng ngày 09/07/2026).

Paul nói team anh gọi đó là "surprise and delight": những điều nhỏ mình sẽ làm là gì? Anh kể một khách hàng của anh nói: "Tôi sắp đi một hội nghị ở Detroit, tôi lo lắm, tôi ngồi một panel mà chưa sẵn sàng." Paul mất 30 phút, làm cùng Gemini và Claude, soạn ra một gói executive briefing: phân tích ai sẽ ngồi panel, đây là vài câu hỏi cho từng người, đây là điểm chung giữa chị ấy với từng người (câu chuyện của Paul, video đăng ngày 09/07/2026).

![Paul nói và giơ tay, Arnon ngồi nghe](https://homus.dev/photos/bkV9yBnlPUs-3423.jpg)

Paul kể câu chuyện gói executive briefing cho một khách hàng trước hội nghị; Arnon ngồi nghe ở bên trái.

Theo Paul, chị ấy thốt lên "ôi trời". Anh nói anh làm vì anh rất quý chị ấy, rất quý doanh nghiệp đó, chị ấy là một khách hàng của anh, tại sao không, anh có thời gian. Chị ấy rất thích, và anh chắc nó đã đem lại cho team anh rất nhiều "vốn", vốn xã hội, và đó đơn giản là một việc tử tế nên làm. Có tiếng nói tiếp: "100%", việc đó rất dễ, bạn chỉ cần làm nhiều hơn người khác 5%. Paul nói thêm: không cần nghĩ tới lợi ích, đó là việc đúng nên làm, nhưng có lẽ nó đã giúp team anh giữ thêm vài tháng hợp tác, chỉ vì chị ấy nghĩ "trời, tôi thật sự quý mấy người này" (video đăng ngày 09/07/2026).

Paul nói đây là chỗ hay để dừng. Anh nói anh rất thích tập này, vì anh là fan của cách Arnon nghĩ về chiến lược tăng trưởng và go-to-market, và cả thế giới kỹ thuật của hạ tầng billing. Như hai người vừa đi tới, nó có thể rất kỹ thuật nhưng cũng có thể rất "người". Anh thấy điều Solvimon đang làm, giúp người ta nghĩ về việc xây revenue stack, đa dạng hóa nó, làm nó phức tạp hơn nhưng cũng đơn giản hơn, là thật sự thú vị. Theo Paul, monetization không chỉ là cái giá; có cả một trải nghiệm sản phẩm cốt lõi đi kèm, và đó là điều thú vị (video đăng ngày 09/07/2026).

Arnon nói monetization đang rất "hot" vào lúc đó, ai cũng nói về nó (video đăng ngày 09/07/2026). Anh thấy lạ, vì anh làm việc này từ khoảng năm 2020. Không ai thức dậy và nói "ồ, tôi muốn làm billing", phải thành thật như vậy. Nhưng nó đang bắt đầu hấp dẫn hơn nhiều, và anh thấy nhiều người giờ đã viết sách về nó (theo Arnon, video đăng ngày 09/07/2026). Paul cảm ơn Arnon đã dành thời gian cho buổi trò chuyện.

## Nguồn và liên kết

- Tên gốc: Revolutionising AI Monetisation and Usage-Based Billing with Arnon Shimoni, VP of Growth at Solvimon
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=bkV9yBnlPUs](https://www.youtube.com/watch?v=bkV9yBnlPUs)

- Kênh YouTube Literal Humans (Paul David, khách mời Arnon Shimoni): [youtube.com/channel/UCsitHEBlmPqB2vRC9mBDNQQ](https://www.youtube.com/channel/UCsitHEBlmPqB2vRC9mBDNQQ)

- Solvimon, công ty Arnon làm VP of Growth; trang chủ tự mô tả là billing và revenue management cho thời AI, với pricing theo usage, theo outcome và hybrid (đọc ngày 03/11/2026): [solvimon.com](https://www.solvimon.com)

Nguồn: https://homus.dev/talks/revolutionising-ai-monetisation-and-usage-based-billing-with-arnon-shimoni-vp-of-growth-at-solvimon · cập nhật 2026-11-03