AI Agent hỗ trợ tạo yêu cầu mua hàng nội bộ như thế nào?

Ở nhiều doanh nghiệp, một yêu cầu mua hàng nội bộ bắt đầu bằng tin nhắn kiểu “phòng mình cần thêm hai màn hình”. Sau đó là vài vòng hỏi lại: mua loại nào, cho ai dùng, tính vào ngân sách phòng nào, đã có báo giá chưa. Phiếu tới tay bộ phận mua hàng thường vẫn thiếu thông tin, và người duyệt phải đoán lý do.

AI Agent có thể đảm nhận phần hỏi lại và điền phiếu: trò chuyện với người yêu cầu, đối chiếu danh mục, kiểm tra ngân sách còn lại và tạo phiếu nháp đúng mẫu. Phần quyết định mua, chọn nhà cung cấp và phê duyệt vẫn thuộc con người.

Bài viết mô tả các thành phần cần thiết kế, quy trình triển khai, những rủi ro kiểm soát nội bộ cần lưu ý và cách chia việc giữa người yêu cầu, mua hàng và kế toán.

1. Bản chất của AI tạo yêu cầu mua hàng

Agent tạo yêu cầu mua hàng làm ba việc: hiểu nhu cầu viết bằng lời, ánh xạ nhu cầu đó sang dữ liệu có cấu trúc của hệ thống mua hàng, rồi đưa phiếu vào đúng luồng duyệt. Phần khó thường không phải hiểu câu chữ mà là ánh xạ. “Laptop cho nhân viên mới” phải trở thành một mã hàng cụ thể trong danh mục, một trung tâm chi phí và một người duyệt.

Ba mức việc tách khá rõ trong mua hàng. Mức hỏi đáp là giải thích quy định mua sắm: mặt hàng nào phải qua bộ phận mua hàng, khi nào cần nhiều báo giá. Mức tra cứu là đọc danh mục, ngân sách còn lại và trạng thái các phiếu cũ từ ERP hoặc phần mềm mua hàng. Mức ghi là tạo phiếu; ở mức này agent chỉ tạo phiếu nháp dưới tên người yêu cầu, không gửi duyệt thay họ và không tạo đơn với nhà cung cấp.

2. Các yếu tố cần thiết kế

1. Thu nhu cầu và lý do

Agent hỏi đủ những gì người duyệt cần biết: mua gì, số lượng, dùng cho việc gì, cần trước ngày nào. Lý do mua nên giữ nguyên lời của người yêu cầu, không để AI viết lại cho “thuyết phục hơn”, vì đây là căn cứ để quản lý quyết định. Nếu người yêu cầu không nêu được mục đích, phiếu chưa đủ điều kiện tạo.

2. Chuẩn hóa mã hàng

Người dùng gọi hàng theo thói quen, còn hệ thống cần mã. Agent tìm trong danh mục đã duyệt và đưa ra vài lựa chọn gần nhất để người yêu cầu chọn, thay vì tự chốt một mã. Hàng ngoài danh mục được đánh dấu là yêu cầu mới và chuyển mua hàng xem xét, không tạo mã tạm.

3. Kiểm tra ngân sách

Agent đọc ngân sách còn lại của bộ phận từ phần mềm kế toán hoặc ERP ngay lúc tạo phiếu. Kết quả chỉ là thông tin cho người duyệt: còn đủ, sắp hết hay vượt. Agent không được tự điều chuyển ngân sách hay gợi ý lấy tiền từ khoản mục khác.

4. Chọn trung tâm chi phí

Trung tâm chi phí quyết định khoản mua được ghi nhận vào đâu, nên chọn sai ở đây kéo theo báo cáo sai. Agent có thể gợi ý theo phòng ban của người yêu cầu, nhưng với hàng dùng chung hoặc mua cho dự án, người yêu cầu phải tự chọn và xác nhận. Danh sách hợp lệ lấy từ kế toán, agent không tự đặt tên mới.

5. Đính kèm báo giá

Nếu quy định yêu cầu báo giá từ một mức giá trị nào đó, agent nhắc người yêu cầu đính kèm và kiểm tra file đọc được, đúng mặt hàng. Agent có thể trích tên nhà cung cấp, đơn giá và thời hạn hiệu lực để người duyệt xem nhanh. Việc so sánh nhiều báo giá là một bước riêng, xem bài AI so sánh báo giá nhà cung cấp.

6. Định tuyến phê duyệt

