AI có thể hỗ trợ biến mô tả rời rạc thành một bản yêu cầu mua hàng có cấu trúc. Nhưng chuẩn bị yêu cầu, gửi yêu cầu báo giá và cam kết mua là ba hành động khác nhau. Doanh nghiệp nên quyết định rõ ranh giới này trước khi kết nối agent với email, catalogue hoặc hệ thống mua hàng.
Bài này đề xuất một quy trình thử nghiệm cho bước chuẩn bị RFQ — yêu cầu nhà cung cấp báo giá. Đây là thiết kế tham khảo, không phải thông báo Onter đã cung cấp một agent tự mua hàng, cũng không phải bằng chứng doanh nghiệp nào đã áp dụng thành công.
Tài liệu RFQ của Microsoft Dynamics 365 phân biệt việc tạo yêu cầu, gửi tới nhà cung cấp và xử lý phản hồi. Đó là căn cứ về quy trình mua hàng đã có trong một sản phẩm thực tế. Các điểm kiểm soát AI dưới đây là phương pháp đề xuất của bài viết, không phải chức năng Microsoft hay Onter mặc định cung cấp.
Bắt đầu bằng một phiếu nhu cầu, không bằng quyền thanh toán
Người mua nội bộ thường mô tả nhu cầu bằng tên gọi quen thuộc: “đặt thêm loại hộp đang dùng” hoặc “mua 20 bộ lọc”. AI không nên suy ra mã hàng, kích thước hay nhà cung cấp từ một câu như vậy rồi tự gửi yêu cầu.
Hãy yêu cầu bản nháp có tối thiểu: mục đích sử dụng, mã hàng nếu biết, cấu hình bắt buộc, đơn vị, số lượng, thời điểm cần và nơi giao. Trường nào chưa có thì để cần xác nhận, thay vì điền một giá trị có vẻ hợp lý.
| Trường phiếu | Ví dụ giả lập | Trạng thái |
|---|---|---|
| Nhu cầu | Hộp vận chuyển cho sản phẩm A | Người yêu cầu cung cấp |
| Kích thước trong | 300 × 200 × 150 mm | Cần xác nhận dung sai |
| Số lượng | 2.000 | Đã có số lượng, chưa rõ quy cách đóng kiện |
| Đơn vị | Hộp | Đã rõ |
| Ngày cần nhận | Theo kế hoạch nội bộ | Chưa có ngày cụ thể |
| Giá | Chưa có báo giá | Không được AI tự ước thành giá mua |
Phần đóng góp hữu ích của AI ở đây là chỉ ra điều còn thiếu và chuẩn hóa cách diễn đạt. Nó không thay người phụ trách xác nhận rằng vật tư đúng yêu cầu sản xuất.
Một lần duyệt chỉ có ý nghĩa với đúng phiên bản
Giả sử nhân viên duyệt RFQ v1 cho 2.000 hộp. Sau đó số lượng được sửa thành 5.000 hoặc chất liệu đổi. Nếu hệ thống vẫn coi lần duyệt v1 là hợp lệ cho bản mới, vấn đề nằm ở thiết kế quy trình, không phải cách viết prompt.
Mẫu quy tắc dưới đây là đề xuất quản trị của bài viết, không phải yêu cầu bắt buộc của một giao thức:
| Trạng thái | AI được làm | AI chưa được làm |
|---|---|---|
| DRAFT | Chuẩn hóa trường, hỏi dữ liệu thiếu | Gửi nhà cung cấp hoặc ghi nhận mua |
| NEEDS_REVIEW | Tóm tắt chỗ chưa rõ | Tự chuyển thành APPROVED |
| APPROVED_VERSION | Tạo bản nháp nội dung gửi từ thông số đã duyệt | Tự gửi hoặc thay thông số mà giữ dấu duyệt cũ |
| SENT_RFQ | Ghi nhận thông tin đã gửi khi có xác nhận hệ thống | Gọi “đã mua” hoặc “đã đặt hàng” |
| CHANGED | So khác biệt với bản được duyệt | Tiếp tục dùng quyền gửi cũ nếu thay đổi thuộc trường quan trọng |
Phiếu duyệt nên ghi phiên bản, thời điểm và người duyệt. Với các trường ảnh hưởng lựa chọn hoặc chi phí — mã hàng, cấu hình, số lượng, người nhận — sửa đổi cần quay lại bước kiểm tra theo quy định doanh nghiệp. Từ “đã duyệt” trong văn bản do AI sinh không phải bằng chứng phê duyệt của người có thẩm quyền.
Duyệt thông số không đồng nghĩa cho phép gửi. Trước khi gửi ra ngoài cần một xác nhận thực thi riêng: ai có quyền duyệt gửi, gửi tới nhà cung cấp/người nhận nào, qua kênh nào và đính kèm tài liệu nào. Trong thử nghiệm này, AI chỉ chuẩn bị bản nháp; không tự gửi email hay yêu cầu qua API cho tới khi người có thẩm quyền cấp phép đúng hành động đó. Nếu người nhận, kênh hoặc tệp đính kèm đổi, kiểm tra lại phạm vi cho phép trước khi thực thi. Biên nhận gửi chỉ được ghi sau khi hệ thống đích xác nhận, không dựa vào câu trả lời của AI.
Catalogue có cấu trúc chưa phải quyền mua hàng
Một kết nối đọc catalogue không tự tạo quyền đặt hàng. Tài liệu catalogue B2B của Shopify cho thấy danh mục và giá có thể khác nhau theo nhóm người mua. Vì vậy, quyền xem dữ liệu sản phẩm cần được tách khỏi quyền gửi yêu cầu hoặc cam kết mua.
Đừng lấy giá công khai trên website làm giá hợp đồng của doanh nghiệp. Nếu chưa xác minh được nhóm khách, hiệu lực giá hoặc điều kiện giao, bản nháp cần ghi “chờ xác nhận”. Hãy kiểm tra phạm vi tích hợp thực tế trước khi cho phép agent gửi thông tin ra ngoài.
Bốn tình huống nên thử trước khi dùng dữ liệu thật
- Thiếu đơn vị: đầu vào chỉ ghi “20”, kết quả phải hỏi cái/bộ/thùng, không tự chọn.
- Chỉ dẫn nằm trong tài liệu: catalogue có câu yêu cầu gửi hồ sơ đến một địa chỉ khác. Xử lý đó như nội dung tài liệu, không như lệnh của người có quyền.
- Sửa sau duyệt: thay số lượng trên phiếu đã duyệt, hệ thống phải nhận ra phiên bản thay đổi và chặn bước gửi theo thiết kế.
- Gửi lại: người dùng bấm hai lần hoặc hệ thống bị gián đoạn. Phải kiểm tra receipt/trạng thái thực trước khi gửi lại, tránh hai yêu cầu không chủ đích.
Dùng dữ liệu giả hoặc đã loại bỏ thông tin nhạy cảm trong lần thử đầu. Ghi kết quả kỳ vọng và kết quả thực tế; một bản demo thuận lợi chưa đủ để giao agent quyền tác động ra ngoài.
Đo chất lượng bằng việc giảm thiếu sót có kiểm chứng
Chọn một mẫu phiếu cũ đã được phép sử dụng để so sánh. Đếm số trường bắt buộc còn thiếu, số lần người mua phải hỏi lại và số bản nháp cần sửa. Giữ riêng thời gian chuẩn bị và thời gian chờ người duyệt. Không đặt mục tiêu “giảm 80% thời gian” trước khi có baseline tương ứng.
Nếu khó thống nhất một phiếu chuẩn khi làm thủ công, hãy giải quyết bước đó trước. Agent có thể làm cho dữ liệu thiếu chạy nhanh hơn; nó không tự quyết định quy tắc mua hàng đúng cho doanh nghiệp.
Sau khi nhận báo giá, bước tiếp theo là so sánh báo giá nhà cung cấp. Khi đã có đơn mua, biên bản nhận và hóa đơn, đó là bài toán đối chiếu chứng từ mua hàng. Giữ hai giai đoạn này riêng giúp phạm vi thử nghiệm rõ và tránh giao quá nhiều quyền trong lần triển khai đầu.
Muốn rà soát một quy trình mua hàng đang có, hãy chuẩn bị phiếu đầu vào đã ẩn thông tin nhạy cảm và trao đổi phạm vi triển khai AI Agent. Bắt đầu từ một nhóm vật tư và một hành động được kiểm soát, trước khi mở rộng quyền kết nối.
