Dịch vụ dùng chung trong kỷ nguyên AI Agent: Từ xử lý ticket đến điều phối kết quả

Bạn có đội tài chính dành nửa ngày để lùng dữ liệu trên ba hệ thống chỉ vì một hóa đơn lỗi? Nhân sự trả lời cùng câu hỏi onboarding lần thứ mười trong tuần, dù câu trả lời nằm sẵn trong knowledge base? IT support đốt giờ cho reset mật khẩu trong khi ticket phức tạp chờ xử lý?

Shared services từng là giải pháp hợp lý: chuẩn hóa quy trình, gom khối lượng, tối ưu nhờ quy mô. Nhưng logic đó đang chạm trần. Khối lượng tăng. Ngoại lệ nhân lên. Kỳ vọng chuyển từ "xử lý đúng quy trình" sang "giải quyết ngay lập tức". Ticket chất đống. Bàn giao chồng chéo. SLA đạt trên giấy, nhưng trải nghiệm vẫn rời rạc.

Đây là lúc agentic services xuất hiện — không phải lớp chatbot phủ lên service desk cũ, mà là tái thiết kế cách dịch vụ được vận hành. Mục tiêu không phải thay người. Mục tiêu là chuyển mô hình từ cỗ máy xử lý ticket thủ công sang đội ngũ người-agent cùng hướng tới kết quả.

Tại sao Shared Services là điểm khởi đầu lý tưởng

Không phải chức năng nào cũng sẵn sàng cho agentic transformation. Vai trò chiến lược quá phi cấu trúc. Công việc sáng tạo quá mơ hồ. Nhưng shared services nằm ở vị trí ngọt ngào vì ba lý do.

Khối lượng lớn với mẫu hình lặp lại. Tài chính xử lý hàng nghìn hóa đơn. Nhân sự tiếp nhận hàng trăm câu hỏi nhân viên mỗi ngày. IT reset mật khẩu ở quy mô lớn. Khối lượng này mang lại hai lợi thế: đủ dữ liệu lịch sử để hiểu mẫu hình và ngoại lệ, và đủ sự lặp lại để đầu tư vào agentic workflows có hiệu quả kinh tế.

Đủ cấu trúc để điều phối. Hầu hết quy trình shared services không đơn giản, nhưng có thể phân rã thành các bước: đọc yêu cầu, phân loại ý định, kéo dữ liệu từ hệ thống, kiểm tra chính sách, xác định hướng xử lý, chuẩn bị hành động, giải quyết hoặc chuyển tiếp. Điều này khác biệt cơ bản với công việc phụ thuộc nhiều vào bối cảnh xã hội, đàm phán, hay phán đoán chiến lược.

Dữ liệu vận hành đã tồn tại. ERP, CRM, HRIS, ITSM, knowledge base, SOP — nền tảng đã có sẵn, dù rải rác. Tài chính có hóa đơn, đơn đặt hàng, biên nhận hàng, dữ liệu nhà cung cấp. Nhân sự có hồ sơ nhân viên, bài viết chính sách, lịch sử case. IT có ticket, CMDB, runbook, telemetry.

Nhưng điểm tinh tế: shared services không phải điểm khởi đầu tốt vì dễ tự động hóa. Chúng là điểm khởi đầu tốt vì đủ giàu để tái thiết kế. Nếu mục tiêu duy nhất là giảm nhân sự, bạn sẽ chọn use case hẹp nhất, an toàn nhất và dừng ở tự động hóa một phần. Bạn có hiệu quả cục bộ, nhưng không thay đổi mô hình dịch vụ.

Từ quản lý ticket đến điều phối kết quả

Sự thay đổi sâu nhất trong agentic shared services là chuyển từ quản lý hàng đợi sang điều phối kết quả. Trong mô hình cũ, agent nhận ticket, đọc nó, tìm kiếm ba hệ thống, kiểm tra chính sách, quyết định giải quyết hay chuyển tiếp. Phần lớn thời gian dành cho công việc hành chính và săn tìm ngữ cảnh, không phải phán đoán giá trị cao.

Trong mô hình agentic, agent xử lý các bước đầu. Với case rõ ràng, rủi ro thấp-trung bình, agent có thể đọc yêu cầu đến, phân loại, kéo ngữ cảnh từ knowledge base và hệ thống giao dịch, kiểm tra trạng thái và quyền hạn, chuẩn bị phản hồi hoặc hành động, và trong nhiều trường hợp thực thi giải quyết trực tiếp.

