Sáu thành phần của một SaaS pricing model

1. Vì sao cần một bộ khung và ngôn ngữ cho SaaS pricing model

Ulrik Lehrskov-Schmidt mở đầu bằng nhận xét rằng có rất nhiều nhầm lẫn quanh chuyện SaaS pricing model, và anh muốn dành thời gian để làm rõ tất cả (video đăng ngày 04/03/2024). Về xuất thân, anh nói mình là một pricing consultant, đã làm hơn 100 dự án khác nhau cho B2B SaaS ở châu Âu, châu Á, Mỹ, Nam Mỹ, gần như ở khắp nơi (theo lời anh trong video đăng ngày 04/03/2024).

Slide giới thiệu About Ulrik với ảnh chân dung đen trắng — Slide giới thiệu "About Ulrik" ghi "#1 Global SaaS Pricing Consultant", "+150 B2B SaaS Pricing Projects" và "3x Founder (3 exits)" (slide trong video đăng ngày 04/03/2024). Trong lời nói, anh nói con số "hơn 100" dự án.

Theo Ulrik (video đăng ngày 04/03/2024), phần lớn thuật ngữ và cách nói về việc một pricing model là gì, cái gì cấu thành một model, các bộ phận chuyển động (moving parts) của một pricing model là gì, đơn giản là sai. Vì vậy anh đặt cho mình nhiệm vụ xây một framework và một bộ ngôn ngữ. Anh nói đã viết vài cuốn sách về những chủ đề này, và trong video này anh muốn chia sẻ một phần cốt lõi của nó.

2. Sáu thành phần của một pricing model

"Đây rồi", Ulrik nói khi đưa ra slide tiêu đề "SaaS Pricing Models: 6 Components". Theo anh (video đăng ngày 04/03/2024), có sáu thành phần then chốt của một SaaS pricing model. Mọi SaaS pricing model đều cần đủ sáu thành phần này thì mới thật sự là một model bạn có thể thực thi và dùng để định giá một thứ gì đó.

Slide Pricing 6 Components liệt kê sáu thành phần kèm ví dụ — Slide "Pricing 6 Components" (slide trong video đăng ngày 04/03/2024): 1. Pricing Metric, ví dụ price per user; 2. Pricing Modality, ví dụ "license" hoặc "usage"; 3. Period, ví dụ monthly, annually; 4. Granularity, ví dụ per "5 users" hoặc "2, 5, 10, 15"; 5. Discount, ví dụ waterfall hoặc threshold; 6. Price Point, "$-slope" từ "smallest" tới "largest".

3. Thành phần 1: pricing metric, đơn vị bạn tính tiền

Thành phần đầu tiên trong sáu là pricing metric. Theo Ulrik (video đăng ngày 04/03/2024), pricing metric đơn giản là đơn vị (unit) bạn tính tiền theo. Đó có thể là price per user, price per API call, price per active store, hay thật ra là bất cứ thứ gì.

Slide 1. Pricing Metric với danh sách ví dụ và bốn tiêu chí — Slide "1. Pricing Metric" ghi "The Pricing Metric is the unit you charge by" (slide trong video đăng ngày 04/03/2024). Cột trái là ví dụ: Flat, Price per user, Price per API Call, Price per "Active Store", "... anything really". Cột phải là bốn điều cần đảm bảo: A) Measurable, B) In demand, C) Considered Fair, D) Dense.

Flat fee, theo anh (video đăng ngày 04/03/2024), đơn giản là một monometric: bạn chỉ tính tiền cho mối quan hệ tài khoản (account relationship). Kiểu như bạn nói: "Anh là khách hàng, và mọi thứ bắt đầu bằng việc anh trả tôi X, một nghìn đô mỗi năm, rồi sau đó chúng tôi sẽ đếm thứ kia: số user, số API call, vân vân." Khi đó bạn có hai metric: một flat metric, rồi tới user. Vậy là xong.

Điều anh muốn nói ở đây (video đăng ngày 04/03/2024): bạn cần một thứ gì đó để đếm, dù đó là chính khách hàng hay một trong các volume của khách theo cách nào đó.

4. Tiêu chí của metric: đo được và được khách cần

Để chọn một pricing metric thật sự hiệu quả, Ulrik đưa ra bốn tiêu chí (video đăng ngày 04/03/2024).

Tiêu chí đầu tiên: bạn phải thật sự đo được nó (measurable). Theo anh (video đăng ngày 04/03/2024), nghĩa của nó là bạn phải đo được về mặt vận hành, đo được về mặt pháp lý, vân vân. Nếu bạn đo mức độ hài lòng của khách với sản phẩm, thì đo kiểu quái gì được? Anh cũng kể đã thấy người ta cố đo số tiền tiết kiệm được nhờ đào tạo nhân viên, vì phần mềm giúp đào tạo nhân viên. Nhưng khi đó bạn đang làm việc với các kịch bản kiểu "nếu không có phần mềm thì sẽ tốn bao nhiêu", và bạn sẽ dính vào rất nhiều cuộc cãi vã. Vậy nên nó không đo được.