Người duyệt được xác định theo ma trận phê duyệt đã có: giá trị phiếu, loại hàng, trung tâm chi phí. Ma trận này nằm trong hệ thống; agent chỉ đọc và áp dụng, không suy luận xem ai “nên” duyệt. Khi người duyệt vắng mặt, luồng ủy quyền cũng đi theo cấu hình sẵn có.

7. Tạo requisition nháp

Phiếu yêu cầu (requisition) được tạo ở trạng thái nháp, gắn mã giao dịch để không sinh phiếu trùng khi người dùng gửi lại. Người yêu cầu đọc bản tóm tắt, sửa nếu cần rồi tự bấm gửi. Nhờ vậy, trách nhiệm về nội dung phiếu vẫn thuộc người yêu cầu.

8. Theo dõi trạng thái

Sau khi gửi, câu hỏi phổ biến nhất là phiếu đang ở đâu. Agent đọc trạng thái từ hệ thống và trả lời: đang chờ ai duyệt, bị trả lại vì lý do gì, đã chuyển thành đơn mua chưa. Agent không tự nhắc người duyệt liên tục thay người yêu cầu nếu quy trình chưa cho phép.

3. Quy trình triển khai thực tế

Bước 1: Xác định phạm vi và kết quả cần đo

Chọn một nhóm hàng phổ biến, nơi phiếu hay bị trả lại vì thiếu thông tin. Chỉ số ban đầu có thể là tỷ lệ phiếu bị trả lại và thời gian từ lúc có nhu cầu tới lúc phiếu đủ thông tin. Trưởng bộ phận mua hàng xác nhận phạm vi và các nhóm hàng chưa đưa vào.

Bước 2: Chuẩn hóa dữ liệu cùng quyền truy cập

Rà danh mục hàng, danh sách trung tâm chi phí và ma trận phê duyệt để chắc chúng phản ánh đúng thực tế hiện nay. Agent đọc ngân sách bằng tài khoản dịch vụ chỉ có quyền xem, và chỉ thấy ngân sách của bộ phận người đang hỏi. Kế toán xác nhận nguồn số liệu ngân sách được dùng.

Bước 3: Thiết kế tích hợp ngoại lệ và phê duyệt

Liệt kê các ngoại lệ: hàng ngoài danh mục, yêu cầu khẩn, vượt ngân sách, người yêu cầu đặt thay cho phòng khác. Mỗi ngoại lệ có đường đi riêng, thường là chuyển mua hàng hoặc quản lý kèm lý do. Tài liệu thiết kế ghi rõ agent gọi được API nào, với quyền gì và dừng ở đâu.

Bước 4: Kiểm thử vận hành rồi cải thiện theo log

Cho một nhóm người dùng tạo phiếu thật trong phạm vi đã chọn, bộ phận mua hàng vẫn kiểm tra như bình thường. Ghi lại phiếu nào bị sửa mã hàng, sửa trung tâm chi phí hoặc bị trả lại, và câu nào agent không hiểu. Các lỗi này trở thành ca thử hồi quy trước khi mở cho toàn công ty.

4. Ví dụ giả định

Nhân viên yêu cầu mua thiết bị qua chat. AI hỏi số lượng, mục đích và trung tâm chi phí, kiểm tra danh mục rồi tạo phiếu nháp. Yêu cầu vượt ngân sách được chuyển quản lý, không tự tách nhỏ để né hạn mức.

Ca kiểm thử quan trọng nhất rút ra từ ví dụ này là yêu cầu sát ngưỡng: người dùng đề nghị chia một khoản thành hai phiếu nhỏ, hoặc tạo liên tiếp nhiều phiếu cùng mặt hàng trong thời gian ngắn. Kết quả mong đợi là agent không làm theo, giải thích quy định và gắn cờ cho mua hàng. Bộ ca thử nên có thêm mặt hàng ngoài danh mục, trung tâm chi phí không thuộc phòng người yêu cầu và trường hợp không đọc được ngân sách do hệ thống lỗi.

5. Rủi ro và giới hạn

• Không cho AI lựa chọn nhà cung cấp cuối cùng
• Giữ phân tách nhiệm vụ
• Chống chia nhỏ yêu cầu
• Lưu bằng chứng duyệt

Mua hàng là khâu nhạy cảm với gian lận nội bộ, nên agent không được làm mờ ranh giới giữa người đề nghị, người duyệt và người mua. Tài khoản của agent không có quyền duyệt phiếu, không sửa ma trận phê duyệt và không tạo đơn với nhà cung cấp. Mỗi phiếu lưu lại hội thoại gốc, người xác nhận và thời điểm để kiểm soát nội bộ truy lại khi cần. Khi có dấu hiệu chia nhỏ yêu cầu, hệ thống cảnh báo thay vì âm thầm cho qua.

