Tài liệu yêu cầu chatbot AI: Khung đặc tả dự án

Tài liệu yêu cầu chatbot AI là bản mô tả thống nhất giữa bộ phận nghiệp vụ, đội kỹ thuật và nhà cung cấp về mục tiêu, người dùng, tình huống sử dụng, dữ liệu, kênh triển khai, quyền truy cập và cách nghiệm thu hệ thống. Tài liệu càng rõ thì doanh nghiệp càng dễ đánh giá tính khả thi, so sánh phương án và kiểm soát phạm vi triển khai.

Doanh nghiệp không cần viết ngay một tài liệu kỹ thuật phức tạp. Bản đầu tiên chỉ cần trả lời rõ chatbot phục vụ ai, giải quyết việc gì, được phép sử dụng nguồn dữ liệu nào, phải kết nối với hệ thống nào và kết quả nào được xem là đạt. Sau đó, nhà cung cấp mới có cơ sở tư vấn kiến trúc, quy trình triển khai và phương án vận hành phù hợp.

Tài liệu yêu cầu chatbot AI dùng để làm gì?

Một bản đặc tả chatbot AI tốt giúp doanh nghiệp giải quyết bốn vấn đề chính:

• Thống nhất mục tiêu: tránh tình trạng mỗi phòng ban kỳ vọng chatbot thực hiện một nhiệm vụ khác nhau.
• Kiểm soát phạm vi: phân biệt chức năng cần có trong giai đoạn đầu với các nhu cầu có thể triển khai sau.
• Đánh giá nhà cung cấp: tạo cùng một cơ sở để xem xét đề xuất giải pháp, tích hợp, bảo mật và hỗ trợ vận hành.
• Nghiệm thu có căn cứ: xác định trước điều kiện đạt hoặc không đạt thay vì đánh giá theo cảm nhận.

Tài liệu này không thay thế thiết kế kỹ thuật chi tiết. Đây là đầu vào để doanh nghiệp và đơn vị cung cấp dịch vụ chatbot AI cùng phân tích giải pháp, xác nhận giới hạn và xây dựng kế hoạch triển khai.

Khung đặc tả chatbot AI doanh nghiệp nên chuẩn bị

1. Mục tiêu kinh doanh

Hãy bắt đầu bằng vấn đề cần giải quyết, không bắt đầu bằng danh sách tính năng. Mục tiêu nên gắn với một quy trình cụ thể, chẳng hạn:

• Hỗ trợ khách hàng tra cứu thông tin sản phẩm và chính sách.
• Tiếp nhận nhu cầu ban đầu trước khi chuyển cho nhân viên tư vấn.
• Hướng dẫn nhân sự tìm quy trình, biểu mẫu hoặc tài liệu nội bộ.
• Hỗ trợ đại lý tra cứu thông tin theo quyền được cấp.
• Giảm các câu hỏi lặp lại mà nhân viên đang xử lý thủ công.

Mỗi mục tiêu cần đi kèm kết quả mong đợi có thể kiểm tra. Nếu chưa có ngưỡng số liệu đáng tin cậy, doanh nghiệp có thể mô tả kết quả theo hướng định tính như trả lời đúng nguồn, chuyển tiếp đúng bộ phận, không tiết lộ dữ liệu ngoài quyền và lưu được lịch sử phục vụ đối soát.

2. Nhóm người dùng

Không nên mô tả chung rằng chatbot phục vụ tất cả mọi người. Mỗi nhóm người dùng có nhu cầu, ngôn ngữ, quyền truy cập và mức độ hiểu biết khác nhau.

Tài liệu nên xác định:

• Người dùng là khách truy cập chưa đăng nhập, khách hàng, đại lý, nhân viên hay quản trị viên.
• Người dùng truy cập chatbot trong bối cảnh nào.
• Họ thường hỏi bằng ngôn ngữ, thuật ngữ hoặc cách diễn đạt nào.
• Họ được phép xem loại thông tin nào.
• Trường hợp nào cần xác thực danh tính.
• Khi nào cuộc hội thoại phải chuyển cho con người.