Tiêu chí thứ hai: metric phải được khách cần (in demand). Ulrik mô tả đây là một thang (video đăng ngày 04/03/2024). Ở một đầu, khách sẽ coi nó thẳng thừng là một khoản chi phí, kiểu "được thôi, công bằng, tôi sẽ trả". Ở đầu kia, giả sử bạn bán cho khách lead mới, doanh số, hay chính tiền. Nếu phần mềm của bạn tạo ra công việc kinh doanh cho khách theo cách nào đó, và bạn nói: "Cứ mỗi triệu đô lợi nhuận anh kiếm được, tôi tính anh một trăm nghìn", thì bạn có thể chắc chắn rằng khách sẽ không giới hạn số lượng mua. Khách chỉ muốn nói: "Anh bán cho tôi được bao nhiêu lợi nhuận thì tôi muốn mua bấy nhiêu."

Vậy nên, theo Ulrik (video đăng ngày 04/03/2024), ở đâu đó trên thang này có một điểm mà một thứ trở thành "in demand": khách muốn chính bản thân nó, chứ không phải coi nó là một đầu vào để có được một thứ khác.

5. Tiêu chí của metric: được coi là công bằng và có density

Tiêu chí thứ ba: metric được coi là công bằng (considered fair). Ulrik lấy ví dụ per user (video đăng ngày 04/03/2024). Bạn đo được nó, và khách nghĩ: "Ừ thì công bằng. User của chúng tôi thật sự tạo ra giá trị qua giải pháp của anh. Tôi quen trả theo user rồi, đó là chuyện rất phổ biến. Tôi thấy ổn." Vậy là khách cho phép bạn định giá theo cách này.

Ngược lại, theo anh (video đăng ngày 04/03/2024), giả sử bạn có một phần mềm AI nào đó, và bạn nói: "Tôi sẽ tính anh một phần trăm doanh thu của anh." Dù đó có thể đúng là việc bạn đang giúp khách làm, tạo thêm doanh thu, và khách cũng muốn thêm doanh thu, khách hàng của bạn vẫn có thể không thấy nó công bằng. Khách có thể nói: "Anh hơi đi quá xa rồi đấy. Doanh thu thật ra là của chúng tôi. Chúng tôi cũng làm rất nhiều thứ với doanh thu đó, nên nó không chỉ nhờ phần mềm của anh, và chúng tôi không thấy thoải mái. Chúng tôi không dự đoán được nó", vân vân. Khách đơn giản là không thích. Vậy là nó không công bằng, và nó không chạy được.

Tiêu chí cuối: density. Theo Ulrik (video đăng ngày 04/03/2024), density là khi đơn vị bạn tính tiền, per user, per API call, per bệnh nhân trong phần mềm bệnh viện của bạn, là đồng nhất (uniform): mỗi đơn vị có giá trị như mọi đơn vị khác. Anh lấy ví dụ Stripe: khi Stripe tính bạn 3%, anh nói rồi sửa lại là 2.95%, trên mỗi đô la bạn xử lý qua cổng thanh toán của họ, thì đô la là đơn vị (theo video đăng ngày 04/03/2024). Và một đô la là một đơn vị dense hoàn hảo: đô la này có giá trị đúng bằng đô la kia.

Nhưng, theo anh (video đăng ngày 04/03/2024), giả sử bạn có một phần mềm khác, kiểu một hệ thống đào tạo gì đó cho toàn tổ chức, trong đó có những user là admin dùng nặng bên HR, còn những user khác rất "casual", kiểu mỗi năm đăng nhập một lần để tick vào một ô. Khi đó khách sẽ nói: "Mấy user bên này thì tôi hiểu vì sao phải trả, được thôi, họ tạo ra rất nhiều giá trị cho tôi. Nhưng mấy user bên kia, dù về kỹ thuật họ có login, họ không thật sự mang lại nhiều giá trị. Nên có khi tôi muốn được giảm giá hay gì đó." Khi đó đơn vị không dense lắm, vì một user đáng giá hơn user khác rất nhiều, và điều đó sẽ gây cho bạn rất nhiều vấn đề.

Lời khuyên của Ulrik (video đăng ngày 04/03/2024): đi qua bốn tiêu chí này, measurability, value hay demand, fairness và density, và cân nhắc chúng khi chọn metric. Đó là bước một trên sáu; anh nói các bước sau sẽ nhanh hơn một chút.

Hình 5.1Bốn tiêu chí Ulrik đưa ra để chọn pricing metric, theo slide và lời anh (video đăng ngày 04/03/2024).

