# Kiến trúc định giá SaaS: buổi training đầy đủ

[Ulrik Lehrskov-Schmidt](https://homus.dev/speakers/ulrik-lehrskov-schmidt) · [Willingness to Pay](https://homus.dev/orgs/willingness-to-pay)

> Ulrik Lehrskov-Schmidt giảng pricing architecture cho SaaS: phí recurring và one-off, pilot, bốn tiêu chí chọn pricing metric, value chain, wallet structuring.

Topics: SaaS Pricing, Startups

Canonical: https://homus.dev/talks/saas-pricing-architecture-full-training

## 1. Recurring hay transactional: câu hỏi đầu tiên của pricing architecture

Đây là buổi training đầy đủ của Ulrik Lehrskov-Schmidt về SaaS pricing architecture (video đăng ngày 07/07/2023). Theo mô tả video (đăng ngày 07/07/2023), anh đi sâu vào các lựa chọn cụ thể để định giá sản phẩm và cách tạo ra giá trị cho khách hàng. Buổi học diễn ra trong một phòng họp với một nhóm nhỏ người tham dự, và họ chen vào hỏi và đáp nhiều lần.

![Ulrik Lehrskov-Schmidt đứng trước màn hình có slide SaaS Pricing Architecture](https://homus.dev/photos/BGb6-WKMNN4-0223.jpg)

Ulrik đứng trước màn hình lớn trong phòng họp, sau lưng là slide "SaaS Pricing Architecture: The 9 Elements of SaaS Revenue" (slide trong video đăng ngày 07/07/2023).

Ulrik mở đầu bằng câu hỏi gốc của một pricing architecture: ta có một sản phẩm và giờ muốn định giá nó, vậy ta có những lựa chọn nào? Theo anh (video đăng ngày 07/07/2023), điều đầu tiên cần cân nhắc là: tôi tính tiền theo cách định kỳ (recurring) hay chỉ theo từng giao dịch (transactional)? Tức là tôi giao một thứ gì đó, tính tiền, rồi xong; hay tôi tiếp tục giao cho bạn theo một cách nào đó và tiếp tục tính tiền? Nếu là vế sau thì đó là subscription, hoặc là pricing theo user.

Nếu chỉ là transactional, Ulrik chia tiếp theo thời điểm giao dịch xảy ra trong vòng đời khách hàng (customer lifetime) (video đăng ngày 07/07/2023). Có thể là start cost: onboarding, migration, training và những thứ tương tự để khách hàng bắt đầu, cả phí đăng ký (sign-up fee). Có thể là những khoản one-off ad hoc: "chúng tôi sẽ build một integration cho bạn vào lúc nào đó", "chúng tôi sẽ làm thêm một buổi training", "chúng tôi sẽ thêm một địa điểm", tức một việc làm một lần trong khi bạn vẫn là khách hàng, có thể nằm bên dưới quan hệ recurring. Hoặc là việc làm một lần ở cuối để off-board khách hàng. Hoặc cũng có thể có một lựa chọn ở đó.

![Slide The 9 Elements of SaaS Revenue: doanh thu theo vòng đời khách hàng](https://homus.dev/photos/BGb6-WKMNN4-0103.jpg)

Slide "The 9 Elements of SaaS Revenue": trục ngang là Customer Lifetime, trục dọc là Revenue. Hai đầu là Start Cost và Exit Cost; ở giữa có khối Ad-Hoc One-Offs (services, change requests, certifications), ba lớp flat (Basic Subscription Fee, Flat Add-On Fees, Flat Non-Optional Fees) và ba lớp metric tăng dần (Usage-Based, License-Based, Credit-Based Metrics) (slide trong video đăng ngày 07/07/2023).

Đó mới chỉ là các khoản transactional. Ulrik nói (video đăng ngày 07/07/2023) trong nhiều startup, kể cả thế giới enterprise, người ta ghét những khoản one-off này, vì nghĩ rằng: nếu chuyển doanh thu transactional đang có thành ARR (annual recurring revenue) thì công ty sẽ đáng giá hơn rất nhiều. Đúng thế. Nhưng tiền là tiền. Nếu bạn kiếm được thật nhiều tiền mặt trong doanh nghiệp thì bạn không cần bận tâm nó đáng giá bao nhiêu, cứ lấy tiền mặt.

Ulrik kể mọi doanh nghiệp của anh đều là bootstrapped (theo lời anh trong video đăng ngày 07/07/2023). Và đôi khi người ta chỉ muốn trả nhiều hơn hẳn một lần, thay vì trả theo kiểu định kỳ, kể cả tính trên cả vòng đời của họ. Vì vậy lời khuyên của anh (video đăng ngày 07/07/2023): đừng quá gắn bó với ý tưởng recurring revenue. Nếu việc giao hàng của bạn kéo dài theo thời gian thì recurring revenue hoàn toàn hợp lý. Nhưng nếu việc giao chỉ xảy ra rồi biến mất, cứ tính tiền một lần.

## 2. Quy trình 100 ngày: ký toàn bộ trước, pilot chỉ là lối thoát

Tiếp đó Ulrik mô tả một quy trình 100 ngày, nói ở ngôi "chúng tôi" của bên bán (video đăng ngày 07/07/2023). Mười ngày đầu, bên bán làm integration vào các hệ thống, phát tablet cho toàn bộ người kỹ thuật bên khách và thiết lập mọi thứ. Sau đó là 60 ngày dùng thử (trial period): khách dùng phần mềm, còn bên bán ngày nào cũng gọi điện, tìm hiểu xem khách đã sẵn sàng và biết dùng chưa, và theo dõi xem khách có thật sự làm các bước kiểm tra hay không. Cuối cùng là 30 ngày với một workshop cụ thể, nơi hai bên xem lại mọi KPI đã thống nhất trong quá trình bán hàng.

![Thẻ 100 day process: 10 ngày integration, 60 ngày trial, 30 ngày workshop](https://homus.dev/photos/BGb6-WKMNN4-0303.jpg)

Thẻ "100 day process" trong video: 10 days System integration, 60 day Trial period, 30 day Workshops (Opt-out period) (video đăng ngày 07/07/2023).

Khi KPI đã được trình bày, khách hàng có quyền opt-out. Lý do, theo Ulrik (video đăng ngày 07/07/2023): ngay ngày đầu tiên, khách đã ký để trả tiền cho pilot, nhưng đồng thời cũng ký subscription cho toàn bộ giải pháp. Vậy là có một giai đoạn opt-out 30 ngày, trong đó hai bên đồng ý đo mọi thứ đã làm trong pilot. Và anh cho rằng nếu bên bán đạt mọi mục tiêu đã hứa, thì ít nhất theo một cách nào đó, bạn nên tạo ra tình huống mà khách cảm thấy có nghĩa vụ về mặt đạo đức phải tiếp tục và thật sự mua toàn bộ, vì họ đã ký và họ biết giá đầy đủ. Kiểu: "được, chúng tôi sẽ trả, chẳng hạn, 10 euro mỗi nhân viên hay bao nhiêu đó".

Như vậy, theo Ulrik (video đăng ngày 07/07/2023), thương vụ lớn thật sự trở thành mặc định, vì khách đã ký rồi. Sau đó bạn chỉ việc chứng minh, và cho khách một điều khoản thoát (escape clause, opt-out) phòng khi vì lý do nào đó họ không muốn làm, ngân sách của họ sụp đổ, hoặc họ thấy KPI đã đặt sai: bạn đạt KPI, nhưng thật ra bạn đã hiểu sai doanh nghiệp của họ, hay đại loại vậy. Thế thì: được, bạn có điều khoản opt-out.

Điểm chính Ulrik nhấn (video đăng ngày 07/07/2023): bạn chỉ nên bắt đầu pilot khi đã bán được toàn bộ. Pilot chỉ là một cửa thoát an toàn (safety hatch) cho khách hàng. Điều đó cũng có nghĩa là bạn phải bán pilot cho người mua thật sự (the actual buyer), không chỉ cho người gác cổng (gatekeeper) có quyền chi khoản tiền của pilot. Còn chuyện bạn tính khoản đó cho pilot hay tính phí recurring thì không quan trọng; thậm chí cho không cũng được, anh không bận tâm. Có thể khách cần một cam kết nào đó, nhưng mục đích của pilot là đưa khách tới chỗ họ có thể nhìn lại hiệu quả thật của sản phẩm và rất khó opt-out khỏi thứ họ đã opt-in từ lúc bắt đầu pilot.

Nếu không cấu trúc như vậy, theo Ulrik (video đăng ngày 07/07/2023), bạn chỉ đang tạo ra một dự án marketing nội bộ để người champion bên trong công ty khách đi bán bạn cho chính công ty họ, và như thế thì bạn chưa có thương vụ nào. Anh nói có lẽ khoảng 10% số lần người champion thật sự thành công việc đó. Anh hỏi cả phòng: hiểu chứ?

## 3. Một người tham dự hỏi chuyện pilot: nói gì khi khách hỏi "sau đó thì sao?"

Một người tham dự đáp "rất hiểu" và kể rằng chuyện này gắn rất chặt với một cuộc trò chuyện chị có trước đó, cũng với một khách hàng đang bàn về pilot, và chị đã tự hỏi: vậy sau pilot thì chuyện gì sẽ xảy ra? (video đăng ngày 07/07/2023)

Ulrik nhập vai người bán để trả lời (video đăng ngày 07/07/2023): "Chúng tôi phải làm pilot. Đây là cách chúng tôi làm. Rất vui vì anh chị hỏi. Chúng tôi làm pilot với tất cả những khách hàng tốt nhất của mình. Đây là cách chúng tôi làm: trước tiên, chúng ta ký toàn bộ giải pháp. Sau đó có 100 ngày pilot. Rồi có workshop này, nơi chúng ta đo hiệu quả của pilot. Và nếu khi đó anh chị không muốn toàn bộ giải pháp thì có thể opt-out ở thời điểm ấy. Anh chị không bị ràng buộc gì. Đó là cách chúng tôi làm pilot."

Có tiếng nói tiếp (video đăng ngày 07/07/2023): vậy nó không nhất thiết phải là một giao dịch, nó giống một cuộc trò chuyện và một cam kết hơn, đúng không? Đó mới là phần quan trọng.

Ulrik nói (video đăng ngày 07/07/2023): bạn khiến họ ký, bạn khiến đúng người ký đúng tài liệu ngay ngày đầu. Sau đó, đúng là pilot có thể là một khoản one-off. Nhưng lời hứa, và điều đã được ký, là sau 100 ngày, nếu không opt-out, toàn bộ phần recurring sẽ bắt đầu, có thể kèm cả việc triển khai trên toàn tổ chức hay bất cứ thứ gì cần ở đó. Thế là ổn.

Cách làm pilot Ulrik mô tả trong video đăng ngày 07/07/2023: đúng người ký toàn bộ ngay ngày đầu, pilot 100 ngày, workshop đo KPI, rồi hoặc opt-out, hoặc phần recurring bắt đầu.

Ulrik hỏi cả phòng anh có thể nói tiếp một chút không, vì phần tiếp theo là pricing metrics: cách chọn chúng và cái gì có thể hợp với từng người, phần anh nghĩ mọi người sẽ thích. (video đăng ngày 07/07/2023)

## 4. Phí định kỳ: flat fee và ba loại metric

Với phí định kỳ (recurring fees), theo Ulrik (video đăng ngày 07/07/2023), có thể chia làm hai loại. Một là loại "giá trên mỗi thứ gì đó" (a price per something), đó là pricing metric: giá trên mỗi user, mỗi API call, mỗi lần scan, mỗi event, bất cứ gì. Hai là loại chỉ là một khoản cố định (flat) mỗi tháng; con số bao nhiêu không quan trọng, kể cả 100.000 euro mỗi tháng.

Flat fee rất tốt, theo Ulrik (video đăng ngày 07/07/2023): chúng có nhiều chức năng trong một pricing model, vì nhiều lý do. Ví dụ, giả sử bạn tính $10 mỗi nhân viên, hay $10 mỗi user, nhưng thật sự không muốn khách hàng nào dưới $1.000. Thế thì bạn nói: chúng tôi tính $1.000 cộng $10 mỗi user. Flat fee nâng phần đáy, tức mức chi phí tối thiểu; đó là một cách chúng hoạt động.

Với phí dựa trên metric, "price per", Ulrik chia làm ba loại (video đăng ngày 07/07/2023). License là loại kinh điển, ví dụ một user license: tôi trả tiền, tôi có quyền truy cập một thứ gì đó. Phần lớn app trong app store hoạt động như vậy: tôi trả tiền subscription cho app và tôi được dùng app, là tôi, vì đó là điện thoại của tôi. Có thể là $100 một năm hay $10 một tháng, bao nhiêu cũng được. Thế thôi. Và tôi trả tiền kể cả khi không dùng, đúng không? Một người tham dự đáp lại, nhắc tới nỗi lo về chuyện đó.

Ulrik nói (video đăng ngày 07/07/2023) license là như vậy, và chúng rất tốt. Nhưng có thể có trường hợp usage-based pricing tốt hơn. Usage-based pricing chính là cách bạn trả tiền điện với đồng hồ điện: bạn có quyền dùng điện, nhưng không trả cho tới khi dùng. Đồng hồ bắt đầu chạy, sau một khoảng thời gian người ta đọc số và gửi hoá đơn cho bạn. Đó là lý do khi bạn trả tiền Azure, chẳng hạn, theo kiểu "tôi trả theo mỗi API call, theo mỗi thứ này", thì đó thường được gọi là reoccurring revenue: loại doanh thu không cố định, nên không phải recurring revenue, nhưng nó cứ lặp lại hết lần này tới lần khác vì hành vi của khách hàng.

Cách Ulrik chia phí định kỳ trong video đăng ngày 07/07/2023: flat fee, và ba loại phí theo metric.

## 5. Credit-based metrics: bài học từ Audible

Loại thứ ba là credit-based metrics. Ulrik hỏi phòng có ai dùng Audible, app sách nói, không (video đăng ngày 07/07/2023). Audible dùng credit: bạn subscribe, trả một khoản cố định mỗi tháng, và mỗi tháng nhận một hoặc hai credit tuỳ subscription. Nếu bạn không tiêu, credit nằm trong tài khoản và tích luỹ dần: thêm hai credit nữa, vậy là bạn có hai, rồi bốn, rồi sáu, rồi tám.

Rồi một dịp nào đó tới, kiểu "cuối cùng mình cũng có thời gian nghe hết đống sách nói này", tôi vào và tải tám cuốn. Tôi tiêu hết credit. Nhưng tôi không huỷ subscription, đúng không? Vì: ồ, cái này chạy tốt quá. Tôi đã trả tiền, giờ tôi có credit đúng lúc cần, tôi tiêu chúng, rồi tôi giữ subscription, và nó lại cộng thêm hai, hai, hai, hai nữa. Rồi một kỳ nghỉ khác tới, và tôi lại đi tiêu credit (ví dụ Ulrik kể trong video đăng ngày 07/07/2023).

Ví dụ Audible của Ulrik (video đăng ngày 07/07/2023): credit tích luỹ khi không dùng, được tiêu một lần khi người dùng có thời gian, và subscription vẫn tiếp tục.

Vậy hệ thống credit, theo Ulrik (video đăng ngày 07/07/2023), về bản chất là usage-based pricing được trả trước. Tôi trả cho phần sử dụng: tôi tải sách nói, đó là phần tiêu thụ, nó xảy ra và tôi trả cho nó. Nhưng việc billing diễn ra theo chu kỳ định kỳ. Mô hình này có thể chạy được, nhưng cần cẩn thận hơn một chút khi thiết kế chi tiết để người dùng không bị vướng. Có thể có rất nhiều điều khoản: credit có hết hạn không? Tôi dùng credit nào trước, cái cũ nhất hay cái mới nhất? Tôi có được trả lại credit nếu tôi churn không? Vân vân. Có rất nhiều câu hỏi quanh credit mà bạn phải trả lời được khi đang ở trong bối cảnh bán hàng.

## 6. Hai thứ gần như là quy tắc: packaging và pricing metric

Ulrik nhắc lại hai thứ anh gọi là gần như quy tắc của monetization và pricing (video đăng ngày 07/07/2023). Thứ nhất, hãy làm packaging. Nếu bạn chỉ có MVP thì cứ bán MVP, nhưng hướng tới việc có nhiều hơn một gói. Đó là cách rất tốt để phân biệt các nhóm khách hàng, giống như hành khách tàu hoả hạng nhất, hạng nhì, hạng ba.

![Slide The Transcontinental Railroad: Price Discrimination Problem](https://homus.dev/photos/BGb6-WKMNN4-0943.jpg)

Slide "The Transcontinental Railroad: Price Discrimination Problem": trên trục Willingness-to-Pay, một vé duy nhất không phân biệt (Single Undifferentiated Ticket) được tách thành hạng 1 và hạng 2 "optimally priced", vé hạng nhất có thêm quyền vào toa ăn (dining wagon), và câu hỏi "How do we create a 3rd class experience?" (slide trong video đăng ngày 07/07/2023).

Thứ hai, hãy có một pricing metric, như giá theo dặm (price per mile): đi càng xa, vé càng đắt (theo Ulrik, video đăng ngày 07/07/2023). Trong những app B2C thật đơn giản thì không làm vậy; ta chỉ nói bạn là một user và bạn trả theo tháng, chẳng hạn cho một app học ngôn ngữ. Vì thế nếu bạn thấy "ồ, lạ nhỉ, mình có nên tính theo mỗi flashcard không", thì có thể là không cần. Hãy làm cho phù hợp với tình huống của chính bạn.

Nhưng ngay khi ACV (annual contract value) bắt đầu vượt lên trên, chẳng hạn, vài nghìn euro, thì theo Ulrik (video đăng ngày 07/07/2023) có lẽ bạn cần một pricing metric để bắt đầu phân biệt các khách hàng với nhau.

## 7. Bốn tiêu chí để chọn pricing metric

Vậy chọn một pricing metric tốt thế nào? Ulrik kể anh đã mất nhiều đêm mất ngủ vì câu hỏi này để mọi người khỏi phải mất, và đây là kết luận của anh (video đăng ngày 07/07/2023): có bốn thứ cần cân nhắc. Anh nói tới giờ anh chưa gặp tình huống nào mà bốn thứ này không giải được, không tìm ra một pricing metric chạy được. Anh sẽ đi qua từng tiêu chí thật nhanh, rồi đi lại từng cái thật chậm.

![Slide Pricing Metrics: Choosing the right metric(s) với bốn tiêu chí](https://homus.dev/photos/BGb6-WKMNN4-1103.jpg)

Slide "Pricing Metric = A price per X" (Price per #GB, Price per #User, etc) và "Choosing the right metric(s)": 1. Measurable & Executable, 2. Value Perception, 3. Expectation to pay, 4. Metric Density (slide trong video đăng ngày 07/07/2023).

Thứ nhất, theo Ulrik (video đăng ngày 07/07/2023), muốn tính giá theo một thứ gì đó thì bạn phải đo được nó. Không đo được thì không thể tính giá theo nó. Anh kể hôm qua có một người nói với anh: "Tôi sẽ tính giá theo số giờ tiết kiệm được trong thời gian training kỹ thuật viên." Anh hỏi lại: làm thế quái nào anh đo được cái đó? Người kia đáp: nhưng hôm nay họ đang mất chừng ấy giờ trung bình, và tôi có thể kéo nó xuống. Ulrik: đúng, nhưng con số đó sẽ thay đổi, và họ còn làm những việc khác nữa. Rất khó để bạn chỉ ra chính xác giờ mà bạn tiết kiệm được so với mọi sáng kiến khác mà khách hàng đang chạy. Vậy là không đo được, nên không dùng làm pricing metric được.

Thứ hai, khách hàng có muốn nó không? Hay nói cách anh dùng: bản thân khách hàng có muốn nhiều thứ này hơn không? Khách hàng có muốn nhiều user hơn không? Có muốn nhiều flashcard hơn không, lấy ví dụ đó (theo Ulrik, video đăng ngày 07/07/2023).

Tiêu chí kế tiếp, Ulrik hỏi (video đăng ngày 07/07/2023): khách hàng có kỳ vọng trả tiền theo cách này không, hay họ thấy nó kỳ cục, thậm chí bất công?

Thứ tư là cái anh gọi là density: đơn vị đó có giá trị đồng đều không? Anh lấy ví dụ một người tham dự quyết định tính giá theo mỗi sản phẩm, không phải mỗi đơn vị hàng mà mỗi mã sản phẩm (product code), như người đó chen vào nói. Khi đó, theo Ulrik (video đăng ngày 07/07/2023), rất có thể có mã sản phẩm chỉ bán vài trăm đơn vị vì đó là một sản phẩm ngách lạ lùng, còn mã khác là hộp sữa tách béo một lít bán ra hàng triệu hộp. Với sản phẩm này giá trị rất lớn, với sản phẩm kia cực nhỏ. Nên density của giá trị tính theo từng sản phẩm rất thấp, vì cái thì to, cái thì nhỏ.

Ví dụ ngược lại là Stripe. Theo Ulrik (video đăng ngày 07/07/2023), Stripe tính một tỷ lệ phần trăm trên số đô la bạn đẩy qua nền tảng thanh toán của họ, anh nói là 2,95% ở mức đầu tiên. Và một đô la giống hệt một đô la khác; một đô la là một đô la là một đô la. Nên density của một đô la là 100%: không phải tôi thích đồng đô la này hơn đồng kia, nó là cùng một đô la, cứ cho tôi thêm nhiều nữa. Nó có density hoàn hảo.

Ulrik nói anh sẽ đi qua từng tiêu chí bằng một ví dụ. Một người tham dự hỏi có được chụp ảnh slide không; anh đồng ý, nói có thể gửi slide cho mọi người sau, nhưng ai cũng thích chụp ảnh, nên cứ chụp. (video đăng ngày 07/07/2023)

## 8. Bảng giá của 2021.AI: ngân hàng muốn model, không muốn thêm user

Ví dụ là một ma trận giá (pricing matrix) của 2021.AI. Theo Ulrik (video đăng ngày 07/07/2023), đây là một công ty Đan Mạch làm AI cho ngân hàng, trên một nền tảng tên là Grace. Nếu bạn là ngân hàng, bạn mua license Grace và bị tính giá theo hai pricing metric. Một là số user: anh nói Small là tới 8, Medium từ 9 tới 20, Large từ 21 trở lên. Và đây là một ma trận: chiều kia là giá theo số model đang chạy production.

![Bảng giá 2021.AI Pricelist cho Grace License theo số user và số model in production](https://homus.dev/photos/BGb6-WKMNN4-1603.jpg)

Slide "2021.AI Pricelist", Grace License, "Monthly rates in EUR ex. VAT", đề ngày 01 January 2019. Hàng là Users (up to 8 Small, up to 20 Medium, enterprise Large), cột là # Models in production (1-4, 5-15, 15+); ô Medium với 5-15 model ghi 12.500. Cột Included components ghi Github integration, Small + Nifi, Medium + Hadoop/Spark (slide trong video đăng ngày 07/07/2023).

Ulrik giải thích (video đăng ngày 07/07/2023): một AI model có thể đang ở giai đoạn testing, hoặc được đẩy vào doanh nghiệp, tức đang production và làm một việc gì đó. Ở đây chỉ tính tiền cho model đang production và làm việc trong doanh nghiệp. Nếu tôi có, chẳng hạn, năm model và mười nhân viên, tôi đọc ma trận, đi tới ô này, và trả 12.500 euro mỗi tháng. Nó hoạt động như vậy: giá theo model và giá theo user.

Giờ tới tiêu chí value: user và model có giá trị với ngân hàng không? Ulrik kể anh đã hỏi và họ xác nhận có (video đăng ngày 07/07/2023): nhiều user hơn bằng làm được nhiều việc hơn, bằng nhiều dự án AI hơn nói chung, nên user có giá trị với ngân hàng. Còn model đang production? Cũng có, đó là lý do người ta mua. Model chỉ được deploy khi đã chứng minh được là tạo ra giá trị. Khi có một model đang production là vì nó làm một việc gì đó, nó tạo ra điểm tín dụng (credit score) hay phân tích một thứ gì đó, và ngân hàng nhận giá trị từ đó, hoặc vì tự động hoá được một việc, hoặc vì nó mở ra một business case mới. Tuyệt.

Câu hỏi thứ hai: họ có muốn chúng không? Ulrik nói tới đây thì câu trả lời khác (video đăng ngày 07/07/2023). Họ có muốn model production không? Có, họ muốn nhiều model hơn, đó là lý do họ làm việc này ngay từ đầu. Nhưng với user, họ luôn nói: vâng, chúng tôi đồng ý user tạo ra giá trị, nhiều user hơn tạo ra nhiều giá trị hơn, nhưng chúng tôi cần bao nhiêu? Cần tối thiểu bao nhiêu user để làm việc tạo ra model, thứ chúng tôi thật sự muốn? Và chúng tôi muốn model vì có một kết quả ở cuối, vân vân.

Kết quả là, theo Ulrik (video đăng ngày 07/07/2023), 2021.AI chưa bao giờ bán được hơn tám user trong lần đầu. Ngân hàng sẽ mua tám user, làm việc với giải pháp, rồi sau một chu kỳ khoảng một năm, một năm rưỡi, quay lại nói: cái này tuyệt quá, chúng tôi mua thêm user được không? 2021.AI không thích hiện tượng này. Họ nói: được, giờ chúng ta làm feature differentiation ở đây, nếu muốn có, chẳng hạn, Spark, hay gói Medium, hay một trong những thứ này... Họ thử dùng các ngưỡng tính năng (functionality thresholds) để đẩy khách hàng đi lên, và khách hàng không thích điều đó. Khách nói: chúng tôi muốn Spark, nhưng chỉ có năm user, giờ chúng tôi thấy mình bị định giá cao một cách kỳ lạ (overpriced). Trên bảng giá ở slide, Hadoop/Spark nằm trong dòng Large.

Câu hỏi, theo Ulrik (video đăng ngày 07/07/2023), là vì sao họ không muốn thêm user? Chính họ vừa nói user có giá trị, user tạo ra giá trị, vậy sao không muốn có nhiều hơn? Một người tham dự hỏi lại: ai, các ngân hàng à? Ulrik: các ngân hàng. 2021.AI thì chắc chắn muốn bán thêm user. Nhưng các ngân hàng, dù đồng ý user tạo ra giá trị, thì lại không muốn mua. Người tham dự hỏi tiếp: user trong bối cảnh này là gì? Ulrik đáp: đó là người có quyền truy cập license Grace và có thể build AI model rồi deploy chúng.

## 9. Value chain: vàng nằm ở cuối cầu vồng

Để hiểu chuyện gì đang xảy ra, theo Ulrik (video đăng ngày 07/07/2023), cần đào sâu một chút vào việc tạo ra giá trị, hay có giá trị trong một bối cảnh, nghĩa là gì, vì "ma quỷ nằm ở chi tiết". Để tạo ra giá trị, ta có thể nhìn nó như một value chain: tôi làm một việc cho phép tôi làm một việc khác, rồi việc đó cho phép tôi làm việc khác nữa, và cuối cùng cho phép tôi có được thứ tôi muốn. Ví dụ, tôi tập thể dục để giảm cân. Có một quá trình đang diễn ra, một chuỗi nhân quả với các bước bắt đầu ở đâu đó và kết thúc ở thứ tôi muốn. Ở một đầu là input: tôi hy sinh thời gian, công sức, vân vân. Và rồi tôi nhận được thứ tôi muốn hơn, chẳng hạn là không kém hấp dẫn nữa.

Ulrik nói (video đăng ngày 07/07/2023) điều này y hệt với mọi loại business model. Với các ngân hàng dùng license Grace: họ lập một dự án AI model và một team. Kiểu "chúng tôi muốn làm AI, nên sẽ thuê vài người làm AI, cho họ một ngân sách và để họ tự đi". Rồi những người này tìm vài nguồn dữ liệu và vài ý tưởng cho AI model, bắt đầu train model, deploy chúng vào doanh nghiệp, và từ đó tạo ra một kết quả: tính credit score hay bất cứ gì, tự động hoá một việc gì đó. Đó là kết quả ngân hàng muốn. Ngân hàng đầu tư team và ngân sách để có credit score; nó tạo ra doanh thu, nó làm một việc gì đó cho ngân hàng ở đầu kia. Không ai muốn một AI team; cái người ta muốn là thứ AI team đó làm được ở cuối.

![Slide Customer Value Chain: AI models for enterprise, từ input tới output](https://homus.dev/photos/BGb6-WKMNN4-2043.jpg)

Slide "Customer Value Chain: Where to place your pricing?" với ví dụ "AI models for enterprise": từ INPUT tới OUTPUT có bốn bước (I create an AI model project & team; I gather data and train my model; I deploy my model; The model works and my KPI's improve), bên dưới là metric ứng với từng bước: # Users, # GB Processed, # Models, # Data Outputs (slide trong video đăng ngày 07/07/2023).

Vậy một đầu là input, tức là chi phí (cost), cần thiết vì nó tạo ra, theo quan hệ nhân quả, giá trị đi ra ở đầu kia. Theo Ulrik (video đăng ngày 07/07/2023), hầu như ai cũng chỉ muốn có càng nhiều giá trị càng tốt với càng ít chi phí càng tốt.

Khi có một value chain như vậy, bạn có thể nhìn từng bước và hỏi: ở đây tôi đo được gì? Theo Ulrik (video đăng ngày 07/07/2023), ở bước đầu ta đo được user, vì họ là team dự án AI. Ở bước kế, có thể đo nguồn dữ liệu, số gigabyte được xử lý, hay gì đó. Ở bước tiếp, có thể đo số model đang production, và có thể đo số credit score hay bất cứ thứ gì đi ra. Đó là các pricing metric tiềm năng, cách bạn tìm ứng viên cho câu hỏi "ta có thể định giá theo gì": quá trình tạo giá trị là gì, ta đo được gì, và có tính giá theo nó được không?

Ý chính cần mang về, theo Ulrik (video đăng ngày 07/07/2023): hãy nghĩ nó như một cầu vồng, vàng nằm ở cuối. Người ta muốn thứ nằm ở cuối value chain. Họ chấp nhận trả cho thứ nằm ở đầu. Đó là lý do có quá trình này: họ nghĩ rằng dù phải trả gì để đi qua nó thì thứ ở cuối chuỗi của họ sẽ tốt hơn. Nên họ chấp nhận trả cho user vì họ muốn vàng. Không phải họ muốn user; họ chấp nhận trả cho user như một điều cần thiết để có vàng.

## 10. Nếu user miễn phí thì sao, và bài tập vẽ value chain

Ulrik phân tích tiếp (video đăng ngày 07/07/2023): 2021.AI định giá ở chỗ này và chỗ này, tức user và model. Vậy chuyện gì xảy ra nếu không định giá ở chỗ user? Anh hỏi những người ngồi cuối phòng: nếu không tính giá theo user thì sao? User miễn phí, cứ thêm bao nhiêu user tuỳ thích. Có nhiều user hơn không? Một người tham dự đáp có. Ulrik: đúng, như 2021.AI, họ sẽ có thêm user. Thêm user thì làm gì? Người tham dự đáp: dùng nhiều dữ liệu hơn, xử lý nhiều dữ liệu hơn. Ulrik: nhiều dữ liệu hơn, và rồi họ tạo ra nhiều model hơn, nhanh hơn, chính là thứ 2021.AI định giá.

Lập luận của Ulrik trong video đăng ngày 07/07/2023: bỏ giá ở bước user để khách đầu tư mạnh hơn vào quá trình tạo giá trị, và chỉ thu ở bước model.

Như vậy, theo Ulrik (video đăng ngày 07/07/2023), ta đã giảm chi phí áp dụng giải pháp cho khách hàng. Họ có thể có bao nhiêu user tuỳ ý, có thể đầu tư mạnh hơn vào quá trình tạo giá trị. Thay vì đánh thuế vào quá trình đó ở phía đầu, tức làm cho việc bắt đầu khó hơn, ta chỉ đánh thuế ở phía cuối: ta chỉ lấy giá trị khi nó thật sự được tạo ra ở cuối.

Ulrik giao cho phòng một bài tập (video đăng ngày 07/07/2023): hãy thử vẽ một phiên bản hai tới năm bước của quá trình tạo giá trị mà bạn có, hoặc mang lại cho khách hàng của mình.

## 11. The plumber problem: hoá đơn ba dòng và time & materials

Rồi Ulrik kể một câu chuyện nhỏ (video đăng ngày 07/07/2023). Ai để ý thì sẽ thấy: trong ví dụ ngân hàng, khi nói có một team, team đó có dữ liệu, train model, rồi có data output, anh đã không gợi ý định giá theo data output. Vì sao không? Vì nó nằm ở cuối chuỗi, đúng không? Đúng, nhưng có một vấn đề. Anh minh hoạ.

Hãy tưởng tượng tối thứ Năm anh đang ở nhà và đột nhiên có nước trong bếp: vỡ ống. Anh lên Google, tìm "emergency plumber", gọi người đầu tiên, và anh ta tới ngay. Vừa lúc anh mở cửa, anh thợ nói: "Anh may đấy, tôi tìm được chỗ đỗ xe ngay dưới phố. Hỏng ở đâu?" Anh đáp: ở bếp, ngập hết rồi. Thợ nói: được, để tôi sửa. Nhưng ngay trước khi bước vào căn hộ, anh thợ để ý thấy thảm và sàn đẹp, liền "à", rồi cởi giày, đi vào và sửa chỗ hỏng trong bếp. Xong anh ta nói: chỉ là một cái O-ring hay gì đó thôi, tôi thay rồi, tôi sẽ gửi hoá đơn. Anh ta về nhà và gửi hoá đơn (câu chuyện Ulrik kể trong video đăng ngày 07/07/2023).

Trên hoá đơn có ba thứ. Ulrik đo ba thứ đó trên hai chiều: giá trị (value) và kỳ vọng trả tiền (expectation to pay) (video đăng ngày 07/07/2023). Ở góc trên là time and materials: anh thợ bỏ thời gian, và có một linh kiện thay thế. Cái đó có giá trị với tôi không, tôi có thật sự muốn nó không? Có. Tôi đã Google "emergency plumber", và tôi kỳ vọng anh ta xuất hiện, có năng lực, và có linh kiện nếu cần.

![Slide Willingness to Pay: Value & Expectation với ba khoản trên hoá đơn thợ sửa ống nước](https://homus.dev/photos/BGb6-WKMNN4-3343.jpg)

Slide "Willingness to Pay: Value & Expectation": trục dọc Value-to-Customer, trục ngang Expectation-to-Pay, bốn ô "High/Low Demand, Prices fair/unfair". €250 Time & Materials nằm ở góc trên bên phải, €8.72 Parking Fee ở dưới bên phải, €10 Shoe Fee ở trên bên trái; ô nhỏ góc dưới là cảnh Ulrik chỉ vào màn hình trong phòng (slide trong video đăng ngày 07/07/2023).

Một người tham dự hỏi lại về con số 250 trên slide, và Ulrik đáp là cả những con số đó nữa. Rồi anh hỏi tiếp về kỳ vọng trả tiền: tôi có kỳ vọng bị tính tiền time and material không? Hoàn toàn có. Nhưng vì sao? Một người tham dự trả lời: vì anh đã dùng một dịch vụ rất cụ thể, phải gọi để hỏi anh thợ có rảnh không để giải quyết được việc; nếu không thì anh đã phải tự đi mua, tự làm cái này cái kia. (video đăng ngày 07/07/2023)

Ulrik chia lý do ra như sau (video đăng ngày 07/07/2023). Một, tôi đã quen trả tiền cho nó: người khác cũng tính time and material với tôi, nên được thôi, ở đây tôi cũng trả. Theo anh, điều này thật ra chạy được trong rất nhiều pricing model. Có thể bạn định giá theo user mà chẳng có lý do gì, nhưng khách hàng vẫn chấp nhận đơn giản vì họ trả tiền theo user ở mọi nơi khác: "được, cái này chúng tôi biết, làm vậy ở đây luôn". Rất nhiều pricing thật ra chạy theo cách đó. Đó chỉ là thói quen (habit).

Hai, anh thợ có chi phí (video đăng ngày 07/07/2023). Anh ta trả bằng thời gian của mình, nên có chi phí cơ hội (opportunity cost): đáng lẽ anh ta có thể ở nhà. Và anh ta phải mua linh kiện mà giờ đưa cho tôi. Vậy có những chi phí rõ ràng chảy qua, mà tôi phải trả để gỡ chúng khỏi anh ta.

Ba, time and materials là một thành phần nhân quả rõ ràng (video đăng ngày 07/07/2023): chúng là lý do việc của tôi được làm xong. Không phải tôi trả tiền cho một linh kiện nào đó anh ta để trong kho, mà là đúng linh kiện anh ta dùng để sửa đồ của tôi. Đó là cái tôi trả tiền. Có một lý do rất rõ vì sao chính thứ này cần để giải quyết vấn đề của tôi. Đó là ba thứ: causal connection, cost và habit.

## 12. Parking fee, shoe fee, và một lần tăng giá 60% không churn

Thứ hai trên hoá đơn là phí đỗ xe (parking fee). Theo câu chuyện của Ulrik (video đăng ngày 07/07/2023), anh thợ phải trả tiền đỗ xe vì anh sống ở một con phố đỗ xe không miễn phí. Hỏi lại cùng những câu: tôi có nhu cầu với nó không? Ít hơn. Đâu phải tôi Google "parking". Nhưng tôi có kỳ vọng trả cho nó không, hay dùng một từ khác: tôi có thấy công bằng khi trả cho nó không? Có chứ. Dùng cùng các tiêu chí: tôi có quen trả tiền đỗ xe không? Vì chỗ tôi sống, tôi thật ra đã quen trả tiền đỗ xe khi gọi thợ sửa ống nước và những người tương tự; thường tôi chỉ nhận vé, vì họ đỗ xe, lấy vé, rồi tôi trả tiền vé. Nó có liên hệ nhân quả với việc họ làm xong công việc không? Có, họ phải đỗ xe ở đâu đó để tới được chỗ tôi. Và họ có chi phí không? Có, họ phải trả tiền đỗ xe, đúng 8 euro 72 xu. Vậy cost, causal connection và habit đều có mặt: mức kỳ vọng trả tiền và mức công bằng cao.

Ulrik áp vào một người tham dự (video đăng ngày 07/07/2023): khi bạn tính tiền theo giờ cho physiotherapy, một lý do khiến người ta sẵn lòng trả là bạn bỏ ra một giờ để làm. Họ cũng rất quen trả tiền theo giờ physiotherapy, nên đó là thói quen. Và physiotherapy có giúp họ giải quyết vấn đề không? Hy vọng là có. Vì thế ta thấy đó là một mô hình công bằng.

Thứ cuối cùng: shoe fee, 10 euro, "dịch vụ giày". Ulrik nói lý do mọi người cười là vì chẳng ai muốn trả cho thứ này, và đó chính là điểm minh hoạ (video đăng ngày 07/07/2023). Hỏi lại các câu: bạn có muốn anh thợ cởi giày không? Có. Đó là một dịch vụ có giá trị; nếu hỏi trong khảo sát, bạn sẽ chấm năm trên năm: tôi rất thích họ đối xử với nhà tôi tử tế, không bày bừa, làm đủ mọi thứ như vậy, ví dụ cởi giày ra. Vậy tôi có nhu cầu. Bạn có muốn trả tiền cho nó không? Không. Tôi thấy nó kỳ cục và bất công, tôi không muốn trả. Tôi sẽ gọi điện cãi về 10 euro chứ không phải 250, vì tôi thấy nó bất công.

Vì sao bất công? Theo Ulrik (video đăng ngày 07/07/2023): bạn có quen trả shoe fee không? Không, nó lạ, tôi chưa từng trả. Hai, nó có liên hệ nhân quả với việc anh thợ mang lại giá trị không? Không phải tôi thấy nó không có giá trị, nhưng việc cởi giày chẳng liên quan gì tới công việc chính là sửa cái ống vỡ của tôi. Anh thợ có chi phí gì khi cởi giày không? Không; nó tốn của anh ta một giây thôi.

Ba khoản trên hoá đơn của anh thợ, chấm theo ba lý do Ulrik nêu cho kỳ vọng trả tiền trong video đăng ngày 07/07/2023; con số lấy từ slide.

Theo Ulrik (video đăng ngày 07/07/2023), parking fee rất tốt, đặc biệt với những khách hàng lớn hơn, những tài khoản lớn như phần mềm enterprise. Họ đã quen trả đủ loại phí và các khoản tương tự.

Anh kể một khách hàng insurtech (theo lời anh, video đăng ngày 07/07/2023). Khi anh bắt đầu làm với họ, họ có khoảng 60 triệu krone Đan Mạch ARR trên khoảng 30 khách hàng, tức 30 công ty bảo hiểm. Và anh và nhóm đã tăng giá 60%, lên khoảng 100 triệu trên đúng 30 khách hàng đó, đơn giản bằng cách thêm phí hạ tầng (infrastructure fees), vì trước đó họ chưa có khoản nào như vậy. Giá lúc đó tính theo claim, theo mỗi hồ sơ bồi thường bảo hiểm. Nhưng rồi anh và nhóm nói với khách: bên anh chị còn có rất nhiều data storage, rất nhiều nguồn dữ liệu bên thứ ba, license, integration, và đủ thứ mà phòng IT của anh chị hiểu rõ và vốn đang trả tiền; giờ chúng tôi cũng sẽ tính tiền cho những thứ đó, và đó là phần giá tăng thêm.

Giá lõi theo claim, nằm ở phía trên, về cơ bản giữ nguyên (theo Ulrik, video đăng ngày 07/07/2023). Anh và nhóm chỉ bắt đầu tính thêm tất cả các "parking fee": hạ tầng và những thứ tương tự. Một phần vì đó là một ngân sách khác, nhưng cũng vì với khách hàng điều đó quá hợp lý: những thứ này chúng tôi đã quen trả, chúng có chi phí rõ ràng với bên bán, và tất nhiên là thứ cần thiết để mang lại giá trị cho chúng tôi, nên tất nhiên phải trả. Thế là khách trả. Anh nói anh và nhóm đã tăng giá 60% mà không có churn.

## 13. Onboarding, platform fee và module

Một người tham dự hỏi: nếu dùng mô hình anh đưa ra lúc trước, với giá bắt đầu và giá kết thúc, để đưa vào một số thứ, thì sao? Chị kể bên chị đang nghĩ tới việc tuỳ biến dashboard: khi onboard một khách hàng, cần tạo một không gian cho công ty đó với logo và vân vân, đó là phần khởi đầu. Vậy nó nằm ở đâu trong sơ đồ? Ulrik hỏi lại: chị đang nói tới slide có toàn bộ pricing architecture phải không? Chị xác nhận đúng. Ulrik nói, lạ là slide đó lần nào cũng thu hút sự chú ý của mọi người, rồi quay lại slide ấy. (video đăng ngày 07/07/2023)

Câu trả lời của Ulrik (video đăng ngày 07/07/2023): chắc chắn bạn có thể có onboarding fee. Rồi có thể có platform fee cho toàn bộ dashboard và những thứ bạn đưa cho ai cần xem dashboard. Và có lẽ có thể có một mô hình credit, chẳng hạn cho việc chạy các chứng chỉ (certifications): "công ty anh chị có 10.000 nhân viên, vậy cần 10.000 credit để đạt mức tuân thủ tối thiểu, nhưng chúng tôi gợi ý 20.000 nếu muốn đạt benchmark này", vân vân. Rồi bên bán đưa ra các lựa chọn đó, làm toàn bộ phần marketing nội bộ, và ban lãnh đạo, phòng HR, bộ phận compliance hay bất kỳ ai có thể ngồi xem dashboard, thấy bên bán làm gì và xuất báo cáo ra. Đại loại như vậy.

Người tham dự nói chị đang cố nối điều này với "trò chơi" anh vừa cho xem: có thể lấy vài thứ, như data output, đặt nó vào đâu đó và nói "đây là exit cost" hoặc "đây là start cost" không? Kiểu: tôi biết anh chị không thích, tôi biết anh chị không muốn trả, nhưng nó cứ nằm đó, chúng tôi làm việc như vậy; và nếu anh chị muốn những thứ hay ho khác thì cần trả cho... (video đăng ngày 07/07/2023)

Ulrik trả lời (video đăng ngày 07/07/2023): với mỗi thứ có kỳ vọng trả tiền, việc để nó là flat fee hay phí theo metric phần nào phụ thuộc vào nó là gì. Nó có thật sự tăng theo khối lượng không, hay chỉ là thứ bạn muốn đưa vào? Với phần mềm enterprise, đôi khi anh đặt một platform trước khi khách có bất kỳ chức năng dùng được nào. Anh nói với khách: platform chỉ là nơi chứa toàn bộ dashboard và analytics, có mọi integration, có user management, và mọi thứ khác về bản chất là tính năng chung (generic features), chẳng liên quan gì tới việc bên bán thật sự làm. Rồi bạn có thể mua các module, nơi bên bán thật sự làm việc, như làm phần sustainability, vân vân.

Platform fee khi đó, theo Ulrik (video đăng ngày 07/07/2023), về bản chất trở thành một flat fee trong mô hình để nâng mọi khách hàng lên. Còn những gì trong module thì tăng theo khối lượng, theo nhân viên hay theo chứng chỉ, tuỳ trường hợp. Bạn cũng có thể tính onboarding fee: platform onboarding, onboarding training cho cấp quản lý cao, bất cứ gì.

## 14. Gộp hay tách phí, và wallet structuring

Một người tham dự khác hỏi về câu chuyện anh thợ: nếu phí giày và phí đỗ xe là những con số lớn hơn thì gộp tất cả lại sẽ khiến người ta hỏi vì sao time and materials đắt thế. Nhưng khi chỉ là những con số nhỏ như hiện tại, có phải tốt hơn là gửi một hoá đơn chỉ ghi gộp một dòng time and material là xong, để anh thợ khỏi gặp rủi ro khách hỏi "sao tôi lại phải trả shoe fee"? (video đăng ngày 07/07/2023)

Ulrik đáp (video đăng ngày 07/07/2023): đúng, nhưng tới một lúc nào đó con số gộp sẽ thành quá nhiều, vì khi đó anh bắt đầu so sánh (benchmark) nó: thời gian nào, vật tư nào? Tách ra làm tăng pricing power. Anh lấy một ví dụ mà người hỏi có thể áp vào trường hợp của mình. Giả sử bên bán nói: chúng tôi có một platform fee, nơi làm toàn bộ dashboard, hạ tầng, integration, nguồn dữ liệu bên thứ ba, benchmarking, và anh chị có thể làm báo cáo, vân vân. Platform fee đó, anh không biết, chẳng hạn 30.000 euro một năm, anh chỉ bịa ra một con số. Rồi tính giá theo credit học tập: các khoá cơ bản tốn một credit, các khoá nâng cao tốn ba credit, thế thôi. Và chỉ tính tiền cho người thật sự hoàn thành khoá.

Khi đàm phán mô hình này với khách hàng, theo Ulrik (video đăng ngày 07/07/2023), điều thường xảy ra về mặt tâm lý là khách sẽ tập trung vào giá mỗi credit, nhất là ở khối lượng lớn, và thường để yên platform. Nghĩa là một phần lớn hơn trong giá của thương vụ enterprise này bị để ra ngoài cuộc mặc cả, nhất là khi phần đó có kỳ vọng trả tiền rất cao, có chi phí rõ ràng, vân vân.

Đôi khi việc này tinh vi hơn một chút, nhưng đó là một khái niệm Ulrik gọi là wallet structuring (video đăng ngày 07/07/2023): bạn chia giá thành các thành phần nói chuyện với những ngân sách khác nhau trong tổ chức. Phần này nói với phòng IT: toàn đồ IT, gigabyte, API call, nguồn dữ liệu, những thứ họ vốn đã quen trả. Họ có ngân sách cho chúng và sẽ nói: được, phải có ai trả cho mấy thứ này, rõ ràng là chúng tôi, chúng tôi lo. Rồi có phần về training, có thể đặt vào phòng HR hay bộ phận sustainability; họ có ngân sách cho nó và cần thấy được nó. Làm như vậy, theo anh, bạn thật sự có thể thu được nhiều tiền hơn.

Wallet structuring theo mô tả của Ulrik trong video đăng ngày 07/07/2023: chia giá thành các thành phần ứng với những ngân sách khác nhau trong tổ chức khách hàng.

Ulrik lấy ví dụ một người tham dự làm sự kiện (video đăng ngày 07/07/2023): khách hàng của người này nhiều khả năng có các ngăn ví nội bộ cho ăn uống, cho giải trí, cho những thứ khác. Giả sử bạn tổ chức một sự kiện, và nếu thêm bữa tối vào sự kiện đó thì bạn có thể tính nhiều hơn. Bạn nói: triển lãm và buổi nói chuyện là, chẳng hạn, 200 krone; chúng ta sẽ có một tour riêng, vân vân, rồi tất cả gặp nhau ăn tối sau đó ở nhà hàng đẹp này, trọn gói 800 kể cả rượu vang. Ồ, tuyệt. Hoặc bạn có thể nói: 500, muốn có rượu vang thì thêm 300. Vì người ta có những "xô" khác nhau cho những thứ họ muốn trả tiền.

Kiểu: sự kiện chỉ 200 thôi, nhưng có muốn ăn tối luôn không? Được chứ. Và họ biết đại khái một bữa tối nên tốn bao nhiêu với phân khúc của họ, nên họ vui vẻ đồng ý. Rồi bạn thuê phòng ăn riêng ở nhà hàng, đàm phán một giá tốt hơn, kiếm thêm một chút từ đồ uống, vân vân. Ulrik cho rằng (video đăng ngày 07/07/2023) đây là cách mà ngay cả ở quy mô nhỏ, với những khách hàng nhỏ, ta có thể hỏi: họ quen trả cho cái gì, và làm sao khai thác được những thứ đó?

Với một người tham dự khác, theo Ulrik (video đăng ngày 07/07/2023), có thể tính một khoản giá theo mỗi phòng marketing như một flat fee, rồi một khoản giá theo mỗi impression hay mỗi tương tác. Bên bán nói: chúng tôi cần onboard anh chị đúng cách, cần có customer support, cần phản hồi được, cần có integration, cần thiết lập nguồn dữ liệu, vân vân. Phần đó chỉ là một chi phí cố định, và anh chị cứ trả, mức thấp, hay nói là hợp lý. Rồi anh chị trả cho hiệu quả (performance) ở phía trên. Người tham dự đó nói như vậy là hợp lý.

## 15. Con số phải hợp lý, và câu hỏi "trên hay dưới đường"

Quay lại câu hỏi gộp phí, Ulrik nói (video đăng ngày 07/07/2023): nếu time and materials là, chẳng hạn, 600 euro, còn shoe fee của anh thợ chỉ là một euro rưỡi, thì có lẽ tốt hơn nên gộp chúng lại, để khách không bực mình vì phải trả một euro rưỡi. Nhưng vì tỷ lệ ở đây giống thế này hơn...

Rồi còn chuyện con số có hợp lý không, theo Ulrik (video đăng ngày 07/07/2023). Nếu bạn bán API call, bạn không thể tính một euro mỗi API call, vì người trả tiền cho API call đã rất quen với một khoảng giá rất cụ thể. Anh xin lỗi người tham dự làm sự kiện vì cứ bịa sản phẩm cho người đó, nhưng người đó không thể đẩy giá bữa tối lên chỉ vì gói thêm chuyến đi thuyền, vì người ta biết họ muốn trả bao nhiêu cho bữa tối. Bạn phải hiểu những điều này và nói: đây là mức tôi tính được, vì khách sẽ đánh giá theo từng dòng một (line-by-line). Nhưng cái họ đôi khi lại không làm, theo anh, là đánh giá tổng chi phí sở hữu (total cost of ownership) so với kết quả, xuyên qua các ngân sách và các bên liên quan khác nhau.

Ulrik quay lại ma trận value và expectation cho trường hợp của một người tham dự (video đăng ngày 07/07/2023). Có một user, có thể nằm ở đây, có thể ở đây, nhưng đại loại là dưới đường này. Một user đã làm vài khoá training thì đi lên. Một user đã làm training tốt thì đi lên thêm chút nữa. Những khác biệt nhỏ đó, và đó là lý do có thể chứng chỉ, tức những khoá training đã hoàn thành, nằm cao hơn user của người này.

Theo Ulrik (video đăng ngày 07/07/2023), nếu bạn đang tự hỏi thứ của mình nằm trên hay dưới đường này, bạn nên hỏi: khách hàng của tôi có tự nhiên muốn nhiều thứ này hơn không, chỉ vì thích thế? Nếu tôi bỏ giá đi, họ có tự bùng nổ về khối lượng không, hay vẫn vậy? Một người tham dự trả lời rằng họ sẽ muốn nhiều hơn. Ulrik nói: những thứ ở dưới này chỉ là kiểu "được, tôi cần hoặc tôi không cần". Anh cho rằng SSO và mọi thứ tương tự nằm ở đây. Người ta biết họ muốn trả cho nó: "chúng tôi không nhất thiết muốn nó, nhưng phải có ai trả, chúng tôi rất quen trả cho nó, nó là thành phần cần thiết để mang lại giá trị, ổn thôi, cứ đưa chúng tôi những thứ đó".

Với người tham dự đó, theo Ulrik (video đăng ngày 07/07/2023), việc cần làm là tìm ra một thứ mà khách thật sự nói "ồ, chúng tôi làm thêm cái đó được không?". Người tham dự đó kể: chính user là thứ khách hàng của chị tới mặc cả. Họ muốn lấy flat fee nếu được, vì họ tới và nói "nhưng chúng tôi không biết mình có bao nhiêu user". Và chị kể chị đã hỏi lại: vậy anh chị có muốn họ đi học hay không?

## 16. Một mô hình credit cho khoá training đã hoàn thành

Ulrik đưa ra một mô hình khác, và tự nói có lẽ anh đang gõ mãi một cái trống, mọi người cứ bảo anh nếu vậy (video đăng ngày 07/07/2023). Giả sử việc bạn làm là cung cấp training dưới một hình thức nào đó. Ta lùi trong value chain về khoá training đã hoàn thành, và bán credit cho cái đó. Bạn nói với khách: chúng tôi không quan tâm anh chị có bao nhiêu user; chúng tôi cũng không biết, nhưng biết đại khái: anh chị có hơn 1.000, nhưng có lẽ ít hơn 3.000. Được, bắt đầu từ đó. Chúng tôi sẽ đưa anh chị 1.000 credit, hay 100, bao nhiêu cũng được, một lượng đủ để bắt đầu. Năm sau chúng tôi bán thêm 100 nữa. Đó là subscription: mỗi năm anh chị nạp thêm credit. Cần nhiều hơn thì báo, năm sau chúng tôi bán 200 nếu anh chị tăng subscription. Vậy đó là usage-based pricing trả trước.

Nếu khách không dùng hết 100 credit, theo Ulrik (video đăng ngày 07/07/2023), bên bán sẽ có một cuộc trò chuyện, từ góc nhìn customer success thông thường, xem có chuyện gì, vì cả hai bên đều có lợi khi khách dùng giải pháp. Bên bán muốn biết có thể làm gì để tạo thêm giá trị cho khách không. Nhưng nếu khách chỉ đơn giản có ưu tiên khác, bên bán lấy số credit chưa dùng và chuyển sang năm sau (roll over). Giả sử chuyển sang 20 credit và nhận 100 credit mới, vậy khách có 120. Những gì năm nay chưa có thời gian làm, năm sau có thể làm bù. Nó hoạt động như vậy.

Ví dụ roll over credit của Ulrik trong video đăng ngày 07/07/2023: 20 credit chưa dùng cộng 100 credit mới thành 120.

Điều ta cố đạt được ở đây, theo Ulrik (video đăng ngày 07/07/2023), là tới một chỗ mà người ta nói: tôi thấy công bằng khi trả cho nó, vì tôi sẽ không bao giờ trả cho thứ tôi không dùng. Đó là vấn đề của giá theo user mỗi năm: tôi trả cho một user, nhưng có thể họ chẳng làm gì cả, thế là tôi phí tiền. Vậy kỳ vọng trả tiền tăng lên. Thêm nữa, đơn vị ta đang hướng tới thật ra không phải user mà là kết quả của việc đã hoàn thành một thứ gì đó, chính là thứ ta tính credit.

Ulrik nói tiếp (video đăng ngày 07/07/2023): bạn có thể nói "tôi có thể cho 100 người đi qua khoá training rồi trượt, và như vậy là miễn phí". Được thôi, đó là lỗi của bên bán, bên bán cần làm khoá training tốt hơn. Nhưng nếu họ hoàn thành, bên bán làm những việc này; và nếu họ hoàn thành, thì ở phần platform fee bên dưới, khách có thể làm mọi báo cáo, vân vân, và bên bán sẽ giúp về employee branding. Anh nói người tham dự có thể tự nghĩ ra bước tiếp theo.

Theo Ulrik (video đăng ngày 07/07/2023), đây có lẽ là một mô hình dễ hơn cái người tham dự đang có hôm nay, nơi chị cố nói với khách "anh chị cần mua 3.000 user trả trước", và khách nói "ừm, có lẽ không". Vì họ muốn thử và xem giá trị ở đâu. Anh hỏi như vậy có hợp lý không; người tham dự đáp có.

## 17. Metric density: ca Lyfegen

Ulrik nói anh muốn dành khoảng mười phút cho phần cuối của việc chọn pricing metric (video đăng ngày 07/07/2023). Anh nhắc lại bốn chiều tiêu chí: một, bạn đo được nó; hai, thật sự có nhu cầu với nó; ba, nó công bằng, hay có kỳ vọng trả tiền; và thứ tư là nó dày (dense) tới mức nào. Như anh đã nói trước đó với ví dụ mã sản phẩm, một sản phẩm có thể là hàng khối lượng lớn với nhiều doanh thu trong đó, hoặc là sản phẩm rất nhỏ, nên density khác nhau. Còn Stripe có density hoàn hảo vì tính trên đồng đô la đi qua, và một đô la giống hệt đô la tiếp theo.

Ulrik kể về một khách hàng Thuỵ Sĩ tên là Lyfegen, nơi anh cũng là nhà đầu tư (theo lời anh, video đăng ngày 07/07/2023). Họ có một phần mềm nằm giữa bệnh viện, công ty dược và công ty bảo hiểm. Công ty bảo hiểm trả tiền khi bệnh viện mua thuốc từ công ty dược: ví dụ Pfizer bán thuốc giảm đau cho một bệnh viện, rồi hệ thống bảo hiểm quốc gia trả tiền cho khoản đó, phần bảo hiểm y tế.

Cách thuốc được bán, theo Ulrik (video đăng ngày 07/07/2023), là ngày đầu tiên bán với giá đầy đủ. Rồi có chiết khấu, và chiết khấu có thể vận hành theo nhiều cách: có thể là chiết khấu theo khối lượng, nhưng cũng có thể là chiết khấu kiểu "thuốc không hiệu quả như kỳ vọng". Anh nói rất nhiều thuốc điều trị ung thư được định giá tuỳ theo bệnh nhân sống được bao lâu: nếu bệnh nhân mất ngay, việc điều trị miễn phí; nếu sống hơn 40 ngày thì tốn một mức; sống hơn nửa năm thì tốn mức khác. Anh nói thực tế nó vận hành như vậy. Nhưng ngày đầu họ trả giá đầy đủ, như thể bệnh nhân sẽ hồi phục hoàn toàn. Rồi khi bệnh viện không may mất bệnh nhân ngay, họ tới hỏi công ty dược đòi hoàn khoản chiết khấu: các anh bán cho chúng tôi giá đầy đủ, nhưng theo hợp đồng, chúng tôi chỉ trả mức này khi bệnh nhân chỉ sống được chừng này. Trong ngành dược, anh nói, cái này gọi là value-based contracts. Lyfegen dựng nền tảng xử lý toàn bộ luồng dữ liệu và việc hoàn tiền giữa các bên đó.

![Slide Lyfegen Payer Value Chain từ Pharma Contract Team tới Reimbursement Claim](https://homus.dev/photos/BGb6-WKMNN4-4443.jpg)

Slide "Lyfegen: Payer Value Chain": từ INPUT tới OUTPUT có năm bước (Pharma Contract Team, Pharma Contracts Made, Treatments Happen với ghi chú "Payee invoices Payer", Track & Measure, Reimbursement Claim), bên dưới là các metric như # Users, # Contracts, # Claims, # Patients, #Contract$value, #Claims$Value, # Data Outputs, #Reimbursement $Value, #Invoices (slide trong video đăng ngày 07/07/2023).

Lại là input và output, theo Ulrik (video đăng ngày 07/07/2023). Có những thứ họ thật ra không đo được tốt lắm, nhưng có những thứ họ làm được; họ đo được rất nhiều thứ. Anh và nhóm đã làm đúng bài tập mà cả phòng vừa làm, và đặt các metric vào một sơ đồ như thế này, với value, fairness và các tiêu chí kia. Tới đây vẫn ổn. Họ nghĩ: giá theo bệnh nhân rất hợp lý, khách hàng biết họ có bao nhiêu bệnh nhân, họ đếm được, tuyệt. Khi nói chuyện với những người làm tài chính ở công ty bảo hiểm, họ thấy giá theo claim hay theo hoá đơn cũng rất tốt vì rất dễ đo, và họ vốn xử lý những thứ đó.

Nhưng nó có vấn đề. Theo Ulrik (video đăng ngày 07/07/2023), ở Thuỵ Sĩ, thị trường sân nhà của Lyfegen, có một công ty bảo hiểm rất lớn xử lý khoảng một triệu hồ sơ bảo hiểm, hồ sơ y tế mỗi năm, tức một triệu bệnh nhân. Giá trị trung bình của một hồ sơ hoàn tiền là 20 euro, nên mỗi năm có 20 triệu euro được các công ty dược hoàn lại. Nhưng giá trị bị lệch rất, rất mạnh. Trong một triệu đó, 700.000 hồ sơ có giá trị bằng không, không có khoản hoàn nào. Và ở một số rất ít hồ sơ, khoản hoàn lên tới một triệu euro. Vậy là một phân phối giá trị theo kiểu power law 80-20 cực mạnh trong tập bệnh nhân này: rất ít bệnh nhân chiếm phần lớn giá trị, còn phần lớn bệnh nhân có giá trị bằng không.

![Biểu đồ Lyfegen Pricing Metric Evaluation: share of total value và share of metric units theo giá trị mỗi đơn vị](https://homus.dev/photos/BGb6-WKMNN4-4623.jpg)

Slide "Lyfegen: Pricing Metric Evaluation": hai trục Share of total value và Share of #Metric Units, trục ngang #Metric Unit Value từ $0 tới $1M. Cột ở $0 cao gần 70% (phần lớn số đơn vị), còn cột ở $1M cao khoảng 50% (phần lớn giá trị) (slide trong video đăng ngày 07/07/2023).

Vậy nếu dùng giá trị trung bình mỗi bệnh nhân và nói "giá trị là 20 euro, có lẽ ta tính 5, hay 2, gì đó", tức lấy một phần của mức trung bình, thì theo Ulrik (video đăng ngày 07/07/2023), dù tính bao nhiêu ở đây, công ty bảo hiểm sẽ nhìn giá và nói: 2 euro mỗi bệnh nhân; chúng tôi có 700.000 bệnh nhân giá trị bằng không, vậy có thể tiết kiệm 1,4 triệu nếu không đưa luồng đó cho các anh, nếu tìm được cách chỉ gửi qua 300.000 hồ sơ thật sự có giá trị.

Theo Ulrik (video đăng ngày 07/07/2023), đây là điều xảy ra khi pricing metric rất không dày: khách hàng, nếu đủ tinh vi, sẽ bắt đầu tìm cách lọc khối lượng của họ để bạn chỉ nhận một phần. Anh hỏi cả phòng có hiểu không. Nếu bạn không có vấn đề này, có lẽ bạn sẽ nghĩ "tôi hiểu về mặt khái niệm, nhưng tôi không quan tâm". Nhưng nếu bạn có vấn đề này, đôi khi đây là lúc bóng đèn bật sáng trong đầu, vì pricing model của họ: "à, ra là chuyện đó, đó là lý do chúng tôi không làm được".

## 18. Làm metric dày hơn: lùi trong value chain, và hai kiểu phân phối

Theo Ulrik (video đăng ngày 07/07/2023), một phần vấn đề này được giải bằng cách đi lùi dần trong value chain. Giá theo user, hay theo nhân viên trong trường hợp của một người tham dự, khá không dày (undense). Nhưng giá theo user đã được training, hay theo chứng chỉ, thì dày hơn, vì nó thật sự lọc bỏ những người không dùng phần mềm. Ngay ở đó ta đã làm nó dày hơn, và ta cũng đang lùi thêm một chút trong value chain, nên mọi thứ ở đây đều ổn.

Đôi khi bạn cũng thấy, theo Ulrik (video đăng ngày 07/07/2023), nếu lấy một thứ là license, tức "tôi có quyền dùng một thứ", so với "tôi đã dùng nó": tôi có quyền dự một buổi physiotherapy, hoặc tôi đã dự một buổi physiotherapy. Có thể density của "tôi thật sự đã dùng" cao hơn. Nên tôi sẵn lòng trả nhiều hơn cho nó, vì: ồ, không tới thì không trả, tới thì trả. Tuyệt, vậy tôi không phải tính nhẩm trong đầu tất cả những lần tôi sẽ không tới, những lần tôi không muốn trả. Về mặt cảm xúc tôi muốn được giảm giá cho những lần đó, vì tôi cảm thấy mình sẽ hối hận vì đã mua những buổi mà mình không tới. Đó là chuyện đang diễn ra.

Ulrik nói (video đăng ngày 07/07/2023) thường có hai kiểu phân phối có thể làm ta vấp. Một là kiểu này, khi có power law. Kiểu kia là khi phạm vi giá trị chỉ đơn giản là rất rộng: giống một đường cong hình chuông, nhưng là một đường cong chuông rất dẹt.

![Slide Lyfegen Pricing Metric Evaluation: các metric đặt trên trục value-to-customer và fairness, bong bóng lớn là good density](https://homus.dev/photos/BGb6-WKMNN4-4943.jpg)

Slide "Lyfegen: Pricing Metric Evaluation": các metric đặt trên hai trục Value-to-Customer và Fairness; chú thích ghi bong bóng lớn là Good Density, bong bóng nhỏ là Poor Density, màu theo Line of Business, CIO, Finance. % Reimbursements và %Total Contract Value / #Claims$value là bong bóng lớn; #Patients, #Invoices, #DataPoints ?, # Users là bong bóng nhỏ (slide trong video đăng ngày 07/07/2023).

Ulrik giải thích cách anh vẽ (video đăng ngày 07/07/2023): thường anh lấy các metric này và vẽ chúng to hơn nếu có density tốt. Anh nói một người tham dự đã về trước, nhưng metric của người đó cũng sẽ nằm ở trên này: khối lượng giao dịch tính bằng tiền thường có density cực tốt, vì khách hàng kiếm được bao nhiêu thì bạn kiếm một phần trong đó.

Một người tham dự hỏi vì sao anh dùng từ density, cái gì là dày? Ulrik đáp: nếu một thứ có giá trị rất mơ hồ, vì nó có thể là rất nhiều thứ, thì anh chỉ thấy là nó rất không dày. Anh nói thêm: anh không biết nữa. (video đăng ngày 07/07/2023)

## 19. Pricing validation: product in PowerPoint

Theo Ulrik (video đăng ngày 07/07/2023), pricing validation diễn ra như sau. Nếu bạn ở bối cảnh B2C thì có thể hơi khác, nhưng cứ nghe anh nói. Nói chung việc bạn muốn làm là tạo ra pricing mới. Nếu chưa có sản phẩm, bạn chỉ việc tạo pricing, cái đầu tiên bạn sẽ dùng. Rồi bạn nói: trước khi bắt đầu bán ra thị trường, tôi muốn biết nó có chạy không. Đó là cái anh gọi là validation phase. Validation phase không phải là bài test bán hàng khi bạn thật sự cố bán cho ai đó; nó là bước trước đó, khi bạn chỉ hỏi: cái này có đứng được không (does this have legs), người ta có hiểu nó không, vân vân.

![Slide SaaS Pricing: Validation of New Pricing, hai loại internal và external](https://homus.dev/photos/BGb6-WKMNN4-5103.jpg)

Slide "SaaS Pricing: Validation of New Pricing, Two Kinds". Internal: Functions ("What would happen for you if we launched tomorrow?", "Communication, Decision, Issues."). External: Customers ("Feedback - not Sale", "Product in a power point", "Sequence is king.", "Great Sales-training") (slide trong video đăng ngày 07/07/2023).

Có hai loại, theo Ulrik (video đăng ngày 07/07/2023). Nếu bạn là một tổ chức lớn, bạn cũng cần làm internal validation, nghĩa là đi tới mọi người trong tổ chức để xem bạn có làm được không. Vì CEO có thể nghĩ ra pricing trong kỳ nghỉ, nhưng nếu nó không deploy được vào sản phẩm, nếu CFO không lập hoá đơn được, vân vân, thì có vấn đề. Anh cho rằng mọi người trong phòng đều đủ nhỏ để chuyện đó không thành vấn đề, nên tập trung vào phía khách hàng.

Cách làm, theo Ulrik (video đăng ngày 07/07/2023): bạn tạo một file PowerPoint, cái anh gọi là "product in PowerPoint". Slide một, bạn ghi tên công ty. Slide hai, bạn ghi job to be done mà bạn giải quyết cho khách hàng. Ví dụ: "chúng tôi giúp các nhà sản xuất nhỏ bán được nhiều hơn bằng cách cho thấy nỗ lực sustainability của họ", anh nói đó là cho một người tham dự. Hoặc: "chúng tôi giúp người cao tuổi có thời gian rảnh vui hơn, dễ chịu hơn". Bất cứ cách nào bạn muốn chốt nó.

Đây là câu tagline duy nhất đưa khách hàng qua cửa, theo Ulrik (video đăng ngày 07/07/2023). Nếu khách hàng không kết nối với câu này thì bạn không cần cho họ xem phần còn lại của bài trình bày. Đơn giản vậy thôi. Nếu khách kiểu "ừ, thì sao?", bạn cần quay lại và tìm một nguồn nhu cầu (source of demand). Còn nếu bạn nói "chúng tôi giúp người cao tuổi hết đau ngay tại nhà mình", khách sẽ: "ồ, tuyệt, giờ tôi đang nghe đây, tôi muốn nghe thêm, các anh làm thế nào, đó là gì?"

Slide tiếp theo là packaging, theo Ulrik (video đăng ngày 07/07/2023). Bạn nói: chúng tôi có một platform, rồi có module này, module này, có dịch vụ này, rồi onboarding, bất cứ gì. Hoặc: chúng tôi có thể làm các gói 12 buổi điều trị, hoặc subscription liên tục, hoặc từng buổi lẻ, bất cứ thứ gì bạn có. Cứ cho họ xem cái gì đang được bán, đơn giản vậy. Bạn không cho xem giá, nhưng cho xem cái gì đang được bán.

Rồi bạn hỏi họ hai câu, theo Ulrik (video đăng ngày 07/07/2023). Có rõ không, anh chị có hiểu tôi đang cố cho anh chị xem gì không? Và hai, anh chị có muốn nó không, hay có muốn thứ gì trong này không? Phải là hai điều đó. Khách hàng cần hiểu rõ bạn đang cố bán hay cho họ xem gì, vì nếu không, sẽ kiểu "cái quái gì đây, mấy feature này là gì, các anh đang cố làm gì vậy", và khi đó họ sẽ chẳng bao giờ mua. Vậy nó phải rõ. Rồi họ cần kiểu "ồ, gói thứ hai có lẽ là cho tôi" hay "có lẽ tôi bắt đầu từ đó", bất cứ gì họ nói, nhưng họ phải kết nối với ít nhất một gói, tức gói giải quyết được cái job bạn đã cho xem đầu tiên. Họ lấy cái job đó và nói: để giải quyết nó, tôi sẽ chọn phiên bản này trong những gì anh chị giao.

## 20. Cho xem pricing model, rồi price point, rồi im lặng

Rồi bạn chuyển sang pricing model. Theo Ulrik (video đăng ngày 07/07/2023), ở bước này bạn cho xem cách tính giá mà không có con số, ví dụ: chương trình 12 buổi là một khoản phí cố định cho 12 buổi, dùng được trong một năm và tính giá theo tháng. Nhưng bạn không nói ra con số giá đã chọn; bạn bỏ price point ra ngoài. Bạn cho họ xem mô hình, cho xem cách trả tiền: đó là giá theo một thứ gì đó, giá theo mỗi ngôn ngữ, mỗi flashcard, mỗi học viên, bất cứ gì; hoặc giá theo mỗi sự kiện với mọi phần thêm như bữa tối và chuyến đi; hoặc với platform thì có một flat fee, còn với các tương tác thì có phí theo khối lượng; bất cứ thứ gì bạn tính tiền. Hay: chúng tôi tính theo một tỷ lệ phần trăm doanh thu trên platform. Nhưng không cho xem con số, chỉ cho xem cách.

Rồi bạn hỏi: anh chị thấy cái này có hợp lý không, có công bằng không? Theo Ulrik (video đăng ngày 07/07/2023), "công bằng" (fair) là từ khoá kích hoạt ở đây. Khách hàng sẽ nói kiểu: "nhưng thế thì tôi chẳng biết mình sẽ trả bao nhiêu". Được, đó không phải chuyện đắt hay rẻ, đó là chuyện của chính mô hình: họ không biết sẽ trả bao nhiêu vì, như họ nói, dù là $1 hay $10 thì họ vẫn không biết mình có bao nhiêu đơn vị. Đó là vấn đề. Hoặc họ sẽ nói: "nghe hoàn toàn công bằng, nhưng ngân sách đó lúc này rất eo hẹp, vì chúng tôi sẽ tính nó vào phần HR". Vậy là họ cho bạn biết họ sẽ hạch toán ở đâu, có thể ở đó họ có những ràng buộc nhất định, hoặc họ nói điều gì khác. Chỉ riêng phản ứng của họ với cách bạn sẽ tính giá đã cho bạn rất nhiều hiểu biết về việc họ có thể, hay sẽ muốn, trả cho cái này hay không.

Thứ tự các slide trong "product in PowerPoint" theo Ulrik (video đăng ngày 07/07/2023); slide của anh ghi "Sequence is king."

Cuối cùng, theo Ulrik (video đăng ngày 07/07/2023), bạn cho xem price point thật. Bạn nói: sẽ là $3.000 cho gói sự kiện sáu lần, hoặc $6.000 cho gói 12 lần, hay gì đó; hoặc 49 euro mỗi tháng cho flashcard không giới hạn; hoặc bao nhiêu đó mỗi sự kiện, vân vân. Bạn chỉ việc nói giá. Nếu hiểu rõ khách hàng, bạn có thể tính sẵn giá cho họ: "nếu chọn cái này thì anh chị sẽ trả chừng này; nếu có chừng này impression trên platform và 17 triệu sản phẩm hay gì đó, anh chị sẽ trả chừng này mỗi năm", vân vân.

Và rồi bạn im lặng (shut up). Theo Ulrik (video đăng ngày 07/07/2023), bạn không bắt đầu tranh luận cho nó, kiểu "và đó thật ra chỉ bằng một nửa tổng chi phí hiện giờ của anh chị". Im lặng. Cứ đưa giá rồi im lặng. Rồi lắng nghe. Vì điều tiếp theo sẽ xảy ra nếu bạn im lặng là khách hàng sẽ cố tìm hiểu giá đó cao hay thấp bằng cách tìm một thứ khác để so sánh. Không có giá nào tự nó cao hay thấp; giá chỉ có ý nghĩa khi được so với một thứ khác.

Ví dụ của Ulrik (video đăng ngày 07/07/2023): nếu bạn tính $500 mỗi tháng, khách có thể nói "ồ, cái đó vượt quá khả năng chi của tôi". Họ chưa nói gì về việc nó có đáng hay không; chuyện đó thậm chí chưa nằm trong tầm nhìn của họ, họ chỉ có thể nói "tôi không chi nổi". Hoặc nếu bạn báo một mức giá mỗi buổi, họ có thể nói "nhưng chuyên viên physiotherapy kia của tôi lấy rẻ hơn". Vậy là giờ bạn đang bị so với một dịch vụ khác. Tuỳ vào thứ họ đang so, theo anh, thứ đó về bản chất chính là đối thủ cạnh tranh của bạn, vì đó là phương án thay thế mà bạn đang bị đem ra so sánh.

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

- Tên gốc: SaaS Pricing Architecture (Full Training)
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=BGb6-WKMNN4](https://www.youtube.com/watch?v=BGb6-WKMNN4)

- Kênh YouTube Willingness to Pay (Ulrik Lehrskov-Schmidt): [youtube.com/channel/UCPsiSZ0K6iETeXno8PJmgDg](https://www.youtube.com/channel/UCPsiSZ0K6iETeXno8PJmgDg)

- [2021.AI](https://2021.ai), công ty có nền tảng GRACE AI Platform nhắc tới trong ví dụ bảng giá (trang chủ, đọc ngày 02/11/2026): [2021.ai](https://2021.ai/)

- Lyfegen, công ty healthtech làm phần mềm quản lý pricing và rebate cho payer và pharma theo mô tả trên trang chủ (đọc ngày 02/11/2026): [lyfegen.com](https://www.lyfegen.com/)

Nguồn: https://homus.dev/talks/saas-pricing-architecture-full-training · cập nhật 2026-11-03