BDSGPHẠM VĂN THƯNHÀ SÁNG LẬP BDSG
ENTài khoản
Kết nối
Menu
Khởi nghiệp · Nội dung có hỗ trợ AI

Mô hình doanh thu: đọc chín nhóm YC và chọn cách thu tiền có thể kiểm chứng

Đăng ngày 23/10/2026

Mục lục bài nghiên cứu
Ảnh bìa bài: Mô hình doanh thu

Tóm tắt và điều cần nhớ

Một sản phẩm được khen chưa chắc có cách thu tiền khả thi. Muốn thiết kế doanh thu, nhà sáng lập phải nối người hưởng lợi, người có ngân sách, đơn vị tính phí và công việc phải thực hiện sau khi bán. Bài mở đầu giai đoạn kinh tế kinh doanh bằng việc chọn cơ chế thu tiền; mức giá cụ thể và phép tính giá trị khách hàng sẽ được bàn riêng.

  • Viết rõ ai trả, trả cho việc gì, vào thời điểm nào và có quyền dừng ra sao.
  • Phân biệt mô hình doanh thu với toàn bộ cách doanh nghiệp tạo và cung cấp giá trị.
  • Chín nhóm trong hướng dẫn YC là bản đồ tham khảo, không phải phép đo xác suất thành công.
  • Kiểm một cơ chế chính trước khi bổ sung nguồn thu phụ.
  • Đưa cả hoàn tiền, hỗ trợ và đối soát vào phép thử bán hàng.

Bắt đầu bằng một dòng tiền có thể giải thích

Trang Business Builder của Royal Bank of Scotland trình bày các cách tạo doanh thu như thuê bao, giao dịch, quảng cáo và tiếp thị liên kết. Trang cũng đặt câu hỏi về người trả, giá trị và cách thanh toán. Đây là tài liệu hướng dẫn thực hành, không phải kết quả nghiên cứu; bài dùng nó để đặt câu hỏi cho báo giá, không suy ra hiệu quả của từng mô hình [1].

Thử câu mô tả tự dựng: một xưởng thuê công cụ kiểm hồ sơ mỗi tháng; gói có số hồ sơ nhất định, vượt hạn mức thì tính thêm. Câu ấy còn thiếu người duyệt ngân sách, ý nghĩa của hồ sơ hợp lệ và việc ai chịu chi phí khi phải chạy lại. Bổ sung các chi tiết đó giúp phân biệt cơ chế thu tiền đã nghĩ kỹ với một ý định gắn nút thanh toán.

Người hưởng lợi và người trả tiền có thể khác nhau. Nhân viên thấy công cụ giảm thao tác, trưởng bộ phận cần báo cáo, còn bộ phận mua sắm kiểm hợp đồng. Nếu chỉ phỏng vấn người sử dụng rồi kết luận đã tìm được khách hàng trả tiền, nhóm có thể tối ưu trải nghiệm cho một người không có quyền mua. Cần kiểm từng vai bằng câu hỏi và quan sát riêng.

Cơ chế doanh thu chỉ là một lớp của mô hình kinh doanh

Zott và Amit, trong bài năm 2010, nhìn doanh nghiệp như một hệ thống hoạt động liên kết cả với đối tác. Khung của họ xem xét làm hoạt động nào, nối các hoạt động ra sao và bên nào thực hiện. Đây là lập luận thiết kế hệ thống, không phải thử nghiệm chứng minh chọn một hình thức thu phí sẽ làm doanh nghiệp có lãi [2].

Baden-Fuller và Morgan cũng trình bày mô hình kinh doanh như công cụ mô tả, phân loại, tìm hiểu và sáng tạo. Theo cách đọc này, tên mô hình giúp đặt câu hỏi chứ chưa thay được bằng chứng về một thị trường cụ thể. Nhãn thuê bao không tự trả lời khách hàng có cần sản phẩm liên tục, có dùng lại hay có đủ ngân sách gia hạn hay không [3].