6. Thành phần 2: pricing modality, bốn cách tính tiền

Bước tiếp theo, theo Ulrik (video đăng ngày 04/03/2024), là thứ mà người ta hay nhầm với pricing metric: pricing modality. Modality về cơ bản là việc một khoản thu là gì trong bốn loại sau.

Flat fee: anh nói là trả một lần (video đăng ngày 04/03/2024).
License fee: quyền được dùng một thứ trong một khoảng thời gian tương lai (theo Ulrik, video đăng ngày 04/03/2024).
Usage-based fee: một khoản thanh toán vào cuối kỳ, vì bạn đã dùng một thứ gì đó (theo Ulrik, video đăng ngày 04/03/2024).
Credit model: giống Audible.com, nơi bạn mua sách nói. Bạn mua một credit, credit nằm trong tài khoản, và bạn đổi nó lấy một cuốn sách nói. Nhưng subscription là cho credit: mỗi tháng bạn có thêm credit, chúng tích lũy dần trong tài khoản, và lúc nào muốn dùng thì bạn dùng (theo Ulrik, video đăng ngày 04/03/2024).

Slide 2. Pricing Modality liệt kê bốn loại kèm ví dụ giá — Slide "2. Pricing Modality" ghi "The Pricing Modality is HOW you charge" và "There are 4 kinds" (slide trong video đăng ngày 04/03/2024): Flat Fee, ví dụ $3k/tháng, trả trước, usage không liên quan (metric không dùng); License, ví dụ $200/user/tháng, usage được ước tính và trả trước; Usage based, ví dụ $50/active user/tháng, usage được đo và trả cuối kỳ; Credits, ví dụ $50/credit/tháng, credit trả trước, tài khoản được cân đối theo usage thực tế vào cuối kỳ.

Theo Ulrik (video đăng ngày 04/03/2024), bạn có thể kết hợp bất kỳ metric nào với bất kỳ modality nào. Flat fee nằm ở cấp tài khoản, thế là xong. Nhưng bạn có thể có user license, hoặc usage-based với user, chẳng hạn đếm số monthly active user. Và bạn có thể có credit: bạn nói "anh trả trước cho tôi 50 usage credit, rồi chúng tôi sẽ đếm bao nhiêu nhân viên của anh đăng nhập, trừ số đó vào credit, rồi anh mua 50 credit mới". Anh nói có những hệ thống như vậy.

7. Ghép metric với modality: cash flow, risk và lời phản đối của khách

Điều bạn sẽ thấy, theo Ulrik (video đăng ngày 04/03/2024): khi người ta phản đối (pushback) metric của bạn, thật ra họ đang phản đối cái modality mà bạn ngầm ghép với metric đó. Ví dụ bạn nói: "Tôi sẽ tính anh một license cho một triệu API call. Anh trả tôi cho một triệu API call, dù anh có dùng hay không." Đó chính là license.

License, theo anh (video đăng ngày 04/03/2024), là việc khách đoán, đặt cược hay ước tính mình sẽ có bao nhiêu usage, rồi trả cho bạn khoản đó. Nếu sau đó không dùng hết thì đành chịu, đó là chuyện của khách. Vậy là risk nằm ở phía khách hàng. Cash flow tới trước, nhưng giá cũng rất dễ dự đoán, và anh nói thật ra nó thường được coi là khá công bằng.

Mặt khác, với các model usage-based, theo Ulrik (video đăng ngày 04/03/2024), khách không phải trả trước mà trả vào cuối. Giá rất khó dự đoán, tùy vào usage thực tế hình thành ra sao. Và cuối cùng, khách chỉ trả cho những gì mình cần, nên không cần ước tính gì cả: cứ dùng, rồi có bao nhiêu user thì trả cho bấy nhiêu.

Ulrik nói anh không nghĩ có modality nào thật sự tốt hay thật sự tệ; tất cả tùy vào sản phẩm, tình huống, khách hàng, vân vân. Chúng chỉ đơn giản là có đó (video đăng ngày 04/03/2024). Một loại thường gặp là license-based. Đôi khi anh và nhóm thêm flat fee cho phần mềm rất đơn giản. Đôi khi anh và nhóm kết hợp, kiểu: "Anh sẽ có một flat fee, cộng một license cho user, cộng phần usage-based cho API call, để đếm toàn bộ tải hạ tầng anh đặt lên hệ thống", đại loại vậy. Với các giải pháp B2B phức tạp hơn, theo anh, bạn bắt đầu kết hợp những loại này và xây model từ đó.

Điểm then chốt về modality, theo Ulrik (video đăng ngày 04/03/2024): nó quyết định cash flow và risk. License thì cash flow tới trước, usage thì cash flow tới vào cuối kỳ. License thì khách gánh risk, usage thì bạn gánh risk. Slide lúc đó ghi "NB: Modality determines Cash flow and Risk", với ví dụ: với Usage Based pricing, vendor nhận risk của việc khách không dùng và thu tiền vào cuối kỳ; License based thì ngược lại (slide trong video đăng ngày 04/03/2024).