Hãy xem IT support. Với reset mật khẩu, cấp quyền ứng dụng tiêu chuẩn, hay kiểm tra trạng thái incident thông thường, agent có thể xác minh danh tính và ngữ cảnh, gọi công cụ phù hợp, và đóng case mà không cần chờ analyst. Trong nhân sự, với câu hỏi về số ngày phép, trạng thái onboarding, hay tài liệu chính sách, agent có thể kéo dữ liệu cá nhân từ HRIS và knowledge base để trả lời. Nếu cần hành động hành chính và nằm trong giới hạn ủy quyền, agent có thể thực thi.

Công việc thường nhật càng được agent hấp thụ, càng rõ con người tạo giá trị ở đâu: ngoại lệ không khớp mẫu hình, xung đột chính sách, tình huống nhạy cảm với stakeholder, đàm phán vendor hoặc khách hàng, quyết định tác động vật chất, và cải tiến quy trình liên tục. Vai trò của đội shared services chuyển từ xử lý ticket sang giải quyết ngoại lệ, diễn giải chính sách, quản lý chất lượng dịch vụ, và huấn luyện hệ thống qua phản hồi vận hành.

Trong mô hình được thiết kế tốt, service desk không còn đồng nghĩa với inbox con người. Nó trở thành lớp điều phối quyết định yêu cầu nào có thể giải quyết tự động, yêu cầu nào cần phê duyệt, yêu cầu nào phải đến người ngay lập tức, và cách fallback khi agent thất bại. Nếu bạn chỉ thêm agent trước service desk cũ mà không tái thiết kế luồng, bạn có chatbot cộng với backlog cũ. Giá trị chuyển đổi là tối thiểu.

Service Catalog mới cho kiểm soát vận hành

Khi shared services chuyển sang mô hình đội người-agent, bạn không thể quản lý vận hành với định nghĩa dịch vụ cũ. Bạn cần service catalog mới phân biệt ít nhất ba chế độ.

Dịch vụ do con người xử lý vẫn chạy chủ yếu bằng người vì phán đoán, độ nhạy cảm, hoặc rủi ro cao. Ví dụ: tranh chấp khách hàng giá trị lớn, quyết định nhân sự ảnh hưởng trạng thái việc làm, xử lý kế toán trọng yếu, thay đổi production IT rủi ro cao.

Dịch vụ có agent hỗ trợ cho phép agent giúp đọc ngữ cảnh, chuẩn bị bản nháp, hoặc đưa ra đề xuất, nhưng con người vẫn là người ra quyết định chính. Ví dụ: soạn thảo bình luận cho báo cáo tài chính, đề xuất hướng sourcing, soạn phản hồi khiếu nại khách hàng, phân loại incident cho kỹ sư.

Dịch vụ do agent thực thi cho phép agent hoàn thành dịch vụ trực tiếp trong ranh giới chính sách rõ ràng, với fallback về người khi cần. Ví dụ: reset mật khẩu, tra cứu trạng thái đơn hàng, cập nhật dữ liệu hành chính nhất định, định tuyến yêu cầu mua sắm tiêu chuẩn, truy vấn chính sách không mơ hồ.

Mỗi loại cần kiểm soát khác nhau. Mỗi dịch vụ agentic cần SLA phù hợp — không chỉ thời gian phản hồi, mà thời gian giải quyết. Quy tắc escalation phải rõ ràng: khi nào agent dừng, khi nào case lên supervisor, khi nào bắt buộc phê duyệt. Audit trail phải cho thấy yêu cầu đến từ đâu, ngữ cảnh nào được dùng, công cụ nào được gọi, hành động nào được thực hiện, và khi nào con người tiếp quản. Không có audit trail, agentic shared services trở nên không thể quản trị được cho kiểm toán nội bộ, tuân thủ, và chủ sở hữu quy trình.

Một trong những sai lầm thiết kế phổ biến nhất là coi fallback về người là điều cần tránh bằng mọi giá. Trong shared services, fallback là kiểm soát quan trọng. Nó cần khi dữ liệu không đủ, chính sách xung đột, độ tin cậy thấp, rủi ro quá cao, hoặc người dùng từ chối kết quả của agent. Một thiết kế lành mạnh không ép agent giải quyết mọi thứ. Nó biết khi nào dừng an toàn. Nếu fallback không được thiết kế tốt, hai điều xảy ra: agent trở nên quá hung hăng và mắc sai lầm đắt giá, hoặc quá bảo thủ và mọi case vẫn đổ lên người, giết chết giá trị kinh doanh.

Đo lường điều thực sự quan trọng