Nếu có nhiều nhóm, hãy ưu tiên nhóm mang lại giá trị rõ nhất cho giai đoạn đầu. Việc triển khai đồng thời quá nhiều đối tượng thường làm tăng số nguồn dữ liệu, luồng hội thoại và quy tắc phân quyền cần xử lý.

3. Tình huống sử dụng

Mỗi use case nên được viết như một nhiệm vụ hoàn chỉnh thay vì một câu mô tả tính năng. Một tình huống sử dụng cần có:

• Người thực hiện: nhóm người dùng nào đặt câu hỏi hoặc gửi yêu cầu.
• Mục đích: người dùng muốn hoàn thành việc gì.
• Đầu vào: câu hỏi, mã đơn, hình ảnh, tệp hoặc thông tin nhận dạng cần cung cấp.
• Nguồn xử lý: chatbot được phép tra cứu ở đâu.
• Kết quả: chatbot phải trả lời, hướng dẫn hay tạo yêu cầu chuyển tiếp.
• Ngoại lệ: cách xử lý khi thiếu dữ liệu, không hiểu ý hoặc hệ thống tích hợp không phản hồi.
• Điều kiện chuyển người: bộ phận tiếp nhận và thông tin cần bàn giao.

Ví dụ, yêu cầu tra cứu chính sách đổi trả không nên chỉ ghi chatbot trả lời chính sách. Đặc tả cần làm rõ chatbot lấy nội dung từ tài liệu nào, có cần xác định loại khách hàng hay không, phải dẫn lại nguồn nào và xử lý thế nào nếu chính sách giữa các kênh bán khác nhau.

4. Nguồn dữ liệu và tri thức

Chatbot chỉ nên sử dụng các nguồn đã được doanh nghiệp kiểm tra và cho phép. Danh mục nguồn dữ liệu cần ghi rõ:

Nội dung cần xác định	Câu hỏi doanh nghiệp cần trả lời
Loại nguồn	Dữ liệu nằm trên website, tệp tài liệu, cơ sở dữ liệu hay hệ thống nghiệp vụ?
Chủ sở hữu	Phòng ban nào chịu trách nhiệm về tính đúng và tính cập nhật?
Quyền sử dụng	Nội dung được dùng công khai, dùng nội bộ hay chỉ dành cho một nhóm?
Tần suất thay đổi	Nguồn được cập nhật theo sự kiện, theo quy trình hay không có lịch cố định?
Mức độ ưu tiên	Khi nhiều nguồn khác nhau, nguồn nào được xem là chuẩn?
Dữ liệu nhạy cảm	Nội dung nào không được đưa vào kho tri thức hoặc không được hiển thị trong câu trả lời?
Truy xuất nguồn	Câu trả lời có cần ghi tên tài liệu hoặc đường dẫn tham chiếu hay không?

Doanh nghiệp cũng cần chỉ định người phê duyệt nội dung và quy trình xử lý khi tài liệu mâu thuẫn. Nếu dùng AI để hỗ trợ chuẩn hóa tài liệu đầu vào, các nguyên tắc trong bài cách lập brief AI an toàn có thể được áp dụng để làm rõ nguồn, giới hạn và yêu cầu kiểm chứng.

5. Kênh triển khai và tích hợp

Tài liệu yêu cầu phải nêu rõ chatbot xuất hiện ở đâu và từng kênh có chức năng gì. Các lựa chọn có thể gồm website, ứng dụng, cổng thông tin nội bộ hoặc kênh liên lạc doanh nghiệp đang quản lý.

Với mỗi kênh, cần xác định:

• Người dùng có phải đăng nhập hay không.
• Chatbot có cần nhận biết người dùng giữa nhiều phiên hay không.
• Lịch sử hội thoại được lưu và hiển thị như thế nào.
• Giao diện cần hỗ trợ văn bản, hình ảnh, tệp hay nút lựa chọn.
• Kênh có cho phép chuyển cuộc hội thoại sang nhân viên hay không.
• Bộ phận nào chịu trách nhiệm quản trị nội dung và tài khoản tích hợp.

