Cách viết yêu cầu RFP cho dự án AI Agent doanh nghiệp

Khi đã quyết định làm AI Agent và muốn hỏi ý kiến vài đơn vị, nhiều doanh nghiệp chỉ gửi một đoạn mô tả ngắn kiểu “cần chatbot trả lời khách và kết nối CRM”. Kết quả là mỗi bên hiểu một kiểu: đơn vị này báo giá cho một bot hỏi đáp đơn giản, đơn vị kia báo cho cả hệ thống tích hợp nhiều kênh. Các đề xuất chênh nhau rất xa và không có cách nào so sánh công bằng.

RFP, hay tài liệu đề nghị đề xuất, giải quyết đúng vấn đề đó. Nó đặt mọi nhà cung cấp lên cùng một phạm vi, cùng một bộ dữ liệu mẫu và cùng một thang chấm điểm. Bài viết này trình bày các phần cần có trong một RFP cho dự án AI Agent, cách viết từng phần sao cho nhà cung cấp trả lời được cụ thể, và những lỗi làm RFP mất tác dụng.

Nếu doanh nghiệp chưa rà soát mức sẵn sàng nội bộ, nên làm bước đó trước theo checklist chuẩn bị trước khi bắt đầu dự án AI Agent. Phần lớn nội dung RFP được lấy trực tiếp từ kết quả của checklist đó.

1. Bản chất của RFP AI Agent

Một RFP cho AI Agent khác RFP phần mềm thông thường ở chỗ kết quả không hoàn toàn tất định. Cùng một câu hỏi, agent có thể trả lời bằng nhiều cách diễn đạt; cái cần yêu cầu không phải là câu chữ cố định mà là hành vi: trả lời dựa trên nguồn nào, khi nào phải từ chối, khi nào chuyển người. Vì vậy RFP nên mô tả tình huống và kết quả chấp nhận được, thay vì liệt kê tính năng.

RFP cũng nên nói rõ agent cần làm tới mức nào. Chỉ hỏi đáp trên tài liệu có sẵn là một phạm vi. Tra cứu dữ liệu thời gian thực trong hệ thống đơn hàng hay tồn kho là phạm vi khác, cần quyền đọc và xử lý khi hệ thống chậm. Ghi vào CRM, tạo phiếu hoặc gửi thông tin ra ngoài lại đòi hỏi phê duyệt, chống lặp và nhật ký. Tách ba mức này ngay trong RFP giúp nhà cung cấp báo giá đúng và giúp doanh nghiệp chọn làm mức nào trước.

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

1. Phạm vi nghiệp vụ

Mô tả một đến ba luồng cụ thể: ai dùng, qua kênh nào, yêu cầu điển hình là gì và kết quả mong đợi ra sao. Ghi cả phần nằm ngoài phạm vi, ví dụ “agent không tư vấn khiếu nại pháp lý” hay “không xử lý hoàn tiền”. Phạm vi viết bằng từ chung chung như “hỗ trợ khách hàng toàn diện” là nguồn gốc của các báo giá không so sánh được.

2. Dữ liệu mẫu

Đính kèm mẫu tài liệu, bảng giá, câu hỏi khách thật đã che thông tin, và vài bản ghi từ hệ thống. Dữ liệu mẫu nên giữ nguyên các vấn đề thực tế như file trùng lặp, trường bỏ trống, cách viết tắt nội bộ. Nhà cung cấp nhìn dữ liệu thật sẽ ước lượng công chuẩn bị dữ liệu sát hơn nhiều so với đọc mô tả.

3. Hệ thống tích hợp

Liệt kê từng hệ thống cần kết nối, phiên bản hoặc nhà cung cấp, agent cần đọc hay ghi, và hiện trạng API. Nếu không chắc hệ thống có API, hãy ghi đúng như vậy và yêu cầu nhà cung cấp nêu phương án thay thế. Các kiểu kết nối thường gặp được mô tả ở bài tích hợp AI Agent với CRM, ERP và API.

4. Yêu cầu bảo mật

Nêu loại dữ liệu agent sẽ chạm, yêu cầu về nơi lưu trữ, phân quyền theo vai trò, nhật ký truy cập và việc dữ liệu có được dùng để huấn luyện mô hình hay không. Yêu cầu nhà cung cấp mô tả cách họ đáp ứng từng điểm thay vì chỉ trả lời “có”. Câu trả lời mơ hồ ở phần này là dấu hiệu cần hỏi thêm trước khi chấm.