Với một dịch vụ kiểm thiết bị giả định, bán thiết bị đứt đoạn đòi hỏi sản xuất và bảo hành; cho thuê đòi hỏi theo dõi tài sản và thu hồi; nhận phí trên kết quả đòi hỏi đo kết quả. Cùng một công nghệ có thể dẫn tới ba hệ thống vận hành khác nhau. Vì vậy, thay mô hình doanh thu thường kéo theo thay người, quy trình và lượng tiền phải ứng trước.

Ba lớp từ hoạt động tạo giá trị tới cơ chế thu tiền và điều khoản thanh toán
Hình 1. Ba lớp cần khớp khi thiết kế dòng doanh thu.

Tách quyết định nền tảng khỏi việc đổi mức giá

Bản nghiên cứu của Casadesus-Masanell và Ricart sửa tháng 11/2009 phân biệt chiến lược, mô hình kinh doanh và các lựa chọn tác nghiệp còn có thể thực hiện trong mô hình đó. Điểm đáng dùng ở đây là quyết định nền tảng giới hạn những điều doanh nghiệp có thể điều chỉnh về sau. Không nên hiểu đây là một công thức thực nghiệm dự báo kết quả tài chính [4].

Một trung tâm giả định đã cam kết cung cấp dịch vụ liên tục sẽ có nghĩa vụ khác một nơi chỉ bán một báo cáo. Giảm giá báo cáo là đổi một biến trong giao dịch. Chuyển sang cam kết theo dõi hàng tháng lại đòi hỏi lịch phục vụ, người trực và cách xử lý sự cố. Nếu nhóm gọi cả hai việc là thử giá, họ dễ đánh giá thiếu chi phí chuyển đổi.

Hãy ghi một trang gồm việc phải làm trước bán, lúc giao và sau bán. Đánh dấu hoạt động nào còn thực hiện thủ công, hoạt động nào cần bên ngoài và khoản nào chưa thể ngừng khi khách rời đi. Trang này giúp chọn cơ chế thu tiền phù hợp năng lực hiện có. Nó cũng chỉ ra việc cần xây tiếp, thay vì biến mọi yêu cầu bán hàng thành tính năng sản phẩm.

Đọc chín nhóm YC như những cách đặt câu hỏi

Hướng dẫn YC được tạo năm 2022 nêu chín nhóm: phần mềm thuê bao, giao dịch, sàn kết nối, thuê bao sản phẩm hoặc dịch vụ, hợp đồng doanh nghiệp, tính theo mức dùng, thương mại điện tử, quảng cáo và nhóm công nghệ khó hoặc sinh học có thời gian phát triển dài. Cách chia này trộn cơ chế thu tiền, kênh bán và đặc điểm công nghệ; các nhóm không nhất thiết loại trừ nhau [5].

Có thể dùng danh sách để tìm điều chưa nghĩ tới. Bán quyền truy cập và bán một sản phẩm hữu hình khác nhau ở nghĩa vụ giao hàng. Thu phí hai phía của sàn đặt ra câu hỏi về ai đang trợ giá cho ai. Thu theo hoạt động đòi hỏi phép đo đáng tin. Một tên nhóm chỉ có ích khi dẫn tới câu hỏi vận hành cụ thể như vậy.

Đừng lấy danh sách công ty thành công để suy ra một mô hình sẽ nâng xác suất thắng cho mọi nhóm mới. Mẫu đã lọc người chiến thắng bỏ qua nhiều trường hợp cùng chọn mô hình nhưng thất bại. Ngay cả khi thấy một cơ chế phổ biến trong danh sách đầu tư, nhà sáng lập vẫn phải kiểm nhu cầu, chi phí bán và khả năng giao giá trị của mình.

Chọn người trả trước khi chọn tần suất thu

Với bán trực tiếp, câu hỏi đầu tiên là ngân sách nào được sử dụng và lý do gì khiến người giữ ngân sách muốn chi. Với quảng cáo, cần kiểm đồng thời sự hữu ích cho người dùng và lý do nhà quảng cáo mua tiếp cận. Với sàn, cần kiểm bên nào chịu phí mà vẫn thấy giao dịch đáng làm. Không thể dùng một cuộc phỏng vấn để xác nhận tất cả các vai.