Agentic shared services thường được bán trên lợi ích năng suất. Điều đó không sai, nhưng quá hẹp. Giá trị quan trọng hơn là sự thay đổi chất lượng dịch vụ. Các metric hữu ích nhất bao gồm:

• Tỷ lệ giải quyết ngay lần đầu (first-contact resolution rate)
• Tỷ lệ xử lý không chạm (touchless processing rate)
• Thời gian chu kỳ từ yêu cầu đến hoàn thành
• Xu hướng backlog ngoại lệ
• Chi phí mỗi case

Những metric này cho bạn biết mô hình dịch vụ có thực sự thay đổi hay không, không chỉ là agent có được sử dụng hay không.

Hiệu quả mà không có chất lượng sẽ phá hủy niềm tin. Vì vậy, agentic shared services cũng phải được đo lường trên:

• Tỷ lệ lỗi
• Phát hiện tuân thủ
• Sự hài lòng của người dùng
• Chỉ số tin cậy (tỷ lệ chấp nhận, tỷ lệ ghi đè, hoặc phản hồi người dùng về đề xuất của agent)

Vấn đề không chỉ là đo lường bao nhiêu được tự động hóa, mà là liệu mọi người có tin tưởng kết quả và những kết quả đó có chính xác hay không.

Ví dụ cụ thể: Tài chính Shared Services

Tài chính shared services là một blueprint hữu ích. Mô hình agent hỗ trợ có thể phân loại ngoại lệ hóa đơn, thu thập bằng chứng từ ERP, soạn thảo giải thích chênh lệch, và tóm tắt các vấn đề tồn đọng. Con người vẫn quyết định, nhưng thời gian săn tìm dữ liệu giảm.

Dịch vụ do agent thực thi có thể xử lý câu hỏi trạng thái hóa đơn, định tuyến truy vấn nhà cung cấp, và xử lý case rủi ro thấp với quy tắc rõ ràng. Dịch vụ do con người xử lý vẫn dành cho phán đoán kế toán trọng yếu, nghi ngờ gian lận, tranh chấp nhà cung cấp, và phê duyệt thanh toán giá trị lớn.

Vấn đề không phải là "tài chính không có người". Đó là phân bổ công việc rõ ràng hơn: agent xử lý điều phối thường nhật, con người xử lý phán đoán, và dịch vụ được đo bằng chất lượng giải quyết thay vì khối lượng ticket.

Áp dụng vào hệ thống thật

Nếu bạn đang dẫn dắt platform team, operation shared services, hoặc nhóm kiến trúc doanh nghiệp, đây là những bước cụ thể:

1. Kiểm toán service catalog — phân loại mỗi dịch vụ thành do người xử lý, agent hỗ trợ, hoặc agent thực thi. Bắt đầu với dịch vụ khối lượng lớn, rủi ro thấp.
2. Ánh xạ phụ thuộc dữ liệu — xác định hệ thống, API, và knowledge base nào mỗi workflow agentic cần. Tích hợp yếu sẽ làm gãy agent của bạn.
3. Thiết kế fallback rõ ràng — định nghĩa điều kiện agent chuyển tiếp lên người. Đừng coi fallback là thất bại.
4. Instrument mọi thứ — thu thập audit trail, tỷ lệ giải quyết, tỷ lệ ghi đè, và phản hồi người dùng từ ngày đầu. Bạn không thể cải thiện điều bạn không đo lường.
5. Chuyển metric — ngừng thưởng cho khối lượng ticket. Bắt đầu thưởng cho giải quyết ngay lần đầu, xử lý không chạm, và giảm ngoại lệ.

Về mặt kỹ thuật, hãy bắt đầu với một use case cụ thể như "reset mật khẩu" hoặc "tra cứu số ngày phép". Xây dựng agent với kiến trúc đơn giản: một orchestrator nhận request, gọi classification model (có thể dùng LLM nhỏ hoặc mô hình phân loại truyền thống), kết nối qua API đến hệ thống nguồn (HRIS, ITSM), và thực thi hành động qua webhook hoặc script tự động. Fallback là một API call đến hệ thống ticket để tạo case cho human. Audit trail ghi vào database riêng hoặc log centralized.

Khi nào Shared Services chưa sẵn sàng

Shared services chưa sẵn sàng khi quy trình không được tài liệu hóa, knowledge base mâu thuẫn, tích hợp yếu, quyền sở hữu dịch vụ không rõ ràng, hoặc metric vẫn thưởng cho khối lượng ticket thay vì kết quả. Trong môi trường đó, agent trở thành lớp mới trên nền hỗn loạn cũ.

Quyết định bạn cần đưa ra ngay bây giờ

Quyết định lãnh đạo không phải là m