Nếu chatbot cần kết nối CRM, hệ thống quản lý đơn hàng, kho dữ liệu hoặc phần mềm nội bộ, hãy mô tả mục đích trao đổi dữ liệu thay vì chỉ liệt kê tên hệ thống. Đặc tả cần nói rõ chatbot đọc dữ liệu, ghi dữ liệu hay thực hiện cả hai; dữ liệu nào được trao đổi; hành động nào cần người dùng xác nhận; và cách xử lý khi kết nối thất bại.

Đối với kênh thoại, doanh nghiệp cần xác định ngôn ngữ, cách đọc thuật ngữ, khả năng ngắt lời và môi trường sử dụng trước khi cân nhắc khả năng chuyển văn bản thành giọng nói trong giải pháp.

6. Quyền truy cập và bảo vệ dữ liệu

Phân quyền cần được thiết kế theo nhóm người dùng và theo hành động. Một người được phép xem thông tin chưa chắc đã được phép sửa, tải xuống hoặc gửi thông tin đó sang hệ thống khác.

Bản đặc tả nên phân loại tối thiểu các quyền sau:

• Quyền truy cập chatbot.
• Quyền xem từng nhóm dữ liệu.
• Quyền thực hiện giao dịch hoặc tạo yêu cầu.
• Quyền xem lịch sử hội thoại.
• Quyền cập nhật kho tri thức.
• Quyền cấu hình lời chào, quy tắc và luồng chuyển tiếp.
• Quyền xem báo cáo vận hành.
• Quyền quản trị tài khoản và phân quyền cho người khác.

Doanh nghiệp cũng cần xác định dữ liệu nào không được nhập vào chatbot, dữ liệu nào phải che bớt khi hiển thị và thời gian lưu trữ nào phù hợp với chính sách nội bộ. Các yêu cầu liên quan đến dữ liệu cá nhân, dữ liệu khách hàng hoặc thông tin nội bộ cần được bộ phận có trách nhiệm về pháp lý và an toàn thông tin xem xét trước khi triển khai.

7. Quy tắc trả lời và chuyển tiếp

Chatbot không nên cố trả lời mọi câu hỏi. Tài liệu cần quy định rõ các trường hợp hệ thống phải thừa nhận giới hạn, yêu cầu bổ sung thông tin hoặc chuyển cho nhân viên.

Các quy tắc nên bao gồm:

• Chỉ trả lời dựa trên nguồn dữ liệu được duyệt.
• Không tự suy đoán khi không tìm thấy căn cứ phù hợp.
• Thông báo rõ khi câu trả lời có thể chưa đủ thông tin.
• Không thực hiện hành động quan trọng nếu chưa có xác nhận cần thiết.
• Không hiển thị dữ liệu vượt quá quyền của người đang sử dụng.
• Chuyển đúng bộ phận khi gặp khiếu nại, giao dịch bất thường hoặc yêu cầu ngoài phạm vi.
• Bàn giao cho nhân viên kèm nội dung hội thoại và các dữ kiện đã thu thập, nếu chính sách cho phép.

Giọng điệu cũng nên được mô tả bằng nguyên tắc cụ thể, chẳng hạn rõ ràng, lịch sự, không dùng thuật ngữ khó hiểu và không đưa ra cam kết vượt thẩm quyền. Chỉ nêu vài nguyên tắc có thể áp dụng nhất quán thay vì liệt kê quá nhiều tính từ chung chung.

Cách xác định phạm vi dự án chatbot

Phạm vi dự án chatbot nên được chia thành ba nhóm để tránh biến mọi nhu cầu thành yêu cầu bắt buộc.

Chức năng thuộc giai đoạn đầu

Đây là các chức năng cần thiết để giải quyết mục tiêu ưu tiên và có đủ dữ liệu để triển khai. Mỗi chức năng phải có chủ sở hữu nghiệp vụ, nguồn dữ liệu và tiêu chí nghiệm thu.

Chức năng dự kiến mở rộng