Một ví dụ giả định là công cụ đặt lịch cho cơ sở dịch vụ. Khách đặt lịch muốn thao tác nhanh, nhân viên muốn giảm cuộc gọi, chủ cơ sở muốn giảm lịch trống. Có thể thu từ cơ sở, từ khách hoặc từ bên giới thiệu, nhưng mỗi lựa chọn làm thay đổi động lực. Thu của khách có thể tạo ma sát; thu của cơ sở cần chứng minh lợi ích so với cách quản lý hiện tại.

Sau khi xác định bên trả, mới hỏi nhu cầu có lặp lại hay không. Công việc chỉ diễn ra khi mở cửa hàng mới có thể thích hợp với một khoản triển khai, còn vận hành thường nhật có thể tạo cơ sở cho thuê bao. Đó là giả thuyết cần bán thử. Tần suất khách dùng sản phẩm cũng không luôn trùng với tần suất họ chấp nhận nhận hóa đơn.

Đơn vị tính phí cần nối được giá trị với phép đo

Một đơn vị thu tiền tốt cần đủ gần thứ khách hiểu và đủ rõ để hai bên đối soát. Ghế sử dụng dễ dự trù khi số nhân viên ổn định. Hồ sơ xử lý có thể thích hợp khi khối lượng thay đổi. Gói theo cơ sở phù hợp một số quy trình triển khai theo địa điểm. Không có đơn vị nào mặc nhiên đúng chỉ vì đối thủ đang sử dụng.

Tài liệu Stripe mô tả tính phí dựa trên mức tiêu thụ và chỉ tới các cơ chế ghi nhận, theo dõi sử dụng, cảnh báo cùng tín dụng trả trước. Đây là bằng chứng về những thành phần kỹ thuật có thể triển khai, không chứng minh khách hàng thích trả theo mức dùng. Khả năng đếm một sự kiện vẫn khác khả năng thuyết phục người mua rằng sự kiện ấy đáng trả tiền [6].

Trong tình huống tự dựng, nếu tính theo hồ sơ thì phải làm rõ hồ sơ thử, hồ sơ lỗi và hồ sơ chạy lại. Nếu tính theo ghế thì cần quy tắc cho nhân viên nghỉ việc và người chỉ xem báo cáo. Nếu tính theo doanh số thì phải xác định hủy đơn, hoàn hàng và cách quy kết. Các ngoại lệ càng nhiều, chi phí giải thích hóa đơn càng có thể tăng.

Ba cách thu tiền và trách nhiệm đo lường tương ứng
Hình 2. Chọn đơn vị tính phí đồng thời là chọn cách đối soát.

Thuê bao, dịch vụ và tiền nhận trước cần sổ riêng

Trong bản đồ YC, phí phát sinh một lần không nên được cộng vào doanh thu thuê bao định kỳ. Điểm phân biệt này giúp tránh dùng khoản triển khai để làm đẹp một chỉ số về việc khách trả lặp lại. Bài không sử dụng các tỷ lệ trên danh sách công ty của YC để ước lượng kết quả cho một doanh nghiệp Việt Nam [5].

Giả định một nhóm bán phần mềm kèm hướng dẫn nhập dữ liệu. Khoản hướng dẫn có thể cần nhiều giờ trong tháng đầu, còn phần mềm phát sinh nghĩa vụ phục vụ dài hơn. Gộp hai khoản thành một dòng thu rồi lấy làm cơ sở tăng trưởng định kỳ sẽ che giấu nhu cầu nhân lực. Tách hai sổ quản trị giúp nhìn ra phần nào có thể lặp lại, phần nào phải làm lại cho từng khách.

Tiền khách trả trước còn tạo nghĩa vụ giao hàng về sau. Một hợp đồng năm đem lại tiền sớm nhưng không khiến toàn bộ công việc phục vụ biến mất. Trong quản trị nội bộ, nhóm cần theo dõi lịch thu tiền, lịch thực hiện và các điều kiện hoàn trả riêng. Việc ghi nhận kế toán cụ thể phải được đối chiếu theo hợp đồng và quy định áp dụng, không suy ra từ tên gói dịch vụ.

Kiểm cơ chế chính trước khi bổ sung nguồn thu phụ