Hình 7.1Điểm then chốt Ulrik nêu về modality: nó quyết định cash flow và risk (theo lời anh và slide trong video đăng ngày 04/03/2024).

8. Thành phần 3: period, khoảng thời gian tính tiền

Thành phần số ba là period. Theo Ulrik (video đăng ngày 04/03/2024), nếu bạn chạy một subscription, bạn cần một khoảng thời gian. Bạn sẽ nói: "Chúng tôi sẽ đếm usage mỗi tháng, mỗi quý, hay mỗi năm", tùy trường hợp. Hoặc bạn bán cho khách một license kiểu ba năm. Dù là gì, bạn cần một period.

Các loại phổ biến là monthly và annual. Nói rất đơn giản, theo anh (video đăng ngày 04/03/2024), hợp đồng dài hơn thì khó bán hơn, có churn thấp hơn, và khó định giá lại (reprice) hơn. Nhưng điều quan trọng là chúng còn khuếch đại hiệu ứng cash flow của modality bạn chọn.

Slide 3. Period với các loại thường gặp và đặc điểm của hợp đồng dài — Slide "3. Period" ghi "You need to choose the time period used" (slide trong video đăng ngày 04/03/2024). Loại thường gặp: Monthly, Annually, Long contracts (2+ years). Hợp đồng dài hơn: khó bán hơn, churn thấp hơn, khó re-price hơn, khuếch đại hiệu ứng cash flow của Modality.

Ulrik lấy ví dụ (video đăng ngày 04/03/2024): bạn có một hợp đồng ba năm trên một license. Tuyệt. Lúc này bạn thậm chí có thể nói với khách: "Anh đã cam kết ba năm, đã ký ba năm, đã có mức giá ba năm dễ chịu, sao anh không trả hết trước luôn?" Anh nói đã thấy chuyện này xảy ra, và anh không nhất thiết nói đó là ý hay, nhưng xét về cash flow thì tuyệt vời: bạn nhận toàn bộ tiền mặt ngay từ đầu. Còn cùng model đó mà là usage-based, kiểu "cứ bắt đầu dùng đi, ba năm nữa chúng tôi gửi hóa đơn", thì có thể sẽ thành rất nhiều usage, nhưng cash flow không tốt lắm, vì nó ở quá xa trong tương lai.

9. Lời khuyên về period: annual, monthly, và bài toán hợp đồng ba năm

Lời khuyên chung của Ulrik (video đăng ngày 04/03/2024): với các modality license-based, ít nhất là trong B2B SaaS, hãy chọn annual; với usage-based, hãy chọn monthly. Và đừng bao giờ làm hợp đồng dài hơn một năm, vì đội sales của bạn không xử lý nổi, và bạn mất quá nhiều do không thể định giá lại.

Slide My advice về period: annual cho license, monthly cho usage — Slide "My advice" ghi "Go Annual for LICENSE Modalities", "Go Monthly for USAGE Modalities" và "(Never go 2+ years - it tends to trigger way to high discounting)" (slide trong video đăng ngày 04/03/2024).

Anh đưa ra phép tính (video đăng ngày 04/03/2024): nếu bạn có thể tăng giá 10% mỗi năm, thì trên một hợp đồng ba năm bạn sẽ mất 10% ở năm thứ nhất, mất 21% ở năm thứ hai, và cứ thế, vì không thể định giá lại. Theo anh, khoản này thường vượt quá mọi mức tăng cố định kiểu 4% hay theo lạm phát. Anh nói nếu làm phép tính thì nó không bao giờ có lợi.

Thêm nữa, theo Ulrik (video đăng ngày 04/03/2024), hợp đồng ba năm thường đi kèm một mức giảm giá sâu. Thứ lẽ ra bán được 100 thì đội sales sẽ bán với giá 85. Vậy bạn thu 85, rồi cộng thêm, giả sử 4%, thành 89 và 93 trong giai đoạn ba năm. So với 100, 110 và 121 nếu bạn chỉ làm hợp đồng annual. Anh nói khoảng chênh lệch có thể rất lớn, và thành thật mà nói, đây là một trong những việc dọn dẹp dễ hơn trong B2B SaaS.

Hình 9.1Ví dụ Ulrik tính bằng lời: hợp đồng ba năm bán giảm còn 85 rồi cộng 4% (85, 89, 93), so với hợp đồng annual tăng giá 10% mỗi năm (100, 110, 121) (theo video đăng ngày 04/03/2024).

10. Thành phần 4: granularity, atomic, chunky và expanding

