Bài 1 — Conversational AI PM là ai và sản phẩm hội thoại thực sự là gì

Conversational AI PM: người biến hội thoại thành sản phẩm đo được

Conversational AI Product Manager (CAI PM) là người chịu trách nhiệm cho một sản phẩm mà giao diện chính là hội thoại — chatbot chăm sóc khách hàng, trợ lý đặt hàng, bot nội bộ tra cứu quy trình, hay voice assistant. Khác với PM web/app truyền thống nơi bạn thiết kế màn hình và nút bấm, ở đây bạn thiết kế cách một cuộc trò chuyện diễn ra: người dùng nói gì, hệ thống hiểu gì, trả lời ra sao, và khi nào phải nhường lại cho con người.

Ba loại sản phẩm hội thoại phổ biến

• Task bot (bot tác vụ): giúp hoàn thành một việc cụ thể — tra cứu đơn hàng, đặt lịch, đổi mật khẩu. Thành công đo bằng "việc có xong không".
• Support bot (bot hỗ trợ): trả lời câu hỏi, xử lý khiếu nại, giảm tải cho tổng đài. Thành công đo bằng "có cần người thật vào cuộc không".
• Advisory/assistant (trợ lý tư vấn): gợi ý sản phẩm, tư vấn tài chính, đồng hành học tập. Thành công đo bằng chất lượng lời khuyên và sự hài lòng.

Mỗi loại có kỳ vọng khác nhau, nên bạn không được dùng chung một bộ chỉ số cho tất cả.

Vì sao sản phẩm hội thoại khó hơn bạn tưởng

Một màn hình web có số trạng thái hữu hạn. Một cuộc hội thoại thì gần như vô hạn: người dùng gõ sai chính tả, hỏi lệch chủ đề, hỏi ba việc trong một câu, hoặc cáu gắt. PM hội thoại phải thiết kế cho sự hỗn loạn của ngôn ngữ tự nhiên, chứ không chỉ cho "happy path".

Khung tư duy 5 lớp của một sản phẩm hội thoại

Hãy luôn tách sản phẩm thành 5 lớp để không nhầm lẫn trách nhiệm:

• Understanding (Hiểu): nhận diện người dùng muốn gì — đây là lớp intent.
• Dialog (Điều phối): quyết định bước tiếp theo — hỏi thêm, trả lời, hay chuyển tiếp.
• Content (Nội dung): câu chữ, tone, thông tin trả về.
• Fulfillment (Thực thi): gọi API, tra database, thực hiện hành động thật.
• Handoff (Bàn giao): khi nào và làm sao chuyển sang người thật.

Một PM giỏi biết khi có lỗi thì lỗi nằm ở lớp nào. Ví dụ: bot trả lời sai — do hiểu sai (Understanding) hay do nội dung viết sai (Content)? Hai nguyên nhân này cần hai cách sửa hoàn toàn khác.

Ví dụ cụ thể

Khách nhắn: "Đơn của tôi tới đâu rồi, mà sao lâu thế?"

• Understanding: nhận ra hai ý — (1) tra cứu trạng thái đơn, (2) cảm xúc bực bội.
• Dialog: ưu tiên tra đơn trước, đồng thời chèn câu xoa dịu.
• Content: "Mình hiểu là bạn đang sốt ruột. Để mình kiểm tra ngay nhé..."
• Fulfillment: gọi API tra đơn theo số điện thoại.
• Handoff: nếu đơn bị kẹt >5 ngày, tự động đề nghị nối máy nhân viên.

Một câu nhắn, năm lớp cùng làm việc. Đó là lý do bạn cần khung này.

Vai trò của CAI PM trong đội

Bạn làm việc với: conversation designer (viết luồng và câu chữ), NLP/ML engineer (huấn luyện mô hình hiểu ý), backend engineer (fulfillment), CS/vận hành (nhận escalation), và data/QA (đo lường). PM là người giữ mục tiêu kinh doanh xuyên suốt và quyết định đánh đổi.

Checklist khởi động một dự án hội thoại

• [ ] Đã xác định bot thuộc loại nào (task/support/advisory)?
• [ ] Đã viết ra 5–10 việc người dùng thực sự muốn làm (top use case)?
• [ ] Đã có một chỉ số thành công chính (VD: containment rate hoặc task completion)?
• [ ] Đã biết "cái gì bot KHÔNG làm" (out of scope)?
• [ ] Đã có đường escalation sang người thật ngay từ ngày đầu?

Sai lầm thường gặp

• Coi chatbot là một tính năng, không phải một sản phẩm. Hệ quả: không ai đo lường, bot chết dần.
• Bắt đầu bằng công nghệ ("dùng LLM đi!") thay vì bằng use case. Dẫn tới bot biết nói nhiều nhưng không giải quyết được việc gì.
• Không thiết kế escalation từ đầu. Người dùng bị kẹt trong vòng lặp với bot, trải nghiệm tệ hơn cả khi không có bot.
• Đo sai chỉ số — ví dụ khoe "bot trả lời 10.000 câu/ngày" nhưng không biết bao nhiêu câu thực sự giúp được khách.

Kết bài: CAI PM không phải người "làm chatbot", mà là người thiết kế một hệ thống hiểu — quyết định — hành động — bàn giao quanh ngôn ngữ tự nhiên, và luôn buộc nó vào một mục tiêu kinh doanh đo được. Các bài sau sẽ đào sâu từng lớp.