Khi chữ "xong" quyết định doanh thu của agent

Sierra, công ty của Bret Taylor, có một chính sách rất rõ: họ chỉ nhận tiền khi agent hoàn thành một tác vụ cho khách. Intercom niêm yết Fin ở mức 0,99 USD cho mỗi outcome, không tính theo seat hay token.

Thế nhưng trên diễn đàn cộng đồng của chính Intercom, một khách hàng viết rằng hãng nên thôi mặc định Fin đã giải quyết vấn đề mỗi khi nhân viên người thật trả lời khách sau Fin.

Ba chi tiết đó cùng chỉ về một điểm. Khi tiền chỉ chảy vào lúc việc được giải quyết, câu hỏi “thế nào là giải quyết xong” quyết định doanh thu. Người trả lời câu hỏi đó, đo nó và đẩy con số lên lại chính là kỹ sư làm việc cạnh khách hàng.

Nếu bạn đang muốn chuyển sang FDE, đây là điểm đáng hiểu kỹ. Khi khách trả theo seat, việc của kỹ sư có thể khép lại ở ngày bàn giao. Khi khách trả theo kết quả, cách kỹ sư triển khai và vận hành agent ảnh hưởng trực tiếp tới việc vendor thu được bao nhiêu.

“Đã giải quyết” là điều khoản hợp đồng, không phải cảm nhận

Sierra định nghĩa outcome bằng các sự kiện kinh doanh: một cuộc hội thoại hỗ trợ được giải quyết, một lượt hủy dịch vụ được giữ lại, một lần upsell, một lần cross-sell. Những cuộc hội thoại không giải quyết được thì phần lớn miễn phí. Nghe rất công bằng, cho đến lúc phải viết code để đếm.

Định nghĩa của Intercom cho thấy chỗ khó. Một outcome có thể được tính khi khách hoàn tất một workflow, nhưng cũng có thể được tính khi khách không hỏi thêm sau câu trả lời của Fin. Nói cách khác, sự im lặng được coi là đã giải quyết. Đó là một giả định, và giả định nào rồi cũng sẽ có khách phản đối.

Lời phàn nàn trên diễn đàn Intercom là ví dụ điển hình. Thử hình dung một ca cụ thể: khách hỏi về hoàn tiền, Fin trả lời, rồi nhân viên vào trả lời tiếp vì câu trả lời của Fin chưa đủ. Hệ thống ghi đó là một resolution của Fin, còn đội hỗ trợ của khách thì thấy họ đang trả tiền cho việc người của mình làm.

Manny Medina đã nêu đúng sự mơ hồ này trong một bài phân tích của Sequoia. Outcome là thời gian xử lý? Là việc khách giải quyết xong ticket rồi mua thêm? Là CSAT? Hay NPS? Mỗi đáp án dẫn tới một pipeline đo lường khác nhau, và chọn đáp án nào là quyết định phải đưa ra trong lúc deployment chứ không thể để lại trên slide bán hàng.

Mỗi điểm phần trăm resolution là doanh thu

Case study của AWS về Intercom và Anthropic cho biết Fin đạt resolution rate trung bình 56% trong 30 ngày đầu sau deployment. Với vendor tính tiền theo outcome, con số đó không còn là một chỉ số chất lượng đơn thuần. Nó là đòn bẩy doanh thu.

Thử làm một phép tính giả định. Một khách hàng có 10.000 cuộc hội thoại mỗi tháng, ở mức 56% thì có 5.600 outcome được tính tiền.

Nếu kỹ sư tìm ra ba nhóm câu hỏi agent hay trả lời sai, sửa knowledge base và luồng gọi tool, rồi đẩy tỷ lệ lên 60%, vendor có thêm 400 outcome mỗi tháng mà không cần bán thêm hợp đồng nào.

Phép tính này còn có chiều ngược lại. Nếu định nghĩa outcome quá rộng, ví dụ coi mọi lần khách im lặng là đã giải quyết, con số trên dashboard sẽ đẹp nhưng niềm tin của khách sẽ giảm, như lời phàn nàn trên diễn đàn đã cho thấy.

Vì vậy FDE giỏi không tìm cách tăng con số bằng mọi giá. Việc của họ là làm cho con số đó trung thực, rồi mới tăng nó.

Sierra cũng nói rõ công việc không dừng ở ngày go-live. Hãng viết rằng sau khi ra mắt, họ tiếp tục thực hiện những đợt tối ưu tập trung, có định hướng để cải thiện hiệu năng của agent theo thời gian. Với giá theo kết quả, chính doanh thu từ outcome trả tiền cho phần việc đó.

Ba điều kiện của Sequoia đều là việc của FDE

Bài phân tích của Sequoia về lộ trình trưởng thành của mô hình giá cho các công ty agentic AI liệt kê những điều kiện cần có trước khi tính tiền theo kết quả. Một trong số đó là định nghĩa rõ thành công trông như thế nào với từng khách hàng. Hai điều kiện còn lại là đo outcome một cách đáng tin và giao kết quả ổn định.