Bước bốn là granularity. Theo Ulrik (video đăng ngày 04/03/2024), đây là kích cỡ của đơn vị bạn tính tiền. Anh thường nói có ba loại: atomic, chunky và expanding.

Slide 4. Granularity với ba loại atomic, chunky, expanding — Slide "4. Granularity" ghi "The Pricing Metric Granularity is the UNIT SIZE" và "There are 3 kinds" (slide trong video đăng ngày 04/03/2024): "Atomic", ví dụ 1 user, 2 users, 3 users, đơn vị nhỏ nhất có thể được dùng mỗi lần; "Chunky", ví dụ 5, 10, 15 users, một đơn vị lớn hơn cho pricing "chunkier"; "Expanding", ví dụ 2, 5, 10 users, một chuỗi các "tranche" được tạo ra để bắt được các cỡ khách hàng khác nhau.

Trước hết, theo anh (video đăng ngày 04/03/2024), nếu bạn tính tiền theo user thì bạn không thể tính cho nửa user, nên bạn sẽ tính ít nhất một user. Đó là atomic unit: đơn vị nhỏ nhất có thể mà bạn đưa ra. Với API call thì đó là một API call, vân vân.

Nhưng chẳng ai bảo bạn phải tính theo atomic unit, theo Ulrik (video đăng ngày 04/03/2024). Có rất nhiều phần mềm tính theo mỗi 5 user hay mỗi 50 user. Bạn cũng có thể tính theo mỗi triệu API call: hễ khách bước sang triệu mới là bạn đếm nguyên một triệu, có khi chỉ khoảng $100, và như thế cũng ổn. Thay vì đếm từng đơn vị, bạn đếm một bước tăng lớn hơn, hay granularity. Anh nói điều đó có thể có mục đích thực tế, và nó cũng có thể được dùng để tăng giá, khoảng từ 2 đến 4 phần trăm (theo video đăng ngày 04/03/2024).

Atomic, theo anh (video đăng ngày 04/03/2024), là 1, 2, 3, 4, 5, 6, 7, 8, đếm từng cái một. Chunky là kiểu mỗi 5, 10, 15, hoặc với API call là 1 triệu, 2 triệu, 3 triệu. Còn expanding granularity về cơ bản là đơn vị sẽ thay đổi: đơn vị thứ nhất không giống đơn vị thứ hai, không giống đơn vị thứ ba, vân vân. Nó không cần phải giống nhau. Với user, đó có thể là kiểu 2, 5, 10: lần đầu khách mua 2, rồi mua thêm 3, rồi thêm 5. Rồi có thể là 15, thêm 5 nữa, rồi 25, thêm 10 nữa, vân vân.

Điều bạn làm ở đây, theo Ulrik (video đăng ngày 04/03/2024), là nói rằng lần mua tiếp theo luôn có kích cỡ hợp lý so với toàn bộ lần mua trước đó. Chẳng hạn luôn mở rộng ít nhất 10%, đại loại vậy.

11. Granularity log-scale: từ school district tới freelancer

Lời khuyên của Ulrik ở đây (video đăng ngày 04/03/2024) là cái anh gọi là "granularity log scale". Bạn nhìn toàn bộ thị trường của mình. Giả sử bạn bán cho các school district (khu học chánh), và bạn bán phần mềm cho giáo viên. Theo anh, các school district lớn nhất ở Mỹ có khoảng 100.000 giáo viên, kiểu New York hay Chicago. Còn những school district nhỏ nhất chỉ có khoảng một tá giáo viên, rất ít, ít nhất là dưới 100.

Slide My advice về granularity log-scale với ba mức 10x, 100x, 1000x — Slide "My advice" về "The 'Granularity Log-Scale'" (slide trong video đăng ngày 04/03/2024): nếu tỷ lệ giữa khách nhỏ nhất và khách lớn nhất là 10x thì chọn "Atomic", 100x thì chọn "Chunky", 1000x thì chọn "Expanding". Dòng cuối ghi ví dụ: nếu bạn bán cho freelancer và agency 100 user thì là Chunky.

Rồi bạn nhìn khoảng chênh lệch kích cỡ giữa khách nhỏ nhất và khách lớn nhất bạn muốn bán (video đăng ngày 04/03/2024). Anh nói có thể bạn không muốn bán cho những khách nhỏ nhất. Nhưng nếu bạn muốn bán cho cả school district 100 giáo viên lẫn school district 100.000 giáo viên, thì từ 100 lên 100.000 là 1.000 lần: khách lớn nhất của bạn lớn gấp 1.000 lần khách tiềm năng nhỏ nhất.