Nhóm này gồm các nhu cầu có giá trị nhưng chưa đủ dữ liệu, chưa sẵn sàng tích hợp hoặc chưa cần cho lần triển khai đầu. Việc ghi nhận riêng giúp doanh nghiệp lựa chọn kiến trúc có khả năng mở rộng mà không làm tăng phạm vi hiện tại.

Nội dung nằm ngoài phạm vi

Cần ghi rõ những gì chatbot chưa thực hiện, ví dụ không tư vấn các vấn đề cần chuyên gia phê duyệt, không tự sửa dữ liệu nghiệp vụ, không truy cập nguồn chưa được cấp quyền hoặc không thay thế hoàn toàn bộ phận hỗ trợ.

Một phạm vi rõ nên trả lời được các câu hỏi sau:

1. Nhóm người dùng nào được phục vụ trước?
2. Những use case nào chắc chắn được triển khai?
3. Nguồn dữ liệu nào đã sẵn sàng?
4. Kênh nào nằm trong lần triển khai này?
5. Tích hợp nào là bắt buộc?
6. Hành động nào chatbot chỉ hướng dẫn, hành động nào chatbot được phép thực hiện?
7. Khi nào chatbot phải chuyển cho con người?
8. Nội dung nào được xác nhận là ngoài phạm vi?

Mẫu yêu cầu chatbot theo từng nhóm nội dung

Doanh nghiệp có thể dùng cấu trúc dưới đây làm mẫu yêu cầu chatbot khi trao đổi nội bộ và gửi nhà cung cấp.

Thông tin tổng quan

• Mô tả vấn đề nghiệp vụ cần giải quyết.
• Xác định bộ phận sở hữu dự án và người phê duyệt yêu cầu.
• Nêu nhóm người dùng ưu tiên.
• Mô tả kết quả mong đợi sau khi đưa vào vận hành.
• Ghi rõ các giới hạn đã biết về dữ liệu, hệ thống hoặc quy trình.

Danh sách use case

Với từng use case, ghi:

• Tên nhiệm vụ người dùng muốn hoàn thành.
• Nhóm người dùng thực hiện.
• Câu hỏi hoặc đầu vào thường gặp.
• Nguồn dữ liệu được sử dụng.
• Kết quả mong đợi.
• Điều kiện cần xác thực.
• Tình huống ngoại lệ.
• Quy tắc chuyển cho nhân viên.
• Mức độ ưu tiên trong phạm vi dự án.

Danh mục dữ liệu

• Tên nguồn và định dạng dữ liệu.
• Đơn vị sở hữu nguồn.
• Người chịu trách nhiệm cập nhật.
• Quyền truy cập hiện có.
• Mức độ nhạy cảm.
• Quy tắc ưu tiên khi nguồn mâu thuẫn.
• Cách kiểm tra phiên bản và ngày cập nhật.
• Yêu cầu trích dẫn nguồn trong câu trả lời.

Yêu cầu tích hợp

• Hệ thống cần kết nối.
• Mục đích của kết nối.
• Dữ liệu chatbot được đọc hoặc ghi.
• Phương thức xác thực dự kiến.
• Hành động cần người dùng xác nhận.
• Cách xử lý khi hệ thống đích không sẵn sàng.
• Đơn vị quản lý kỹ thuật của hệ thống liên quan.

Yêu cầu vận hành

• Bộ phận theo dõi hội thoại và phản hồi lỗi.
• Người được phép cập nhật kho tri thức.
• Quy trình phê duyệt nội dung mới.
• Cách tiếp nhận câu hỏi chatbot chưa xử lý được.
• Cơ chế kiểm tra lại sau khi thay đổi dữ liệu hoặc cấu hình.
• Loại báo cáo cần phục vụ quản trị.
• Quy trình ngừng hoặc giới hạn chatbot khi phát hiện rủi ro.

Xây dựng tiêu chí nghiệm thu chatbot AI

Tiêu chí nghiệm thu phải xuất phát từ use case và nguồn dữ liệu đã thống nhất. Không nên chỉ dùng yêu cầu chung như chatbot thông minh, trả lời tự nhiên hoặc hoạt động ổn định vì các mô tả này khó kiểm chứng.