Đọc kỹ chữ “từng khách hàng”. Một công ty viễn thông có thể coi việc giữ chân khách định hủy gói cước là outcome quan trọng nhất, trong khi một sàn thương mại điện tử lại quan tâm tới số đơn đổi trả được xử lý mà không cần người. Không có định nghĩa nào dùng chung được, nên phải có người ngồi với khách để chốt định nghĩa riêng.

Điều kiện đo lường đáng tin cũng là việc kỹ thuật thực sự. Nó gồm việc xác định sự kiện nào trong hệ thống của khách đánh dấu một ca đã xong, xử lý những ca nhân viên chen vào, và quyết định im lặng bao lâu thì được tính. Những quyết định đó thuộc về người hiểu cả log của agent lẫn quy trình vận hành của khách.

Đặt mô hình giá cũ và mới cạnh nhau sẽ thấy công việc của FDE dịch chuyển ra sao. Bảng dưới đây là suy luận từ các dữ kiện nêu trên, không phải mô tả của một công ty cụ thể nào.

Khía cạnh	Giá theo seat hoặc token	Giá theo kết quả
Ai chịu rủi ro khi agent trả lời sai	Chủ yếu là khách	Vendor, vì ca không giải quyết được phần lớn không thu tiền
Câu hỏi đầu tiên với khách	Cần bao nhiêu user, tích hợp hệ thống nào	Với riêng khách này, thế nào là một ca đã giải quyết
Thời điểm việc của kỹ sư kết thúc	Thường là lúc go-live	Không kết thúc, vì tối ưu sau go-live là nguồn doanh thu
Chỉ số kỹ sư phải bảo vệ	Uptime, độ trễ	Resolution rate và độ tin cậy của cách đếm
Nguồn tranh chấp điển hình	Hóa đơn sử dụng	Định nghĩa outcome, ví dụ có tính khi nhân viên trả lời sau bot hay không

Vì sao Sierra gọi người làm việc này là agent engineer

Natalie Meurer của Sierra cho rằng FDE được định nghĩa rõ nhất bởi trách nhiệm giải trình với khách hàng, hơn là bởi hình thức của vai trò hay loại việc đang làm.

Dù vậy, Sierra vẫn chủ động đặt tên vai trò là “agent engineer”. Hãng giải thích rằng chức danh nên thể hiện được bản chất kỹ thuật của công việc, chứ không chỉ nói về sự tận tâm với khách hàng.

Hai ý tưởng này khớp với mô hình giá. Theo bản tóm tắt của ZenML về bài nói của Sierra, trách nhiệm của các kỹ sư này gắn với những kết quả cụ thể như một giao dịch bán hàng hoàn tất hay một yêu cầu của khách được giải quyết. Đó chính là những thứ xuất hiện trên hóa đơn.

Bret Taylor gói thái độ cần có trong một lời khuyên gửi các vendor: hãy đến với khách như một đối tác và giúp họ giải những bài toán kinh doanh cấp bách. Trong mô hình theo kết quả, câu này không chỉ là khẩu hiệu. Nếu không giải được bài toán của khách thì vendor không có doanh thu.

Bạn nên luyện gì nếu muốn làm việc này

Kỹ năng hiếm nhất ở đây không phải viết prompt. Đó là khả năng biến một mục tiêu kinh doanh mơ hồ thành một định nghĩa đo được, rồi bảo vệ định nghĩa đó trước cả đội vận hành của khách lẫn đội sales của mình. Developer Việt Nam từng làm hệ thống chăm sóc khách hàng, CRM hoặc pipeline analytics đã có sẵn một nửa nền tảng.

Khi đọc JD, hãy để ý các cụm như “resolution rate”, “outcome”, “success metrics”, “agent engineer”. Gặp những cụm này, bạn nên hỏi thẳng nhà tuyển dụng xem kỹ sư có chịu trách nhiệm với con số sau go-live hay chỉ làm phần tích hợp.

Trong buổi phỏng vấn, bạn có thể hỏi thêm: công ty tính một ca là đã giải quyết như thế nào, và ai được quyền thay đổi định nghĩa đó.

Với CV, một dòng như “xây chatbot hỗ trợ khách hàng” gần như không nói lên gì. Hãy viết theo dạng: định nghĩa chỉ số ra sao, đo bằng sự kiện nào, xử lý ngoại lệ thế nào, và con số thay đổi từ bao nhiêu lên bao nhiêu.

Ứng viên nào kể được một lần mình phát hiện cách đếm cũ đang thổi phồng kết quả và sửa nó sẽ được nhớ lâu hơn ứng viên chỉ khoe tỷ lệ cao.

Giá theo kết quả buộc vendor phải đứng chung rủi ro với khách. Kỹ sư nào chốt được với khách thế nào là “xong”, rồi giữ cho cách đếm đó trung thực sau go-live, sẽ là người công ty khó thay thế nhất.