Khi đó, theo Ulrik (video đăng ngày 04/03/2024), bạn có thể muốn chọn kiểu expanding granularity. Bạn nói: "Chúng tôi tính theo 5 giáo viên, 10, 25, 50, 75, 100, 150, 200", vân vân. Rồi bạn đi lên, và ở phía trên của thang là kiểu 50K, 55K, 60K, cứ thế, đi theo từng chunk 5K. Nhưng chunk 5K có thể hợp lý cho Chicago, New York, Miami hay các nơi tương tự, trong khi các school district lớn hơn có kích cỡ gấp 50 lần chính các school district nhỏ hơn. Vậy bạn cần một thứ có thể scale ở đây.

Ngược lại, theo anh (video đăng ngày 04/03/2024), nếu bạn bán phần mềm thiết kế cho freelancer và agency nhỏ, và bạn nói: "Tôi bán cho freelancer, một người, rồi các agency nhỏ giống vậy, có lẽ tối đa 20 người, đó là thị trường mục tiêu của tôi", thì có lẽ bạn chỉ muốn bán từng user. Vì giữa khách nhỏ nhất và lớn nhất chỉ chênh 20 lần, và như vậy có lẽ khá phù hợp. Anh nói ít nhất đó là cách anh nghĩ về chuyện này.

12. Thành phần 5: discount, threshold và waterfall

Thành phần tiếp theo là discount. Ulrik nói anh chọn một cách nhìn về discount cho phần này, và bạn có thể giảm giá theo rất nhiều cách (video đăng ngày 04/03/2024). Theo một nghĩa, bạn có thể nhìn pricing model của mình như một đơn vị, kiểu một đơn vị toán học: đây là cách bạn tính giá. Còn discount là một đơn vị hoàn toàn riêng biệt mà bạn ghép vào tổng thể.

Ở đây anh muốn đưa ra một điều thường tạo ra rất nhiều tranh luận và thảo luận trong các dự án anh chạy: làm sao thực thi một discount (video đăng ngày 04/03/2024). Nó dựa trên tiền đề rằng phần lớn discount ở dạng nào đó là dựa trên volume, dù chúng không cần phải như vậy. Bạn cũng có thể giảm theo số sản phẩm khách mua, kiểu "anh mua tất cả add-on thì được nửa giá", đại loại vậy. Nhưng bạn cũng có thể nói "càng nhiều user thì càng rẻ", và theo anh đó là loại phổ biến nhất, nên anh bàn trong bối cảnh đó. Anh nói bạn có thể làm việc với cái anh gọi là waterfall discount hoặc threshold discount, và mời người xem nghe anh giải thích.

Slide 5. Discount với hai cách threshold và waterfall — Slide "5. Discount" ghi "There are 2 major ways to offer discounts" (slide trong video đăng ngày 04/03/2024): Threshold, ở mức 1000 user được giảm 10% trên mọi user, kể cả 1000 user đầu; Waterfall, ở mức 1000 user được giảm 10% trên mọi user tiếp theo. Dòng dưới: ngoài ra, discount đi theo cấu trúc của pricing model và cũng có Metric + Modality + Period + Granularity.

Với threshold discount, theo Ulrik (video đăng ngày 04/03/2024), bạn nói: "Một nghìn user đầu là $100 một user. Nhưng nếu anh đạt tới 1.000, tôi giảm 10% cho tất cả." Vậy giờ khi khách đạt 1.000 user, mỗi user giá 90, vậy tổng là 90.000. Điều này tạo ra một hiệu ứng kỳ lạ: khách sẽ thêm user lên 997, 998, 999. Ở mức 999 user, anh nói lúc đầu là 90.990, rồi tự sửa lại: khách sẽ trả 99.900. Rồi tới user thứ một nghìn, giá rơi ngược xuống 90.000. Vậy là bạn có tình huống giá đi lên, rồi đột ngột rơi xuống vì chạm ngưỡng.

Ngược lại là waterfall discount, theo anh (video đăng ngày 04/03/2024): bạn nói "cách chúng tôi làm là một nghìn user đầu giá $100, và user thứ một nghìn lẻ một giá 90". Bạn vẫn trả 100K cho một nghìn user đầu, nhưng trả ít hơn cho đơn vị tăng thêm, user kế tiếp. Rồi có thể ở mức 2.000 user, giá giảm xuống 80 hay bao nhiêu đó.

Hình 12.1Hai ví dụ Ulrik tính bằng lời (video đăng ngày 04/03/2024): với threshold, tổng tiền rơi từ 99.900 xuống 90.000 khi chạm user thứ 1.000; với waterfall, 1.000 user đầu vẫn là 100.000 và chỉ các user tiếp theo rẻ hơn. Hình chỉ minh họa hình dạng, không theo tỷ lệ.

13. Khi nào dùng threshold, khi nào dùng waterfall

