# Định giá một con AI agent: cái khó không phải chọn con số, mà là biết mình đang bán cái gì
Mấy hôm trước mình có để lại một câu hỏi ở cuối bài: nếu dữ liệu công khai thì miễn phí, còn model thì cứ mạnh lên và rẻ đi mỗi quý, vậy người làm automation bán cái gì?
Câu trả lời mình đưa hôm đó là: bán phần phía sau — tầng lọc, tầng vận hành, tầng chịu trách nhiệm. Nghe xuôi. Nhưng nói được "bán cái gì" rồi, tự nhiên hiện ra một bức tường khác, mà mình nghĩ khó hơn hẳn: bán bao nhiêu.
Tuần này mình đọc được một bài đi đúng vào bức tường đó — về chuyện định giá một AI agent, và vì sao có tới năm kiểu giá khác nhau, không kiểu nào "đúng" cho mọi người. Đọc xong mình mới ngộ ra chỗ mình từng làm sai: mình cứ đi tìm một con số, trong khi thứ cần tìm là cái mình đang bán.
Vì sao giá phần mềm cũ không áp được cho agent
Phần mềm thường — kể cả SaaS — có một tính chất khiến chuyện định giá dễ thở: chi phí biên gần bằng không. Viết một cái app rồi bán cho 100 người hay 10.000 người, chi phí chạy thêm gần như không đổi. Nên mô hình thu tiền quen thuộc là thuê bao: theo tháng, theo số ghế, theo gói. Khách dùng bao nhiêu mặc khách. Càng đông người, biên lợi nhuận càng đẹp.
Một AI agent thì không vậy. Mỗi lần nó chạy, nó tiêu tiền thật: gọi model, gọi tool, đọc tài liệu, có khi đi vòng vòng rồi mới xong. Và cái trớ trêu là chi phí đó tỉ lệ với mức độ chăm chỉ của khách, chứ không tỉ lệ với giá trị khách nhận được.
Nghĩa là mô hình thuê bao phẳng — thứ vẫn in tiền cho SaaS — trở thành một cái bẫy:
- ▹Khách dùng ít → mình lời, nhưng khách thấy đắt và bỏ đi.
- ▹Khách dùng nhiều → mình tưởng được việc lớn, tới cuối tháng mở hoá đơn ra thì lỗ.
Và cái đau nhất: khách trả tiền nhiều nhất chưa chắc là khách tốt nhất. Nhiều khi người trả gói rẻ lại là người bấm nút nhiều nhất, vì với họ cái máy là thứ để thử.
Nên câu hỏi định giá không còn là "con số bao nhiêu". Nó là: mình gắn giá vào cái gì.
Cái thang năm nấc
Bài kia xếp năm cách thu tiền cho AI agent thành một cái thang. Mình thấy cách xếp đó hay, vì nó không nói "cách nào tốt nhất" mà cho mình biết mình đang đứng ở nấc nào, và bước lên thì đánh đổi cái gì.
Nấc 1 — Bán chỗ (thuê bao). Thu theo người dùng, theo tháng, theo phòng ban. Dễ bán nhất vì khách đã quen kiểu đó. Đổi lại, mình đang ôm toàn bộ rủi ro chi phí: khách càng chăm, mình càng mỏng.
Nấc 2 — Bán lượt tiêu (theo token, theo lần gọi). Mình thu đúng theo thứ mình đang phải trả. Về kế toán thì sạch sẽ. Về cảm xúc thì khá tệ: khách không biết tháng này sẽ tốn bao nhiêu, và tệ hơn, mình vô tình thưởng cho chính sản phẩm của mình việc nói dài, gọi nhiều tool, làm ẩu cho nhanh — vì càng tiêu nhiều, mình càng được tiền. Không ai muốn ngồi cạnh khoản đó.
Nấc 3 — Bán việc đã xong (theo đơn vị công việc). Thay vì bán "một lượt model", bán "một việc hoàn thành": một tài liệu đã xử lý, một yêu cầu đã trả lời, một đơn đã đối chiếu. Cái hay nhất: khách đếm được. Và mình tự chịu phần "chạy mấy bước mới xong". Nó kéo mình về đúng chỗ cần nghĩ — làm sao để một việc xong ngày càng rẻ, thay vì càng dài càng có lý.
Nấc 4 — Bán kết quả (theo outcome). Không thu theo việc, mà theo kết quả việc đó tạo ra: một đầu mối đã chốt, một khoản đã thu về, một khiếu nại bị chặn trước khi thành chuyện. Trần giá ở đây cao hơn hẳn nấc 3. Đổi lại, rủi ro dồn về mình: không ra kết quả thì không có tiền, trong khi chi phí chạy thì vẫn đã trả từ lâu.
Nấc 5 — Bán phần giá trị (chia phần). Mình tạo được bao nhiêu thì lấy theo đó: ăn theo khoản tiết kiệm, hay theo phần doanh thu tăng thêm. Trần cao nhất, nhưng cần đúng hai thứ khó nhất — đo được và được tin. Đo không nổi thì hai bên cãi nhau; không được tin thì khách không đời nào để mình đứng cạnh khoản doanh thu của họ.
Điểm mình thích ở cái thang: bước lên không phải là "xịn hơn", mà là chuyển rủi ro từ khách sang mình. Nấc càng cao, giá càng gắn với giá trị thật, nhưng mình càng phải đủ nội lực để gánh phần xui. Nên không phải cứ leo lên đỉnh là hay — rất nhiều sản phẩm sống rất ổn ở nấc 3.
Không biết sàn chi phí thì mọi nấc đều là đoán
Trong cùng ngày, mình đọc thêm một bài nữa, lần này về tối ưu chi phí hạ tầng dữ liệu cho đúng loại workload chạy agent. Ghép hai bài lại thì ra một điều mình coi là cốt lõi: dù chọn nấc nào, có một điều kiện không thể bỏ — mình phải biết một lần chạy tốn bao nhiêu.
Không biết thì mọi con số đều là đoán. Và cái đoán hay sai theo hướng dễ bị lộ nhất: mình nhớ những lần chạy ngon, quên những lần chạy toang. Hoá đơn thì nhớ hộ mình hết.
Con số cần biết không phải "giá một việc khi mọi thứ thuận lợi", mà là giá một việc đã giao thật, gồm cả những lần không đi tới đâu:
# PSEUDO-CODE minh hoạ — không phải nguồn triển khai
chi_phi_that = 0
for moi_viec_da_nhan:
chi_phi_that += chi phí lần chạy thành công
chi_phi_that += chi phí các lần thử lại
chi_phi_that += chi phí các lần chạy hỏng rồi bỏ
chi_phi_that += chi phí phần người phải chữa tay
gia_san = chi_phi_that / so_viec_da_giao_thatChỗ dễ sai nằm ở mẫu số. Nếu lấy "số lần bấm nút" làm mẫu, mình ra một con số đẹp. Nếu lấy "số việc giao được thật", mình ra con số thật — và con số thật thường đau hơn nhiều.
Ba cái bẫy mình từng dính, xếp theo mức thiệt hại:
- ▹Giá neo vào giá model. Model rẻ đi mỗi quý, thành ra giá mình cũng bị kéo xuống theo — trong khi mấy khoản còn lại (thử lại, người chữa, vận hành, tuân thủ) thì không rẻ đi chút nào. Neo giá vào token là tự trói mình vào thứ đang mất giá nhanh nhất.
- ▹Coi độ ổn định là miễn phí. Mỗi mắt xích mình thêm vào để hệ bớt toang đều là tiền thật: thêm bước kiểm, thêm cổng người quyết, thêm bản ghi để hậu kiểm. Nếu mình bán độ tin cậy mà không tính nó vào giá, mình đang bán độ tin cậy bằng tiền túi.
- ▹Không có trần. Một con agent chạy loạn một đêm — vòng lặp, thử lại, gọi tool sai — có thể đốt hết biên lợi nhuận của một khách trong cả tháng. Nên dù bán theo nấc nào, mình vẫn phải có van cứng: trần chi phí theo từng khách, và tự dừng khi vượt. Cái van đó không phải tính năng phụ. Nó là phần giữ cho mô hình giá còn sống.
Vậy chốt nấc nào? Ba câu hỏi
Mình rút ra ba câu, dùng để tự kiểm trước khi đưa giá ra:
- 1.Khách có đếm được cái mình bán không? Khách không đếm được thì mình không thu được theo nó. Có thu được một lần, rồi lần sau họ né.
- 2.Mình có đo được chi phí của một đơn vị không? Bán theo kết quả mà không đo được chi phí mỗi lần chạy thì đó là đánh bạc đội lốt định giá.
- 3.Khách dùng gấp 10 lần thì biên lợi nhuận còn dương không? Câu này lọc bỏ gần hết mô hình giá nghe hay. Nếu câu trả lời là "chắc không", thì con số đẹp ở câu 1 với câu 2 cũng vô nghĩa.
Mình tự chốt cho mấy thứ mình làm: giá = một tầng nền cố định + một đơn vị công việc đếm được + một cái trần. Tầng nền để khách thấy mình có cam kết. Đơn vị công việc để giá đi theo mức dùng, thay vì đi theo số câu model nói. Còn cái trần để một đêm xui không biến thành thảm hoạ cho cả hai bên.
Cái mình giữ lại
Định giá một con agent nghe như bài toán kế toán, nhưng thật ra nó là câu hỏi về mình dám chịu rủi ro tới đâu.
Vì ở mọi nấc, thứ khách trả tiền không phải là phần mềm. Nó là phần bất định mình gánh thay họ: chạy hỏng thì mình chịu, chạy dài thì mình chịu, model đổi tính thì mình chịu. Giá rẻ nhất là khi mình đẩy hết bất định về phía khách — nhưng khách không ngốc, họ cảm được ngay. Giá bền nhất là khi mình gánh được nhiều bất định nhất mà vẫn sống — và muốn sống thì phải biết sàn chi phí của chính mình, sớm hơn cả lúc biết giá.
Nên câu hỏi mình để lại cho anh em, cũng là câu mình tự hỏi sau hai bài hôm nay: nếu ngày mai khách của anh em dùng gấp 10 lần, mô hình giá hiện tại còn sống không? Nếu câu trả lời là không, thì giá của mình đang nói dối — và thị trường sẽ là người sửa câu đó, chỉ là sửa bằng cách khó chịu hơn.
Một phần của chuỗi mổ xẻ kỹ thuật tại zeodavu.com/blog. Nếu thấy hữu ích, theo dõi [zeodavu.com](/blog) — mỗi bài là một thứ mình thật sự dùng, vấp, và sửa lại.