Một cuộc phỏng vấn YC công bố đầu năm 2025 với người đồng sáng lập Zip nhấn mạnh việc thu tiền ở những khách hàng đầu để kiểm nhu cầu thật. Đây là lời kể của người bán phần mềm trong thị trường doanh nghiệp; phạm vi quan sát không cho phép suy thành mức giá nên áp dụng ở nơi khác. Bài sử dụng ý nghĩa của phép thử trả tiền, không dùng số tiền người nói nêu làm chuẩn [7].

Từ đó có thể thiết kế một phép thử hẹp: cùng một nhóm khách, cùng đầu ra, cùng cách hỗ trợ, nhưng báo giá có điều khoản rõ. Ghi ai chấp nhận, ai từ chối và lý do cụ thể. Một lời đồng ý chưa đủ nếu không có bước mua thực tế. Ngược lại, từ chối vì chưa đến chu kỳ ngân sách không giống từ chối vì công việc không quan trọng.

Thêm nhiều dòng thu quá sớm làm khó việc đọc kết quả. Nếu khách vừa được miễn phí phần mềm, giảm phí triển khai và tặng dịch vụ, nhóm không biết thứ gì khiến họ đồng ý. Chọn một cơ chế chính không có nghĩa từ chối mọi tùy chỉnh; nó có nghĩa giữ được một giả thuyết dễ kiểm và một bộ sổ giải thích được doanh thu.

Hai cách đọc bảng giá tại Việt Nam

Trang giá AMIS CRM của MISA, được kiểm ngày 24/10/2026, thể hiện đơn vị người dùng mỗi tháng và bộ chọn quy mô đội bán hàng, cùng các gói tính năng. Bài chỉ dùng cách đóng gói được nhà cung cấp công khai; không kiểm doanh thu, biên lợi nhuận hay hiệu quả triển khai của khách hàng. Một đơn vị ghi trên bảng giá chưa đủ để kết luận toàn bộ chi phí sử dụng [8].

Trang Haravan cùng ngày trình bày gói với số nhân viên, số cửa hàng đi kèm và khoản mua thêm cửa hàng. Phần hỏi đáp cho biết gói có thời hạn và thanh toán theo năm. Đây là ví dụ tốt để phân biệt đơn vị niêm yết mỗi tháng với chu kỳ chi tiền thực tế. Điều kiện công khai có thể thay đổi; không nên dùng ảnh chụp một mức giá làm hợp đồng [9].

Hai trường hợp cho thấy giá phần mềm có thể gắn với nhiều đại lượng cùng lúc. Khi khảo sát thị trường Việt Nam, nhóm cần hỏi khách dự trù theo người, cơ sở hay tổng ngân sách năm. Cũng cần tách tiền phần mềm, tích hợp và công việc làm sạch dữ liệu. Bảng giá là dữ liệu về lời chào bán; bằng chứng khách mua và dùng lại phải đến từ việc kiểm thực tế.

Các câu hỏi khi đọc gói dịch vụ Việt Nam
Hình 3. Tách đơn vị niêm yết, chu kỳ trả tiền và phần mua thêm.

Góc nhìn AI: chuyển rủi ro cùng với cách thu tiền

AI tạo thêm lựa chọn thu phí, nhưng không xóa nhu cầu xác định ai chịu rủi ro. Thu theo ghế giúp người mua dễ dự trù, trong khi nhà cung cấp phải kiểm chi phí khi một người chạy nhiều tác vụ. Thu theo mức dùng làm chi phí biến động rõ hơn, song có thể khiến khách ngại thử. Thu theo kết quả cần thêm cách xác nhận chất lượng và xử lý tranh chấp.

Intercom cập nhật quy tắc Fin tháng 9/2026, gồm việc khách xác nhận hoặc hệ thống suy ra trường hợp đã giải quyết từ sự im lặng sau câu trả lời. Đây là định nghĩa vận hành riêng của hãng, không phải thước đo hài lòng được chấp nhận chung cho mọi sản phẩm [10].