Lời khuyên của Ulrik (video đăng ngày 04/03/2024) dựa trên việc khách có kiểm soát được volume hay không. Giả sử bạn bán phần mềm cho sales rep, và khách của bạn thật ra có 500 sales rep. Với threshold discount, điều bạn muốn là tránh kịch bản khách chỉ cài cho năm rep để thử trong một năm. Bạn muốn đẩy nhanh. Nên bạn nói: "Anh mua càng nhiều thì tất cả càng rẻ. Và thật ra anh đang mất tiền khi không đưa tôi cả 500." Cứ chạy thử, nhưng chạy trong ba tuần thôi, rồi thêm khoảng 100, rồi 500, vì như vậy khách sẽ có giá tốt nhất. Vậy khi khách kiểm soát được volume, bạn nên cân nhắc một threshold license (theo video đăng ngày 04/03/2024).

Slide My Advice về khi nào dùng threshold và khi nào dùng waterfall — Slide "My Advice" (slide trong video đăng ngày 04/03/2024): dùng THRESHOLDs khi khách CAN kiểm soát volume của metric (ví dụ số user license mua), "= they send you more volume"; dùng WATERFALLs khi khách CAN NOT kiểm soát volume của metric (ví dụ số inch lượng mưa).

Nếu khách không kiểm soát được volume, vì nó cố định hoặc do bên ngoài quyết định, Ulrik nói anh nghĩ mình có một ví dụ ở đây: số inch lượng mưa (video đăng ngày 04/03/2024). Giả sử bạn có một hệ thống IoT nào đó điều khiển dòng nước trong một thành phố, và bạn nói: "Mưa càng nhiều thì giá trị càng nhiều, nên tôi tính theo inch lượng mưa." Khách không thật sự kiểm soát được chuyện đó. Sẽ rất kỳ nếu khách phải xem dự báo thời tiết để biết mình phải trả bao nhiêu, kiểu mưa thêm một chút là giá tự nhiên rơi xuống. Vậy ở đó, hãy dùng waterfall.

Điều khác, theo anh (video đăng ngày 04/03/2024): threshold có thể dễ truyền đạt hơn một chút, kiểu "giờ giá là 90, giờ giá là mức khác". Với waterfall, bạn thật ra phải tính một kiểu giá trung bình và làm mấy việc như vậy. Nhưng hãy tìm xem cái nào hợp nhất với bạn.

Theo Ulrik (video đăng ngày 04/03/2024), chuyện này ít liên quan tới tiền mà liên quan nhiều tới tâm lý. Hãy chọn thứ mà khách hiểu và thích một cách trực giác, và thấy ổn với nó, để không có ma sát (friction). Khách chỉ ghi nhận là mình có discount, khách muốn có một cái để mua, rồi bạn đi tiếp.

14. Thành phần 6: price point

Điểm cuối cùng là price point. Ulrik tóm lại những gì đã có (video đăng ngày 04/03/2024): bạn có một pricing metric; bạn có một modality, ví dụ user, và là license; bạn sẽ tính theo tháng; bạn sẽ tính theo mỗi 5 user; và bạn sẽ có một discount kiểu waterfall ở mức, chẳng hạn, X trăm user. Giờ bạn cần thật sự có price point, và cả price point ở mức, giả sử, một user, năm user, 100 user, vân vân.

Slide 6. Price Point với ví dụ ba bậc giá theo user — Slide "6. Price Point" ghi "Finally: add $-amounts" (slide trong video đăng ngày 04/03/2024). Ví dụ: $100/user/tháng cho 1-50 user, $80/user/tháng cho 51-100 user, $60/user/tháng cho 101+ user, tất cả theo chunk 5 user; tất cả trả trước dưới dạng license với waterfall discount.

Lời khuyên của anh (video đăng ngày 04/03/2024): đừng nghĩ quá nhiều về việc này, và cũng đừng sợ. Price point rõ ràng là nơi có nhiều tiền, nhưng phần còn lại của model dẫn dắt cách khách mua, mua bao nhiêu, mua nhanh thế nào, vân vân, và điều đó có thể có ý nghĩa lớn hơn rất, rất nhiều so với chính price point. Nhưng một khi đã tới đây, thì price point thật sự quan trọng.

15. Scale price point theo khách nhỏ nhất và khách lớn nhất

Cách Ulrik thường làm (video đăng ngày 04/03/2024) là nhìn vào các thị trường của mình. Giả sử lại là các school district ở Mỹ. Bạn hỏi: một school district 100 giáo viên nên trả bao nhiêu, và New York với 100K giáo viên nên trả bao nhiêu?

Slide My Advice về cách scale price point — Slide "My Advice" ghi "Scale price points by answering": 1. khách nhỏ nhất của tôi nên trả bao nhiêu? 2. khách tiềm năng lớn nhất của tôi nên trả bao nhiêu? Ví dụ trên slide: nếu một freelancer nên trả $500/năm và agency 100 user trả $20K, thì 1 user = $40/user/tháng, 100 user = $16/user/tháng (slide trong video đăng ngày 04/03/2024).