6. Phân chia trách nhiệm vận hành

Người yêu cầu chịu trách nhiệm về nhu cầu và lý do trên phiếu, kể cả khi agent giúp điền. Bộ phận mua hàng sở hữu danh mục, quy định về báo giá và việc chọn nhà cung cấp. Kế toán quản lý ngân sách, trung tâm chi phí và các ngưỡng giá trị trong ma trận phê duyệt. Đội kỹ thuật lo kết nối ERP, quyền của tài khoản dịch vụ và cảnh báo khi tích hợp lỗi.

Khi ma trận phê duyệt hoặc danh mục thay đổi, cần chạy lại các ca thử liên quan trước khi áp dụng, vì agent làm theo cấu hình mới ngay lập tức. Nếu phát hiện phiếu bị chuyển sai người duyệt, bộ phận mua hàng có quyền tạm tắt chức năng tạo phiếu và quay lại biểu mẫu cũ cho tới khi sửa xong.

7. Chỉ số nên theo dõi

• Tỷ lệ phiếu đủ thông tin theo tiêu chí đã duyệt
• Tỷ lệ yêu cầu ngoại lệ được chuyển đúng người
• Lỗi tích hợp ERP, độ trễ và số phiếu phải sửa
• Chi phí cùng tác động tới thời gian xử lý mua hàng

Số phiếu được tạo qua agent không cho biết quy trình tốt lên. Nên xem tỷ lệ phiếu bị trả lại vì thiếu thông tin, số lần mua hàng phải sửa mã hàng hoặc trung tâm chi phí, và số cảnh báo chia nhỏ yêu cầu được xác nhận là đúng. Tách theo nhóm hàng để biết chỗ nào cần sửa danh mục, chỗ nào cần sửa cách agent hỏi.

8. Checklist trước khi vận hành

• Danh mục, ngân sách và chủ sở hữu dữ liệu đã xác nhận
• Quyền đọc ghi đã thử với nhiều vai trò
• Có phương án khi hệ thống lỗi hoặc thiếu dữ liệu
• Có log, phê duyệt và cơ chế chống thao tác trùng
• Có bộ kiểm thử hồi quy và người vận hành

9. Câu hỏi thường gặp

Có thể dùng AI tạo yêu cầu mua hàng ngay không? Có thể khi danh mục hàng, danh sách trung tâm chi phí và ma trận phê duyệt đã nằm trong hệ thống và được cập nhật đều. Nếu việc duyệt còn đi qua email và bảng tính rời rạc, nên chuẩn hóa luồng đó trước khi thêm AI.

Nên bắt đầu tự động tạo phiếu mua hàng từ đâu? Bắt đầu với nhóm hàng mua thường xuyên, giá trị vừa phải và đã có trong danh mục, như thiết bị văn phòng hoặc vật tư tiêu hao. Nhóm hàng đặc thù hoặc giá trị lớn nên để sau, khi phiếu nháp đã ít phải sửa.

Khi nào yêu cầu mua hàng cần người duyệt? Mọi phiếu đều đi qua người duyệt theo ma trận phê duyệt hiện hành; agent không rút ngắn bước này. Yêu cầu vượt ngân sách, hàng ngoài danh mục hoặc có dấu hiệu chia nhỏ còn phải được mua hàng hoặc quản lý xem riêng.

AI có được chọn nhà cung cấp không? Không nên. AI có thể trích thông tin từ báo giá để người duyệt xem nhanh, nhưng chọn nhà cung cấp là quyết định của bộ phận mua hàng theo quy định nội bộ.

Kết luận

AI tạo yêu cầu mua hàng hữu ích nhất ở khâu hỏi lại và điền phiếu, nơi đang tốn thời gian của cả người yêu cầu lẫn bộ phận mua hàng. Hãy giữ nguyên phân tách nhiệm vụ, để agent chỉ tạo phiếu nháp và đọc cấu hình duyệt có sẵn, rồi mở rộng theo từng nhóm hàng. Nếu nhu cầu mua xuất phát từ kho, xem thêm cách thiết kế AI cảnh báo tồn kho.

Trao đổi với Naventic để khảo sát quy trình mua hàng nội bộ của doanh nghiệp. Đọc thêm: AI Procurement Agent.