Một doanh nghiệp mua phần mềm chăm sóc khách hàng vì muốn xử lý yêu cầu nhanh và tốt hơn. Nhưng sau khi đăng ký, họ vẫn cần xây dựng đội ngũ, đào tạo nhân viên, thiết lập quy trình và theo dõi chất lượng.
Phần mềm cung cấp công cụ. Để có kết quả, doanh nghiệp tiếp tục đầu tư công sức vận hành.
AI đang mở ra một lựa chọn khác: thay vì chỉ mua một hệ thống để đội ngũ sử dụng, doanh nghiệp có thể mua một phần công việc được hệ thống thực hiện và bàn giao theo tiêu chuẩn đã thống nhất.
Đó là ý tưởng phía sau Service as Software, gọi tắt là SaS trong bài viết này. Trọng tâm chuyển từ quyền truy cập phần mềm sang năng lực hoàn thành công việc.
Đây là một hướng phát triển của thị trường, không phải tuyên bố rằng toàn bộ SaaS sẽ được thay thế. Điều đáng quan tâm là ranh giới trách nhiệm giữa khách hàng và nhà cung cấp đang dịch chuyển.
1. SaaS giải quyết bài toán cung cấp phần mềm, SaS tiến gần hơn đến bài toán thực thi
SaaS — Software as a Service giúp khách hàng sử dụng phần mềm qua dịch vụ, thay vì tự triển khai và duy trì toàn bộ hạ tầng. Khách hàng có thể trả phí theo người dùng, mức sử dụng, tính năng hoặc các hình thức kết hợp.
Mô hình này giúp việc tiếp cận công nghệ thuận tiện hơn. Nhưng trong nhiều sản phẩm, khách hàng vẫn là bên trực tiếp tổ chức công việc: nhập dữ liệu, đọc báo cáo, đưa ra quyết định và điều phối các bước tiếp theo.
SaS — Service as Software đi xa hơn ở một phần của chuỗi giá trị. Nhà cung cấp dùng phần mềm và AI để thực hiện một công việc có phạm vi xác định, rồi bàn giao đầu ra có thể kiểm tra.
Thuật ngữ này cũng xuất hiện dưới các biến thể như “Services-as-Software”. Cách dùng chưa hoàn toàn thống nhất giữa các tác giả; trong bài này, SaS chỉ mô hình dịch vụ được thực thi chủ yếu bằng phần mềm và AI, có con người kiểm soát những phần cần phán đoán hoặc chịu trách nhiệm.
| Khía cạnh | SaaS thiên về công cụ | SaS thiên về thực thi |
|---|---|---|
| Giá trị được mua | Khả năng sử dụng một hệ thống | Một công việc hoặc đầu ra đã xác định |
| Tổ chức thực thi | Đội ngũ khách hàng vận hành công cụ | Nhà cung cấp đảm nhận phần việc trong phạm vi cam kết |
| Vai trò của người dùng | Thao tác, điều phối, kiểm tra | Đặt mục tiêu, cung cấp ngữ cảnh, duyệt ngoại lệ và nghiệm thu |
| Đơn vị tính phí có thể gặp | Người dùng, gói tính năng, mức sử dụng | Khối lượng công việc, đầu ra, kết quả hoặc gói kết hợp |
| Câu hỏi đánh giá | Công cụ giúp đội ngũ làm việc tốt hơn bao nhiêu? | Phần việc được hoàn thành đúng tiêu chuẩn với chi phí nào? |
Bảng này mô tả hai trọng tâm để so sánh. Một sản phẩm thực tế có thể kết hợp cả hai, và SaaS đã có nhiều khả năng tự động hóa từ trước khi AI Agent phổ biến.
2. Vì sao AI làm sự chuyển dịch này đáng chú ý?
Nhiều công việc doanh nghiệp nằm giữa các hệ thống: đọc email, hiểu yêu cầu, tìm hồ sơ liên quan, đối chiếu quy định, cập nhật dữ liệu và theo dõi phản hồi.
Những bước này khó tự động hóa hoàn toàn bằng một chuỗi điều kiện cố định khi đầu vào là ngôn ngữ tự nhiên, tài liệu nhiều định dạng hoặc tình huống có ngoại lệ.
AI có thể hỗ trợ diễn giải đầu vào, trích xuất thông tin, lập kế hoạch và lựa chọn công cụ. Khi kết hợp với API, quy tắc nghiệp vụ và cơ chế kiểm tra, khả năng ấy tạo điều kiện để phần mềm tham gia trực tiếp vào nhiều bước thực thi hơn.
Tuy nhiên, khả năng tạo ra một câu trả lời hợp lý chưa đủ để vận hành một dịch vụ. Hệ thống còn phải biết dữ liệu nào được phép dùng, hành động nào được thực hiện, khi nào phải dừng và ai tiếp nhận khi không thể hoàn thành.
Trong bài Services: The New Software, Julien Bek của Sequoia phân biệt mô hình hỗ trợ người làm chuyên môn với mô hình bán trực tiếp phần việc được thực hiện. Đây là một luận điểm đầu tư về hướng phát triển của thị trường, không phải bằng chứng rằng mọi ngành đã sẵn sàng vận hành tự chủ.
3. Từ phần mềm quản lý hóa đơn đến một bộ hồ sơ đã được đối soát
Hãy lấy một ví dụ minh họa: xử lý hóa đơn đầu vào.
Với một công cụ quản lý, nhân viên có thể tải hóa đơn lên, nhập thông tin, đối chiếu đơn hàng và chuyển người có thẩm quyền phê duyệt. Phần mềm lưu trữ dữ liệu và hỗ trợ quy trình, còn đội ngũ vẫn làm phần lớn công việc đối soát.
Một dịch vụ theo hướng SaS có thể được thiết kế để tiếp nhận hóa đơn, trích xuất dữ liệu, tìm đơn mua hàng liên quan, kiểm tra trùng lặp và chuẩn bị hồ sơ trình duyệt. Các trường hợp thiếu dữ liệu hoặc chênh lệch vượt ngưỡng được chuyển cho người phụ trách.
Đầu ra được mua khi đó là bộ hồ sơ đã đối soát theo quy tắc và sẵn sàng để người có thẩm quyền xem xét. Phạm vi này không bao gồm việc AI tự quyết định thanh toán.
Một định nghĩa nghiệm thu cần làm rõ:
- Những trường dữ liệu nào phải được kiểm tra và bằng chứng lấy từ đâu.
- Trường hợp nào được coi là hoàn thành, trường hợp nào là ngoại lệ.
- Ai có quyền phê duyệt và thời gian chờ phê duyệt được xử lý ra sao.
- Cách sửa lỗi, tránh tạo hồ sơ trùng và kiểm tra lịch sử thao tác.
Đây là ví dụ thiết kế dịch vụ, không phải mô tả một dự án đã được Newsoft triển khai. Nó cho thấy vì sao Service as Software cần được xây dựng quanh một đơn vị công việc rõ ràng.
4. Kết quả phải được định nghĩa trước khi được dùng để tính tiền
Một ví dụ thực tế là Fin AI Agent của Intercom. Tài liệu của hãng mô tả cách ghi nhận và tính phí theo các loại “outcome”, gồm giải quyết yêu cầu và một số trường hợp hoàn thành quy trình hoặc chuyển giao theo cấu hình. Một cuộc hội thoại chỉ bị tính tối đa một outcome. Xem định nghĩa outcome của Intercom.
Điểm đáng chú ý là nhà cung cấp phải giải thích thế nào được coi là hoàn thành. Theo tài liệu này, một “resolution” có thể được xác nhận bởi khách hàng hoặc được suy ra khi khách hàng không yêu cầu hỗ trợ thêm sau câu trả lời. Vì vậy, chỉ số được ghi nhận trong hệ thống cần được đọc cùng định nghĩa cụ thể của nó.
Từ ví dụ ấy, doanh nghiệp có thể rút ra một nguyên tắc: đơn vị tính phí phải đủ rõ để hai bên cùng kiểm chứng.
Một báo cáo đã tạo chưa chắc là báo cáo được nghiệm thu. Một email đã gửi chưa đồng nghĩa có khách hàng mới. Một hồ sơ đã phân loại chưa có nghĩa quyết định nghiệp vụ đã hoàn tất.
Cũng cần tách đầu ra mà nhà cung cấp kiểm soát được khỏi tác động kinh doanh chịu ảnh hưởng của nhiều bên. Một dịch vụ có thể cam kết thời gian xử lý hồ sơ và chất lượng đối soát; tăng doanh thu hay giảm toàn bộ chi phí vận hành còn phụ thuộc vào những yếu tố khác.
Service as Software không bắt buộc chỉ dùng một kiểu giá. Phí nền tảng kết hợp với phí theo khối lượng hoặc theo đầu ra có thể phù hợp hơn với một số quy trình. Thay đổi quan trọng nằm ở phạm vi thực thi và trách nhiệm, không chỉ ở cách viết bảng giá.
5. Khi bán kết quả, nhà cung cấp nhận thêm trách nhiệm vận hành
Nếu khách hàng mua một phần công việc đã hoàn thành, một giao diện hoạt động ổn định chưa đủ để chứng minh dịch vụ thành công.
Nhà cung cấp cần theo dõi tỷ lệ hoàn thành đúng, tỷ lệ phải sửa lại, thời gian xử lý, số ngoại lệ và chi phí kiểm tra của con người. Một hệ thống chạy nhiều bước nhưng thường xuyên cần khách hàng làm lại có thể chỉ chuyển gánh nặng từ thao tác sang giám sát.
Ở cấp độ kỹ thuật, dịch vụ cần kết nối dữ liệu, quản lý trạng thái xuyên suốt quy trình, giới hạn quyền hành động và giữ lại bằng chứng kiểm tra. Nó cũng cần xử lý được các tình huống thực tế: API gián đoạn, dữ liệu mâu thuẫn, thao tác bị gửi lại hoặc người duyệt chưa phản hồi.
Ở cấp độ kinh tế, chi phí thực thi cần tính cả mô hình AI, công cụ bên ngoài, tích hợp, nhân sự xử lý ngoại lệ và sửa lỗi. Giá suy luận thấp hơn không tự động biến một dịch vụ thành mô hình có biên lợi nhuận cao.
Đây là phân tích về điều kiện vận hành của mô hình: khả năng mở rộng phụ thuộc vào mức độ tái sử dụng quy trình và chất lượng, thay vì chỉ vào số lượng Agent có thể chạy đồng thời.
6. Lợi thế cạnh tranh nằm trong hiểu biết nghiệp vụ và khả năng kiểm chứng
Một mô hình AI tốt có thể được nhiều nhà cung cấp cùng tiếp cận. Khác biệt bền vững hơn có thể đến từ cách biến năng lực đó thành một dịch vụ đáng tin cậy cho một ngành hoặc một nhóm khách hàng cụ thể.
Những tài sản có giá trị gồm hiểu biết về ngoại lệ nghiệp vụ, tích hợp với hệ thống đang vận hành, bộ tiêu chí đánh giá và phản hồi từ những lần thực thi được kiểm tra. Dữ liệu chỉ có thể tạo giá trị khi được thu thập, sử dụng đúng quyền và gắn với kết quả đủ tin cậy.
Khách hàng cần biết dịch vụ làm được việc gì, trong điều kiện nào và có thể kiểm tra ra sao. Họ cũng cần xuất dữ liệu, thu hồi quyền truy cập và tiếp tục vận hành khi thay đổi nhà cung cấp.
Với doanh nghiệp phần mềm Việt Nam, đây là một hướng phát triển đáng cân nhắc: đóng gói hiểu biết về một quy trình thành dịch vụ có thể bàn giao và đo lường. Việc đó đòi hỏi năng lực nghiệp vụ, tích hợp và vận hành, bên cạnh năng lực viết mã.
7. SaaS và SaS có thể cùng tồn tại trong một sản phẩm
Có những công việc khách hàng cần giữ quyền thao tác trực tiếp. Có những quyết định cần chuyên gia, đối thoại hoặc hiểu biết về bối cảnh mà hệ thống chưa nắm đủ. Trong các trường hợp ấy, một công cụ hỗ trợ tốt vẫn rất có giá trị.
Một hướng phát triển thực tế là kết hợp ba lớp:
- Hệ thống lưu trữ và quản trị: giữ dữ liệu, phân quyền và quy tắc nền tảng.
- Trợ lý hỗ trợ chuyên môn: giúp con người phân tích, soạn thảo và lựa chọn phương án.
- Dịch vụ thực thi: hoàn thành các phần việc đã đủ rõ về đầu vào, đầu ra và giới hạn hành động.
Doanh nghiệp có thể chuyển từng phần việc từ lớp hỗ trợ sang lớp thực thi khi đã có bằng chứng về chất lượng. Không cần trao quyền tự chủ rộng chỉ vì mô hình AI vừa có thêm năng lực mới.
8. Bắt đầu từ một công việc có thể nghiệm thu
Một thử nghiệm phù hợp nên có đầu vào xác định, tần suất đủ để đánh giá, quyền truy cập rõ ràng và một người chịu trách nhiệm nghiệp vụ.
Trước khi triển khai, hãy ghi nhận cách làm hiện tại: thời gian thực hiện, chi phí, lỗi thường gặp và công sức kiểm tra. Sau đó thống nhất tiêu chí nghiệm thu, thử trên dữ liệu đại diện và tăng dần phạm vi hành động khi kết quả đáp ứng yêu cầu.
Câu hỏi cần trả lời sau thử nghiệm là: công việc có được hoàn thành đúng hơn, nhanh hơn hoặc với tổng chi phí thấp hơn khi đã tính cả giám sát và sửa lỗi hay không?
Hướng tiếp cận này kết nối với chủ đề sự chuyển dịch tổ chức ở AI-Native Company: khi AI tham gia thực thi, con người cần làm rõ mục tiêu, ngữ cảnh, cam kết và trách nhiệm phối hợp.
Ở góc độ công nghệ, độc giả có thể tìm hiểu thêm định hướng Nes Agent của Newsoft. Khả năng điều phối Agent là một thành phần để xây dựng dịch vụ; phạm vi và tiêu chuẩn của mỗi dịch vụ vẫn phải được thiết kế riêng.
Giá trị của phần mềm tiến gần hơn đến công việc được hoàn thành
Sự chuyển dịch từ SaaS sang SaS đặt ra một thay đổi trong cách xây dựng sản phẩm: bắt đầu từ công việc khách hàng muốn hoàn thành, rồi thiết kế hệ thống đủ năng lực để đảm nhận phần việc ấy.
Nhà cung cấp có cơ hội tạo ra nhiều giá trị hơn, đồng thời nhận thêm trách nhiệm về chất lượng và vận hành. Khách hàng có thể giảm công sức thực thi, nhưng vẫn cần khả năng đặt mục tiêu, kiểm tra kết quả và kiểm soát quyền hạn.
Service as Software trở nên thuyết phục khi lời hứa về kết quả được chuyển thành một dịch vụ có phạm vi rõ, bằng chứng đầy đủ và trách nhiệm có thể xác định.
Đó là phép thử đáng quan tâm khi đánh giá thế hệ sản phẩm AI tiếp theo: hệ thống đã giúp hoàn thành phần việc nào, và chúng ta biết điều đó bằng cách nào?