5. SLA

Mô tả mức độ quan trọng của từng luồng và yêu cầu nhà cung cấp đề xuất cam kết cụ thể: thời gian hỗ trợ, cách phân loại mức sự cố, thời gian phản hồi theo từng mức, cách thông báo khi có gián đoạn. Doanh nghiệp không cần tự đặt con số nếu chưa có kinh nghiệm, nhưng phải yêu cầu các bên đề xuất theo cùng cấu trúc để so sánh được.

6. Tiêu chí đánh giá

Công bố trước các nhóm tiêu chí và trọng số, ví dụ hiểu nghiệp vụ, phương án kỹ thuật, bảo mật, kế hoạch vận hành, chi phí. Kèm theo là bộ tình huống thử mà nhà cung cấp phải trình diễn trên dữ liệu mẫu. Chấm theo bộ tình huống chung công bằng hơn nhiều so với chấm theo bản demo mỗi bên tự chọn.

7. Bàn giao sở hữu

Nêu rõ doanh nghiệp cần nhận gì khi dự án kết thúc: tài liệu cấu hình, prompt, kho kiến thức, quyền quản trị, mã nguồn nếu có, và dữ liệu hội thoại. Hỏi nhà cung cấp phần nào thuộc sở hữu của doanh nghiệp, phần nào là nền tảng của họ và điều gì xảy ra nếu ngừng hợp tác.

8. Chi phí vận hành

Yêu cầu tách chi phí một lần và chi phí định kỳ, trong đó chi phí định kỳ ghi rõ các thành phần như lượt gọi mô hình, hạ tầng, hỗ trợ và cập nhật nội dung. Hỏi thêm chi phí sẽ thay đổi thế nào khi lượng người dùng tăng. Một đề xuất rẻ ở phần phát triển nhưng không nói gì về vận hành thường tốn hơn về lâu dài. Có thể tham khảo cách ước lượng ở bài chi phí triển khai AI Agent.

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

Nhóm nội bộ chọn các luồng đưa vào RFP và thống nhất kết quả muốn đo. Đầu ra là phần phạm vi nghiệp vụ của RFP kèm danh sách những gì nằm ngoài phạm vi. Người sở hữu quy trình và người giữ ngân sách cùng duyệt trước khi viết các phần còn lại.

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

Chọn và che thông tin nhạy cảm trong bộ dữ liệu mẫu, ghi mô tả từng nguồn và tình trạng quyền truy cập hiện tại. Đầu ra là gói dữ liệu đính kèm RFP và bảng mô tả hệ thống. Bộ phận IT hoặc người phụ trách an toàn thông tin xác nhận gói dữ liệu được phép gửi ra ngoài.

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

Viết các tình huống ngoại lệ mà nhà cung cấp phải trả lời cách xử lý: hệ thống không phản hồi, khách hỏi ngoài phạm vi, yêu cầu vượt quyền, hành động cần người duyệt. Đầu ra là phần câu hỏi kỹ thuật trong RFP. Mỗi câu hỏi nên đòi mô tả cách làm, không chấp nhận câu trả lời có hoặc không.

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

Chuẩn bị bộ tình huống trình diễn và phiếu chấm, gửi kèm RFP để các bên biết trước sẽ bị đánh giá thế nào. Sau vòng trình diễn, ghi lại kết quả từng tình huống, câu hỏi phát sinh và điểm từng tiêu chí. Hội đồng đánh giá ký biên bản trước khi mở phần giá.

4. Ví dụ giả định

RFP nêu rõ ba luồng cần tự động hóa và bộ ca thử, giúp doanh nghiệp so sánh đề xuất trên cùng phạm vi.

Từ ví dụ này có thể thấy giá trị lớn nhất của bộ ca thử nằm ở các tình huống khó, không phải tình huống chuẩn. Nên có ít nhất một câu hỏi mà câu trả lời không có trong dữ liệu mẫu, một yêu cầu vượt quyền, và một trường hợp hai nguồn dữ liệu mâu thuẫn nhau. Bên nào xử lý được bằng cách từ chối hoặc chuyển người có lý do rõ ràng thường đáng tin hơn bên trả lời trơn tru mọi câu.

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

• Không tự động hóa khi dữ liệu hoặc thẩm quyền chưa rõ
• Giới hạn quyền đọc ghi theo nhu cầu tối thiểu
• Giữ người phụ trách cho ngoại lệ và quyết định quan trọng
• Theo dõi log và kiểm thử lại sau mỗi thay đổi