Anh kể có lần đã làm một dự án như vậy cho giáo viên trường học ở Mỹ (theo video đăng ngày 04/03/2024). Kết luận khi đó kiểu như: ở volume nhỏ, khách nên trả khoảng $100 mỗi năm, còn ở volume siêu lớn thì nên trả khoảng 15, vì có chi phí, có giá trị, có đối thủ cạnh tranh, có đủ thứ như vậy, và gộp tất cả lại thì thấy mức đó có lẽ là công bằng. Vậy là khoảng 10K cho trọn hợp đồng ở đầu nhỏ: $100 nhân 100 giáo viên. Và khoảng một triệu ở đầu lớn: 100.000 giáo viên nhân 10, đại loại vậy, có khi hơn một chút.

Theo Ulrik (video đăng ngày 04/03/2024), nếu nhìn như vậy, câu hỏi là giá trị hợp đồng hợp lý cho thị trường nói chung là bao nhiêu. Và đừng chỉ nhìn năm khách bạn đang có trong pipeline. Hãy nhìn thị trường bạn thật sự muốn tiếp cận. Có thể bạn chưa bán cho New York, nhưng nếu bạn dự định làm vậy trong hai, ba năm tới, hãy lên kế hoạch đó trong pricing: "Nếu tôi tới được đó, mỗi giáo viên sẽ là 10 đô."

Rồi để ra các mức giá, theo anh (video đăng ngày 04/03/2024), về cơ bản bạn chia cho metric. Nếu hợp đồng là 10K, chia cho 100 giáo viên của khách, ra $100 mỗi giáo viên. Ở đầu kia, nếu là một triệu và khách có 100.000 giáo viên, thì là $10 mỗi giáo viên.

Ulrik nhắc lại (video đăng ngày 04/03/2024): đừng làm phức tạp quá. Bạn sẽ có thể tăng giá sau này. Bạn sẽ kiểm chứng mọi thứ. Nếu khách nói "đồng ý" hơi nhanh quá, bạn có thể tăng giá, vân vân.

16. Mô hình đúng thì price point dễ tối ưu, và phần packaging

Điểm then chốt, theo Ulrik (video đăng ngày 04/03/2024): nếu bạn làm model đúng, rất nhiều ma sát trong model sẽ được xử lý, vì bạn đã có đủ các yếu tố đúng. Và điều đó nghĩa là tín hiệu bạn nhận được, lời phản đối, ma sát, tốc độ của thương vụ, sẽ nằm nhiều hơn ở chính price point. Vậy nên với một model tốt, price point dễ tối ưu và dễ tăng hơn rất nhiều, và theo anh đó là lý do nó quan trọng đến vậy.

Ulrik điểm lại các thành phần (video đăng ngày 04/03/2024): pricing metric, modality, period, granularity, discount và price point, và bạn cần có tất cả. Bạn có thể nói "tôi không muốn discount", tốt thôi, nhưng khi đó bạn cần nói thẳng ngay từ đầu rằng không có discount. Theo anh, bạn không thể có một pricing model mà thiếu nó.

Theo Ulrik (video đăng ngày 04/03/2024), đây là một phần của cả bức tranh. Phần lớn còn lại là packaging: bạn thật sự đang bán gì, một cấu trúc tier, các module, add-on, vân vân. Anh nói đó là một phần rất, rất lớn của monetization, và thường thật ra là phần đầu tiên anh sẽ tìm tới để tính cách kiếm tiền từ khách hàng, thị trường và sản phẩm mình có. Pricing nằm bên trên packaging. Nên hãy lo nhiều hơn một chút cho packaging, cho proposition và thứ bạn sẽ bán cho khách. Khi phần đó đã chốt xong, hãy chuyển sang pricing như cách trong video, nơi bạn chỉ cần đảm bảo mình có một pricing hợp lý, chạy được (reasonably functional). Anh nói đó sẽ là tiêu chí thành công của anh ở đây.

Khép lại phần trình bày (video đăng ngày 04/03/2024), Ulrik nói anh hy vọng nó dễ hiểu và có giá trị với người xem, và hy vọng mọi người hiểu vì sao anh nghĩ nhiều thuật ngữ và cách cấu trúc khác về một pricing model là quá lỏng lẻo. Theo anh, bộ khung này bao phủ gần như 100% phạm vi bạn muốn đi vào, và tốt hơn hết là có một ngôn ngữ tốt hơn để mô tả việc mình đang làm, vì nó mang lại một chút rõ ràng. Anh nói dùng nó trong các dự án của mình mọi lúc, và nó thường làm quy trình dễ hơn nhiều; anh và nhóm có thể kết hợp nó, bạn có thể làm toán trên tất cả các thành phần này và tạo ra nhiều kịch bản thiết kế khác nhau với nó. Anh hy vọng nó có ích cho người xem, rồi chào: "All right, cheers."