# Một đơn hàng không có người mua: khi khách của mình là một con agent
Đêm đó có một đơn hàng vào lúc gần bốn giờ sáng.
Không có email. Không có tên. Không có phiên đăng nhập nào được mở ra, không có nút "Mua" nào bị bấm, không có ai đọc điều khoản sử dụng. Chỉ có một request gõ cửa, mang theo đúng một con số tiền, kèm một chứng từ thanh toán nhỏ xíu gắn ngay trong thân request.
Hệ của mình kiểm chứng từ đó, thấy hợp lệ, chạy việc, trả kết quả, và ghi lại một dòng sổ: đã bán một lần, giá vài phần nghìn đô.
Mình ngồi nhìn cái log đó một lúc lâu.
Vì trong nhiều năm làm phần mềm, mình chưa từng bán được món gì mà không có người mua. Luôn có một ai đó ở đầu bên kia: một cái email, một cái thẻ, một cái chữ ký, một người sẽ hỏi "sao tháng này đắt thế". Đêm đó thì không. Khách hàng của mình là một con agent, và nó đã trả tiền xong trước khi mình kịp biết nó tồn tại.
Tuần này mình đọc một bài công khai về đúng kiểu sản phẩm đó: một tiện ích nhỏ (quy đổi tỷ giá) được thiết kế để chính agent gọi và tự trả tiền theo từng lần gọi — không cần đăng ký, không cần khoá API, thanh toán nằm trong chính lần gọi, bán theo gói số lần, và lần gọi hỏng thì không tính tiền.
Nghe như một mẩu quảng cáo. Nhưng mình nghĩ nó là một trong những thay đổi cấu trúc đáng chú ý nhất của năm, và hầu như ai bán automation cũng sẽ đụng nó sớm hơn mình tưởng.
Cái phễu bị nén lại còn ba câu hỏi
Hãy nhớ lại phễu bán hàng bình thường của một món phần mềm. Thấy quảng cáo. Vào landing page. Đọc vài dòng. Đăng ký tài khoản. Xác nhận email. Dùng thử. Tới giới hạn. Nhập thẻ. Kích hoạt. Rồi mới có lần dùng thật đầu tiên.
Bảy bước. Mỗi bước rơi mất một phần người. Cả ngành marketing sống bằng việc vá mấy chỗ rơi đó.
Giờ bỏ hết bảy bước ấy đi và thay bằng một con agent đang cần một việc cụ thể, ngay lúc này, và có sẵn tiền. Nó không thấy landing page. Nó không "đọc vài dòng rồi thấy thuyết phục". Nó thấy một danh sách công cụ, và trong đó có một dòng mô tả ngắn.
Toàn bộ phễu của mình, lúc đó, co lại thành ba câu hỏi, và cả ba được trả lời trong khoảng một giây:
Một — nó có tìm thấy mình không? Đây là phần thay cho toàn bộ khâu marketing. Không phải SEO, không phải quảng cáo: là mình có nằm trong danh sách công cụ mà loại agent đó đang nhìn vào hay không. Nằm sai chỗ thì hay tới mấy cũng bằng không.
Hai — mô tả của mình có đủ rõ để nó gọi đúng ngay lần đầu không? Đây là phần thay cho toàn bộ khâu onboarding, đọc tài liệu, xem video hướng dẫn. Nếu con agent gọi sai tham số lần đầu, nó không "quay lại sau khi đọc thêm". Nó ghi một dòng lỗi và đi đường khác.
Ba — giá và cách trả có nằm trong khả năng của nó không? Không có "liên hệ sale". Không có "dùng thử 14 ngày cần xác nhận thẻ". Nếu trả tiền bắt buộc phải có một người, thì với khách này mình không tồn tại.
Mình từng nghĩ đây là chuyện của vài năm nữa. Nhưng cái log lúc bốn giờ sáng kia bảo mình khác.
Không có tài khoản thì lấy gì để tính tiền?
Đây là chỗ đau nhất, và cũng là chỗ mình nghĩ nhiều người sẽ làm sai.
Toàn bộ hệ thống thu tiền mà mình từng dựng — cái nào cũng xoay quanh một danh tính người: email để gửi hoá đơn, thẻ để trừ tiền định kỳ, hợp đồng để quy trách nhiệm, và một bộ phận để đòi khi khách không trả. Bốn thứ đó gọi là billing.
Con agent không có cái nào trong bốn. Nó không có email. Không có thẻ. Không ký được hợp đồng. Và quan trọng nhất: nó không đọc hoá đơn — nên khái niệm "công nợ" mất luôn ý nghĩa.
Nên hệ thu tiền phải đổi ba thứ:
Đơn vị tính: một lần gọi, không phải một chỗ ngồi. Bán theo "ghế" thì cần biết ai ngồi. Không có ai ngồi thì bán theo việc đã xong.
Chứng từ: trả trước, và biên lai trả về ngay trong kết quả. Cái này mình học được từ phía bên kia bàn — bên mua cũng cần bằng chứng. Nếu response trả về chỉ có dữ liệu mà không có dòng "lần này trừ bao nhiêu, còn lại bao nhiêu", thì con agent (và người đứng sau nó) không có gì để đối chiếu, và mọi tranh chấp sau đó thành chuyện niềm tin. Một dòng receipt nhỏ trong response rẻ hơn rất nhiều so với một bộ phận chăm sóc khách hàng.
Thanh toán: nằm trong chính lần gọi. Không có chu kỳ, nên không có chỗ cho trả chậm — cũng không có chỗ cho nợ xấu. Đổi lại, mình mất luôn cái van an toàn quen thuộc: không thể "tạm ngưng tài khoản" khi có sự cố.
Rồi tới chỗ dễ nói mà khó làm: gọi hỏng thì không tính tiền. Nghe hiển nhiên. Nhưng "hỏng" có hai loại, và trộn hai loại đó là tự bắn vào chân:
- ▹Hỏng vì bên mình — hết hạn mức nội bộ, nguồn dữ liệu chết, timeout khi gọi ra ngoài. Loại này không được tính, dù mình đã tiêu tiền thật cho lần gọi đó.
- ▹Hỏng vì bên gọi gửi rác — sai định dạng, thiếu trường, tham số vô nghĩa. Loại này tính hay không là chuyện chính sách, nhưng phải nói rõ trước khi nó xảy ra, bằng một câu trong mô tả công cụ.
Vì con agent không cãi được. Nó không mở ticket. Nó chỉ... không gọi nữa. Và người đứng sau nó, hai tuần sau, nhìn hoá đơn thấy tiền tăng mà kết quả không có, sẽ rút cả cái tích hợp ra chứ không đi tìm hiểu ai đúng.
Cái khung tối thiểu nó trông như thế này (pseudo-code, không phải nguồn triển khai):
POST /convert
body: { input, payment_proof, request_id }
verify(payment_proof) -> sai thì 402, không chạm máy chủ nào khác
check_cap(request_id / payer) -> vượt trần thì 429 + số còn lại
execute(input) -> lỗi phía mình: trả lỗi, KHÔNG commit meter
commit_meter(từng bậc, không phải gộp)
return { result, receipt: { đã trừ bao nhiêu, còn lại bao nhiêu } }Ba dòng đáng chú ý: verify đứng trước mọi thứ khác để lần gọi rác không tốn một đồng hạ tầng nào. commit_meter đứng sau execute để nguyên tắc "không có kết quả thì không có hoá đơn" là thứ được code cưỡng chế, không phải lời hứa. Và request_id không phải để cho đẹp — retry là chuyện chắc chắn xảy ra, và tiền là loại hành động không được phép xảy ra hai lần.
Không có đăng ký thì chặn lạm dụng bằng gì?
Đây là câu mình bị hỏi nhiều nhất, và câu trả lời thật thà là: mình không chặn được theo người, nên phải chặn bằng giá.
Không có tài khoản thì không có chỗ nào để gắn rate limit. Cái van duy nhất còn lại là chi phí của lần gọi đầu tiên — đủ nhỏ để một con agent dám thử, đủ lớn để spam không đáng. Đó là lý do mấy sản phẩm kiểu này luôn bán theo gói nhỏ, giá tính bằng phần nghìn: không phải vì họ thích rẻ, mà vì cái giá đó chính là bộ lọc.
Thêm hai cái van mình cho là bắt buộc:
Trần theo thời gian, gắn với chứng từ thanh toán chứ không gắn với người. Một chứng từ chỉ được tiêu trong một cửa sổ nhất định, và có trần tổng. Hết thì phải mua thêm — và việc mua thêm là quyết định của người phía sau, không phải của con agent. Nâng hạn mức tự động là mời một vòng lặp tiêu tiền mà không ai duyệt.
Trần chi phí nội bộ cho mỗi lần gọi. Cái này mình học từ chính mấy vụ lùm xùm về agent trong năm nay: một lần gọi giá vài phần nghìn, nhưng để phục vụ nó mình có thể gọi ra ngoài, đọc dữ liệu lớn, chạy mấy vòng. Nếu không đặt trần cho phần mình tiêu, thì chỉ cần một người mua đúng một gói nhỏ là đủ làm mình lỗ cả tháng. Nghe buồn cười, nhưng đây là kiểu lỗ khó thấy nhất: doanh thu tăng, log xanh, và tài khoản hạ tầng bốc khói.
Cái bẫy lớn nhất: máy không trung thành
Đây là phần mình muốn anh em đọc kỹ nhất.
Con agent không "thích" sản phẩm của mình. Nó không có thói quen, không có ký ức thương hiệu, không có cảm giác "dùng cái này lâu rồi nên ngại đổi". Nó chọn mình vì lần gọi đó đúng và rẻ, và nó đổi sang thứ khác trong một request nếu có thứ tốt hơn.
Chi phí chuyển đổi gần bằng không. Nghĩa là toàn bộ mấy trò mình học được trong mười năm qua — giữ khách bằng onboarding, bằng dữ liệu dính vào tài khoản, bằng thói quen giao diện — đều mất tác dụng.
Vậy cái gì còn lại?
Không phải code. Code của mấy tiện ích kiểu này ai cũng viết được trong một buổi chiều. Đó chính là lý do nó phải rẻ.
Mà là phần phải bảo trì. Nguồn dữ liệu thay đổi. Định dạng đổi. Có ngày lễ, có bản ghi lỗi, có đơn vị đã chết mà vẫn nằm trong danh sách. Có chuyện múi giờ. Có chuyện chính sách của bên cấp dữ liệu đổi mà không báo. Con agent không biết những thứ đó — nó chỉ biết lần gọi vừa rồi trả về đúng hay không.
Nên cái mình thật sự bán không phải "một endpoint quy đổi". Là một endpoint quy đổi mà không ai phải nghĩ tới nó nữa. Và cái đó thì không ai copy trong một buổi chiều, vì nó là một chuỗi quyết định nhỏ nối tiếp nhau trong nhiều tháng.
Và cạm bẫy thứ hai, cái này tinh vi hơn: bán theo số lần gọi nghĩa là doanh thu tỉ lệ với số lần gọi. Nhưng con agent giỏi nhất ở đúng một việc: gọi ít đi. Nó cache, nó gộp, nó tự viết một hàm con để khỏi gọi ra ngoài. Khách hàng lý tưởng của mình là khách hàng đang cố gắng trở thành khách hàng ít hơn.
Mình không nghĩ đó là lý do để bỏ mô hình này. Nhưng nó là lý do để đơn giá phải tính cho giá trị của lần gọi đúng, chứ không tính cho "công sức mình bỏ ra". Vì cái công sức đó, con agent sẽ tìm cách xoá sổ ngay khi nó rẻ hơn.
Nối vào cái thang thu tiền
Mấy bài trước mình có kể cái thang thu tiền cho sản phẩm AI: bán chỗ ngồi → bán lượt tiêu → bán việc đã xong → bán kết quả → chia phần. Mỗi nấc là một lần chuyển rủi ro từ khách sang mình.
Cái cửa hàng cho máy này nằm ở nấc thấp nhất — bán lượt tiêu. Nhưng nó có một đặc tính mà mấy nấc trên không có: chi phí bán hàng gần bằng không.
Không sales. Không demo. Không onboard. Không email nuôi dưỡng. Không cuộc gọi nào. Một khi cái endpoint nằm đúng chỗ và mô tả đủ rõ, nó tự bán, hai mươi bốn giờ, kể cả lúc mình đang ngủ.
Biên lợi nhuận mỏng, nhưng cấu trúc chi phí thì sạch. Và với một người làm một mình — không có team, không có giờ hành chính — đó có thể là mô hình duy nhất thật sự chạy được.
Chỉ có một điều kiện: đừng mang mô hình này đi bán mấy việc cần tư vấn. Nếu sản phẩm của mình cần khảo sát, cần mapping dữ liệu, cần ai đó ngồi cùng khách để hiểu quy trình, thì nó không phải primitive, và cái "cửa hàng cho máy" sẽ chỉ là một cái landing page đội lốt. Mình đã thử ghép hai thứ đó lại. Nó ra một món không bán được cho ai: quá phức tạp cho agent, quá hời hợt cho người.
Ba câu tự soi trước khi dựng
Không cần framework. Chỉ ba câu:
- 1.Việc mình bán có gọi được bằng MỘT request không? Nếu cần ba bước thiết lập, xác nhận, cấu hình — thì khách của mình vẫn là người, và mọi thiết kế "cho agent" chỉ là trang trí.
- 2.Nếu khách không để lại email, mình có biết nó đã dùng đúng không? Không có biên lai và không có log đối chiếu thì mình không học được gì từ khách hàng này — và cũng không cãi được khi có chuyện.
- 3.Nếu ngày mai có bản miễn phí y hệt, cái gì còn lại? Nếu câu trả lời là "không biết", thì sản phẩm này chưa phải một sản phẩm — nó là một bài tập.
Kết
Mình vẫn chưa quen với cảm giác bán được hàng cho một thứ không có tên, không có email, không bao giờ nói cảm ơn.
Nhưng có một chi tiết làm mình nghĩ lại về rất nhiều thứ: con agent đó không cần mình thuyết phục. Nó không cần câu chuyện thương hiệu, không cần ảnh đẹp, không cần mình giải thích vì sao mình đáng tin. Nó chỉ cần ba điều đúng — tìm thấy, gọi đúng, trả được. Ba điều đó, hoá ra, khó hơn toàn bộ phần marketing mình từng làm.
Và nếu mình thành thật: rất nhiều sản phẩm mình từng làm sẽ không qua nổi bài kiểm tra ba câu đó. Không phải vì chúng dở. Mà vì chúng được thiết kế cho một kiểu khách hàng đang dần ít đi.
Anh em đang có món gì được gọi mà không có ai đăng ký chưa? Hay vẫn đang phải giữ một cái form đăng ký ở đầu phễu vì "chưa biết tính tiền kiểu gì"? Mình tò mò nhất là chuyện hoàn tiền — mình vẫn chưa nghĩ ra cách xử lý cho gọn khi bên gọi là máy mà bên trả là người.