SaaS tính phí theo seat sắp bị lật: khi agent thay người ngồi vào hệ thống

TL;DR: Hầu hết SaaS doanh nghiệp tính phí theo seat — mỗi người dùng một tài khoản, mỗi tài khoản một khoản tiền mỗi tháng. Mô hình đó dựa trên một giả định ngầm: một seat tương đương một con người làm việc. Khi AI agent làm được phần việc của nhiều người, và service account tự gọi API cả ngày không cần ai ngồi trước màn hình, giả định đó bắt đầu gãy. Toàn bài dưới đây là nhận định của chúng tôi — không có số liệu thị trường để trích, và chúng tôi không bịa — nhưng những câu hỏi đàm phán hợp đồng ở cuối bài thì nên hỏi thật từ chu kỳ mua sắm 2026–2027.

Mô hình seat: giá trị của một tài khoản đang đổi chủ

Suốt hai thập kỷ, phép tính giá SaaS doanh nghiệp đơn giản: nhân viên càng nhiều, hóa đơn càng lớn. Seat là người — người đăng nhập, người nhập liệu, người đọc báo cáo.

Agent làm hai thứ phá phép tính này:

1. Agent làm việc của nhiều người. Một agent đọc tin nhắn khách, cập nhật CRM, soạn báo cáo — phần việc trước đây cần vài seat của vài hệ thống.
2. Agent cần tài khoản để vào hệ thống. Nó là service account: đăng nhập, đọc/ghi qua API, chạy liên tục. Theo hợp đồng kiểu cũ, đó vẫn là "một user" — nhưng nó không phải một người.

Kịch bản để hình dung (nhận định, không phải số liệu): một nhóm 20 nhân viên cần 20 tài khoản hệ thống. Sau khi tự động hoá bằng agent, cơ cấu trở thành 5 người điều hành và duyệt + 10 agent/service account làm thực thi + người ngoài luồng chỉ thỉnh thoảng duyệt. Câu hỏi đặt ra: hóa đơn nên tính theo 15 tài khoản kỹ thuật, hay theo giá trị công việc mà 10 agent kia tạo ra? Nhà cung cấp nào giữ nguyên cách tính cũ, khách hàng sớm muộn cũng hỏi lại — hoặc rời đi.

Nhà cung cấp sẽ phải đổi cách tính giá — theo hướng usage

Nhận định của chúng tôi: mô hình giá SaaS doanh nghiệp sẽ dịch chuyển khỏi seat thuần, sang các trục tính phí theo mức dùng thực tế — theo action, theo workflow đã chạy, theo token, hoặc theo số agent đang hoạt động. Lý do không phải lòng tốt: khi doanh thu của nhà cung cấp gắn với số người mà chính sản phẩm của họ đang giúp giảm, mô hình seat tự mâu thuẫn với giá trị sản phẩm.

Một tín hiệu phụ đáng chú ý (và đây mới chỉ là hạ tầng, chưa phải bảng giá): tại sự kiện Feishu Future 2026, Feishu 8.0 giới thiệu công cụ đo mức dùng AI theo token kèm API phân tích usage cho doanh nghiệp (khoảng mốc 00:18–00:28 trong video sự kiện). Hạ tầng đo lường usage là điều kiện cần để một bảng giá usage-based ra đời — không đo được thì không tính tiền theo đó được.

Tính năng được công bố tại sự kiện Feishu (thị trường Trung Quốc) ngày 15/09/2026; chưa kiểm chứng tính sẵn có trên LarkSuite quốc tế và tại Việt Nam.

Cần nói rõ: có công cụ đo usage không đồng nghĩa đang đổi cách tính giá. Trên đây là dấu hiệu chuẩn bị, không phải bảng báo giá mới.

Ba câu hỏi nên hỏi thật khi đàm phán hợp đồng 2026–2027

Dù dự báo đúng hay sai, hợp đồng bạn ký năm nay vẫn chịu tác động của nó. Ba câu hỏi nên đưa vào bàn đàm phán:

1. Service account và agent account giá bao nhiêu? Có được coi là seat full price, giá giảm, hay free? Đây là khoản mà nhiều nhà cung cấp chưa có chính sách rõ — hỏi sớm để không ngạc nhiên về sau.
2. Chi phí mỗi lần agent gọi API/automation tính thế nào? Có soft limit không, vượt limit thì sao, có cách mua trước theo khối không?
3. Khóa giá theo seat được bao lâu? Nếu nhà cung cấp chuẩn bị chuyển sang usage-based, điều khoản bảo vệ giá seat hiện tại cho kỳ hợp đồng kế tiếp là thứ đáng đổi lấy cam kết dài hơi.

Thêm một câu phòng hờ: phí xuất dữ liệu khi hết hợp đồng là bao nhiêu? Khi mô hình giá đổi, khả năng mang dữ liệu rời đi là đòn cân bằng thực tế nhất của người mua. Nguyên tắc tính tổng chi phí sở hữu — không chỉ giá niêm yết — đã được chúng tôi phân tích trong cách tính TCO bộ công cụ làm việc doanh nghiệp.

Góc Diginno: kiến trúc hai lớp để không bị khóa theo giá seat của một hãng

Cách phòng thủ mà chúng tôi đang áp dụng cho khách và cho chính mình: tách lớp dữ liệu khỏi lớp công cụ.

• Lớp một — system of record: dữ liệu khách hàng, đơn hàng, quy trình nằm ở nơi có cấu trúc và xuất được (LarkBase, hoặc ERP/Postgres khi doanh nghiệp lớn hơn). Đây là lớp "sự thật" — đổi công cụ phía trên không mất dữ liệu.
• Lớp hai — automation và agent: n8n, workflow, agent chạy phía trên, đọc/ghi vào lớp một qua API. Agent đổi nền tảng thì luồng dữ liệu vẫn nguyên.

Với kiến trúc này, nếu một nhà cung cấp đổi cách tính giá theo hướng bất lợi, bạn di chuyển phần công cụ chứ không di chuyển dữ liệu và quy trình — rủi ro lock-in giảm hẳn. Bài thực hành kèm theo: so sánh 5 gói LarkSuite nên chọn gói nào để thấy giá seat thực tế khác nhau ra sao giữa các gói; Odoo Community vs Enterprise: chi phí thật cho thấy giá bản quyền chỉ là một phần TCO; và phân quyền Odoo record rule khi có tài khoản AI cho ví dụ cụ thể việc quản service account của agent trong một hệ thống production.

Kết

Mô hình giá per-seat không sụp đổ trong một đêm — nhưng giả định "một tài khoản là một người" đang yếu dần từng tháng. Người mua phần mềm không cần chờ dự báo đúng: chỉ cần thêm ba câu hỏi trên vào checklist đàm phán hợp đồng kế tiếp, và giữ cho dữ liệu của mình luôn nằm ở lớp có thể rời đi. Đó là hai việc làm được ngay, không phụ thuộc bất kỳ nhà cung cấp nào đổi giá hay không.