RFP có ba rủi ro phổ biến. Viết quá chi tiết về công nghệ khiến nhà cung cấp chỉ làm đúng thứ được mô tả thay vì đề xuất cách tốt hơn. Viết quá chung khiến các đề xuất không so sánh được. Và gửi dữ liệu thật chưa che thông tin ra ngoài trước khi có thỏa thuận bảo mật. Cũng cần nhớ RFP chỉ là căn cứ lựa chọn; các cam kết về SLA, bàn giao và bảo mật phải được chuyển vào hợp đồng mới có hiệu lực.

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

Người sở hữu quy trình viết phạm vi, tình huống và kết quả mong đợi. Bộ phận IT viết phần hệ thống, tích hợp và yêu cầu kỹ thuật. Bộ phận an toàn thông tin hoặc pháp chế viết yêu cầu bảo mật, quyền sở hữu và điều khoản bàn giao. Bộ phận mua hàng hoặc tài chính lo khung báo giá và quy trình mở thầu.

Nên chỉ định một đầu mối duy nhất nhận câu hỏi từ nhà cung cấp và gửi câu trả lời chung cho tất cả các bên, để không bên nào có thông tin riêng. Khi phạm vi thay đổi giữa chừng, cập nhật RFP thành phiên bản mới, ghi rõ điểm thay đổi và cho các bên thời gian điều chỉnh đề xuất.

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

• Tỷ lệ hoàn thành đúng theo tiêu chí đã duyệt
• Tỷ lệ từ chối đúng và chuyển người phụ trách
• Lỗi tích hợp, độ trễ và số thao tác phải sửa
• Chi phí cùng tác động kinh doanh của quy trình

Các chỉ số này nên được viết ngay trong RFP như yêu cầu báo cáo sau khi vận hành, để nhà cung cấp biết mình sẽ được đo bằng gì. Trong quá trình chọn, chỉ số cần theo dõi là số tình huống thử mỗi bên đạt, số câu hỏi làm rõ phát sinh và mức chênh giữa các báo giá sau khi đã đưa về cùng khung.

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

• Nguồn dữ liệu và chủ sở hữ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

Doanh nghiệp chưa rõ yêu cầu kỹ thuật có viết RFP AI Agent được không? Được. RFP tốt mô tả bài toán nghiệp vụ, dữ liệu hiện có và ràng buộc, còn giải pháp kỹ thuật để nhà cung cấp đề xuất. Phần doanh nghiệp cần viết rõ là kết quả mong muốn, hệ thống đang dùng và những việc agent không được làm.

Nên bắt đầu viết RFP từ phần nào? Bắt đầu từ phạm vi nghiệp vụ: chọn một đến ba luồng cụ thể, mô tả người dùng, đầu vào và kết quả mong đợi. Các phần như bảo mật, SLA và tiêu chí chấm điểm dựa vào phạm vi này nên viết sau.

Có nên gửi dữ liệu thật trong RFP không? Không nên gửi dữ liệu thật chứa thông tin khách hàng, nhân sự hay tài chính. Hãy dùng dữ liệu mẫu đã che thông tin nhạy cảm nhưng giữ đúng cấu trúc và các lỗi thường gặp, kèm thỏa thuận bảo mật nếu cần chia sẻ sâu hơn.

Làm sao so sánh các đề xuất có cách báo giá khác nhau? Yêu cầu mọi nhà cung cấp tách giá theo cùng một khung: khảo sát, phát triển, tích hợp từng hệ thống, chi phí vận hành định kỳ và hạng mục tùy chọn. Khi khung giống nhau, doanh nghiệp mới thấy được ai đang tính thiếu phần nào.

Kết luận

Một RFP tốt cho dự án AI Agent mô tả bài toán bằng tình huống thật, dữ liệu mẫu thật và tiêu chí chấm công bố trước. Nó giúp doanh nghiệp chọn đơn vị dựa trên cách họ xử lý tình huống khó, chứ không phải bản demo đẹp nhất. Nếu vẫn đang cân nhắc có nên làm với đơn vị bên ngoài hay không, xem thêm bài tự xây hay giao đơn vị triển khai AI Agent.

Trao đổi với Naventic để góp ý phạm vi và bộ tình huống thử cho RFP của bạn. Đọc thêm: Dịch vụ.