Nghiệm thu theo tình huống

Mỗi kịch bản kiểm thử nên gồm:

• Bối cảnh và vai trò người dùng.
• Dữ liệu đầu vào.
• Quyền truy cập áp dụng.
• Hành động mong đợi của chatbot.
• Nội dung bắt buộc phải xuất hiện.
• Nội dung không được phép xuất hiện.
• Nguồn dùng để đối chiếu.
• Điều kiện đạt và không đạt.

Ví dụ, với câu hỏi ngoài kho tri thức, điều kiện đạt có thể là chatbot thông báo chưa có đủ căn cứ, không tự tạo thông tin và hướng dẫn người dùng đến kênh hỗ trợ phù hợp. Với yêu cầu cần đăng nhập, chatbot phải yêu cầu xác thực trước khi truy xuất dữ liệu riêng.

Các nhóm tiêu chí cần có

Nhóm nghiệm thu	Nội dung cần kiểm tra
Độ phù hợp	Câu trả lời có giải quyết đúng ý định trong phạm vi đã định hay không?
Căn cứ dữ liệu	Nội dung có bám nguồn được phê duyệt và chỉ đúng tài liệu tham chiếu hay không?
Phân quyền	Người dùng có chỉ xem được dữ liệu thuộc quyền của mình hay không?
Ngoại lệ	Chatbot xử lý thế nào khi thiếu dữ liệu, câu hỏi mơ hồ hoặc hệ thống tích hợp gặp lỗi?
Chuyển tiếp	Yêu cầu có được chuyển đúng bộ phận và kèm đủ ngữ cảnh cần thiết hay không?
Tích hợp	Dữ liệu đọc, ghi và xác nhận có đúng với đặc tả hay không?
Giao diện	Nội dung có hiển thị đúng trên các kênh và thiết bị nằm trong phạm vi hay không?
Vận hành	Quản trị viên có cập nhật tri thức, xem lịch sử và tiếp nhận lỗi theo đúng quyền hay không?

Nếu cần đặt ngưỡng định lượng, doanh nghiệp và nhà cung cấp nên thống nhất cách đo, tập dữ liệu kiểm thử, thời điểm đo và điều kiện môi trường. Không nên chọn một con số mục tiêu nếu chưa xác định rõ cách tính.

Bộ câu hỏi kiểm thử

Bộ kiểm thử cần bao phủ nhiều cách diễn đạt cho cùng một ý định, câu hỏi thiếu thông tin, câu hỏi có lỗi chính tả, yêu cầu ngoài phạm vi và tình huống người dùng cố truy cập dữ liệu không thuộc quyền. Dữ liệu kiểm thử không nên chứa thông tin nhạy cảm ngoài phạm vi được phê duyệt.

Khi nguồn dữ liệu thay đổi, các tình huống quan trọng cần được kiểm tra lại để bảo đảm câu trả lời, quyền truy cập và luồng tích hợp vẫn đúng.

Hồ sơ cần chuẩn bị trước khi liên hệ nhà cung cấp

Một bộ hồ sơ ban đầu có thể gồm:

• Bản tóm tắt mục tiêu kinh doanh và vấn đề cần giải quyết.
• Danh sách nhóm người dùng theo mức độ ưu tiên.
• Danh sách use case thuộc giai đoạn đầu.
• Danh mục nguồn dữ liệu và chủ sở hữu.
• Sơ đồ hoặc mô tả quy trình nghiệp vụ hiện tại.
• Danh sách kênh triển khai.
• Danh sách hệ thống cần tích hợp và đầu mối kỹ thuật.
• Ma trận vai trò và quyền truy cập.
• Quy tắc chuyển tiếp cho nhân viên.
• Tiêu chí nghiệm thu và bộ tình huống kiểm thử ban đầu.
• Danh sách các nội dung nằm ngoài phạm vi.
• Yêu cầu về quản trị, theo dõi và cập nhật sau triển khai.

Nếu chưa có đủ tài liệu, doanh nghiệp nên ưu tiên hoàn thiện use case, dữ liệu và quyền truy cập trước. Đây là ba nhóm thông tin ảnh hưởng trực tiếp đến việc lựa chọn phương án triển khai.