Bài học phân tích là phải kiểm được sự kiện thu tiền trước khi cam kết theo kết quả. Một câu trả lời được hệ thống coi là hoàn tất có thể vẫn khiến khách tốn thời gian sửa. Vì vậy, nhóm nên lưu dấu vết xử lý, cho phép xem lại và phân biệt kết quả kỹ thuật với lợi ích kinh doanh. Việc khách im lặng không tự chứng minh họ hài lòng.

Khi dùng AI để thiết kế mô hình doanh thu, có thể nhờ nó so sánh ngoại lệ hoặc dựng các kịch bản sử dụng. Tuy nhiên, câu trả lời của mô hình không thay được phỏng vấn người mua hay sổ chi phí. Dữ liệu lịch sử có thể chỉ phản ánh nhóm khách từng chịu được bảng giá cũ. Một phương án mới cần thử với lượng dùng, tỷ lệ lỗi và công việc hỗ trợ thực tế.

Do đó, phép thử AI nên có giới hạn sử dụng, cách chuyển cho người và ngưỡng dừng lỗ được quyết định trước. Các giới hạn này thuộc thiết kế vận hành, không chỉ là một dòng chữ nhỏ trên bảng giá. Nếu chưa đo nổi đầu ra, nhóm có thể bắt đầu bằng gói có hạn mức rồi học tiếp, thay vì hứa giao một kết quả mà hai bên chưa thống nhất cách nhận biết.

Lập một hồ sơ thử mô hình trong bốn tuần

Hồ sơ thử không cần dự báo dài hạn thật đẹp; nó cần đủ rõ để người ngoài đọc được giả thuyết và điều gì sẽ bác bỏ giả thuyết ấy. Chọn một phân khúc hẹp, một công việc thường gặp và một cơ chế thu chính. Ghi cả số giờ hỗ trợ, ngoại lệ hóa đơn và lý do mua, tránh chỉ giữ tổng tiền nhận được.

  • Tuần đầu: xác định người dùng, người duyệt và nguồn ngân sách; mô tả đầu ra có thể bàn giao.
  • Tuần tiếp: đưa báo giá thật với đơn vị đo, hạn mức và điều kiện dừng dễ hiểu.
  • Tuần thứ ba: thực hiện một phạm vi nhỏ; ghi chi phí giao, lỗi và công việc sửa lại.
  • Tuần cuối: đối soát cùng khách; hỏi quyết định mua tiếp thay vì chỉ hỏi mức hài lòng.

Một phép thử ngắn khó chứng minh khả năng gia hạn năm hay tác động mùa vụ. Nếu chưa quan sát được chu kỳ mua lại, hãy ghi đó là khoảng trống. Quyết định tiếp theo có thể là kéo dài quan sát, thu hẹp cam kết hoặc thay đơn vị tính. Không cần kết luận mô hình đã đúng chỉ vì hợp đồng đầu tiên đã ký.

Vòng kiểm từ giả thuyết tới đối soát và điều chỉnh
Hình 4. Vòng kiểm một cơ chế thu tiền với khách thực tế.

Kết luận: giữ được đường nối từ giá trị đến tiền thu

Mô hình doanh thu đáng thử là mô hình giải thích được người trả, sự kiện tính phí, nghĩa vụ phục vụ và cách xử lý khi đầu ra không đạt. Các bản phân loại giúp mở rộng lựa chọn; dữ liệu mua và đối soát mới cho thấy lựa chọn nào phù hợp. Trước khi thêm nhiều dòng thu, hãy làm cho một dòng chính có thể lặp lại và kiểm tra được.

Nguồn và phương pháp

Bài tổng hợp có hỗ trợ AI, được viết bằng lập luận và ví dụ riêng, không phải bản dịch. Nguồn được mở ngày 24/10/2026 gồm Business Builder, thư viện Y Combinator, nghiên cứu trường đại học và tài liệu nhà cung cấp. Phạm vi đọc học thuật ghi trong hồ sơ biên tập; còn dữ kiện chưa kiểm chứng ngoài phạm vi được nêu, không khẳng định kiểm định mọi kết quả toàn văn. Các tình huống tự dựng không phải dữ liệu doanh nghiệp. Bảng giá chỉ minh họa cấu trúc công khai tại ngày kiểm; người đọc cần xem nguồn gốc và hợp đồng hiện hành.