Khi nhận đề xuất, hãy yêu cầu nhà cung cấp giải thích rõ phần nào đáp ứng bằng cấu hình sẵn có, phần nào cần tích hợp hoặc phát triển thêm, điều kiện dữ liệu cần thiết, trách nhiệm của mỗi bên và cách kiểm thử trước khi bàn giao.

Những lỗi thường gặp khi lập yêu cầu chatbot

Đặt mục tiêu quá rộng

Yêu cầu chatbot trả lời mọi câu hỏi khiến phạm vi không thể kiểm soát. Cách phù hợp hơn là chọn một số nhóm nhiệm vụ có dữ liệu tốt, người sở hữu rõ và giá trị nghiệp vụ cụ thể.

Chỉ liệt kê tính năng

Danh sách như trả lời tự động, hiểu ngôn ngữ tự nhiên và báo cáo chưa cho biết hệ thống phải giải quyết quy trình nào. Mỗi tính năng cần được gắn với người dùng, dữ liệu, hành động và kết quả.

Bỏ qua chất lượng nguồn dữ liệu

Tài liệu trùng lặp, hết hiệu lực hoặc mâu thuẫn có thể làm giảm độ tin cậy của câu trả lời. Doanh nghiệp cần xác định nguồn chuẩn và người chịu trách nhiệm cập nhật trước khi đưa dữ liệu vào hệ thống.

Không mô tả ngoại lệ

Các tình huống thiếu thông tin, không xác thực được người dùng, mất kết nối hoặc câu hỏi ngoài phạm vi phải có cách xử lý rõ. Đây thường là những tình huống ảnh hưởng trực tiếp đến trải nghiệm thực tế.

Để phân quyền đến cuối dự án

Nếu phân quyền chỉ được xem xét sau khi đã xây dựng kho tri thức và tích hợp, doanh nghiệp có thể phải điều chỉnh lại cấu trúc dữ liệu hoặc luồng xử lý. Quyền truy cập nên được xác định ngay từ giai đoạn đặc tả chatbot AI.

Nghiệm thu theo cảm nhận

Một cuộc hội thoại minh họa không đủ để đánh giá toàn bộ hệ thống. Nghiệm thu cần dựa trên bộ tình huống đã thống nhất, bao gồm cả trường hợp đúng, sai, thiếu dữ liệu và vượt quyền.

Từ tài liệu yêu cầu đến kế hoạch triển khai

Sau khi hoàn thành bản yêu cầu, doanh nghiệp nên tổ chức một buổi rà soát có đại diện nghiệp vụ, kỹ thuật, vận hành và bộ phận chịu trách nhiệm về dữ liệu. Mục tiêu là xác nhận cùng một cách hiểu về phạm vi, nguồn thông tin, quyền truy cập và điều kiện nghiệm thu.

Quy trình tiếp theo có thể gồm:

1. Ưu tiên các use case cho giai đoạn đầu.
2. Kiểm tra mức độ sẵn sàng của dữ liệu và hệ thống tích hợp.
3. Xác nhận vai trò của doanh nghiệp và nhà cung cấp.
4. Xây dựng bản thử nghiệm trên phạm vi có kiểm soát.
5. Kiểm thử bằng các tình huống đã phê duyệt.
6. Khắc phục lỗi, xác nhận tiêu chí nghiệm thu và chuẩn bị vận hành.
7. Theo dõi các câu hỏi chưa xử lý được để cải thiện dữ liệu và quy trình.

Tài liệu yêu cầu chatbot AI không cần cố định sau lần viết đầu tiên. Tuy nhiên, mọi thay đổi về use case, nguồn dữ liệu, quyền truy cập hoặc tích hợp nên được ghi nhận và phê duyệt để tránh mở rộng phạm vi ngoài kế hoạch. Một bản đặc tả rõ ràng sẽ giúp cuộc trao đổi với nhà cung cấp tập trung vào nhu cầu thực tế, thay vì bắt đầu từ các tính năng rời rạc.