Có một cảnh mình gặp khá thường xuyên khi nói chuyện với các doanh nghiệp.
Sếp mở ChatGPT hoặc Claude, nhập một yêu cầu kiểu: “Hãy xây cho tôi chiến lược chăm sóc khách hàng bằng AI.” Vài chục giây sau, màn hình hiện ra một bản kế hoạch dài, chia mục rõ ràng, câu chữ nghe rất chuyên nghiệp.
Mọi người nhìn nhau: AI giỏi thật.
Nhưng hỏi thêm ba câu thì cả phòng bắt đầu im lặng:
Khách hàng nào đang cần được chăm sóc tốt hơn?
Vấn đề hiện tại là phản hồi chậm, tư vấn sai hay bỏ sót khách?
Kết quả nào sẽ chứng minh hệ thống mới có ích?
Không ai trả lời chắc chắn.
Đây là lỗi gốc của rất nhiều dự án AI: chúng ta bắt đầu bằng công cụ, trong khi chưa thống nhất bài toán. Và AI càng mạnh, lỗi này càng khó nhận ra — vì nó có thể biến một yêu cầu mơ hồ thành một câu trả lời trông rất hoàn chỉnh.
Hãy hình dung AI là một sinh viên năm ba
Lấy ví dụ tưởng tượng đầu tiên.
Bạn tuyển một sinh viên năm ba rất sáng dạ vào thực tập. Bạn ấy đọc nhanh, viết tốt, biết dùng nhiều công cụ và có thể thức cả đêm để làm một bản phân tích. Nhưng bạn ấy chưa từng vận hành doanh nghiệp của bạn. Bạn ấy không biết vì sao đội bán hàng gọi một số khách trước, không biết đơn hàng nào lời thật, và càng không biết lần trước công ty đã trả giá thế nào cho một quyết định tưởng như hợp lý.
Nếu bạn nói:
“Em nghiên cứu thị trường rồi đề xuất sản phẩm mới cho anh.”
Bạn ấy vẫn sẽ làm. Thậm chí làm ra một bộ slide rất đẹp.
Nhưng sản phẩm đó có giải quyết đúng vấn đề không? Chưa chắc. Vì người thực hiện được giao một đầu việc, chứ chưa được giúp hiểu nhu cầu kinh doanh phía sau đầu việc.
AI cũng vậy. Nó đã “đọc” rất nhiều, có thể tổng hợp nhanh hơn chúng ta, nhưng không tự nhiên biết:
quy trình ngầm trong công ty;
ngoại lệ mà chỉ nhân viên lâu năm nhớ;
điều khách hàng nói khác với điều họ thực sự làm;
giới hạn về ngân sách, pháp lý và năng lực triển khai;
tiêu chí thành công mà ban lãnh đạo sẵn sàng trả tiền.
Gọi AI là “sinh viên năm ba” không có nghĩa là coi thường năng lực của nó. Ngược lại, đây là cách đặt đúng kỳ vọng: năng lực xử lý rất cao, nhưng bối cảnh thực tế rất thấp nếu bạn không cung cấp.
Và một sinh viên thông minh được hướng dẫn tốt có thể làm ra kết quả xuất sắc. Một sinh viên thông minh nhận đề bài sai sẽ chỉ tạo ra một sai lầm được trình bày đẹp hơn.
Hoặc coi AI là nhân viên mới có một năm kinh nghiệm
Ví dụ tưởng tượng thứ hai gần với doanh nghiệp hơn.
Hãy coi AI như một nhân viên mới có một năm kinh nghiệm. Người này đã biết nghề, hiểu thuật ngữ, làm được các việc phổ biến và có thể tự tìm tài liệu. Nhưng họ mới vào công ty sáng nay.
Bạn có giao ngay cho họ quyền tự thay đổi chính sách giá không?
Có lẽ là không.
Bạn sẽ cho họ đọc tài liệu, quan sát quy trình, nói chuyện với các bộ phận liên quan, làm thử trên một phạm vi nhỏ rồi mới tăng quyền. Khi họ đưa ra đề xuất, bạn còn yêu cầu giải thích dữ liệu, giả định và rủi ro.
Thế nhưng với AI, nhiều doanh nghiệp lại bỏ qua toàn bộ quá trình này. Họ đưa một câu lệnh ngắn, nhận câu trả lời dài rồi mặc định đó là “phương án của AI”.
Vấn đề không nằm ở prompt chưa đủ hoa mỹ. Vấn đề là AI chưa được onboard vào bài toán.
Nếu muốn đi sâu hơn vào cách phân quyền, cung cấp bối cảnh và đặt điểm dừng, bạn có thể đọc thêm: Đừng tuyển AI như một “nhà tiên tri”: Hãy quản lý nó như nhân viên mới!
Một hệ thống AI tốt không bắt đầu bằng câu hỏi “dùng model nào?”. Nó bắt đầu bằng việc giúp máy và người cùng hiểu:
Công việc hiện tại diễn ra thế nào?
Nỗi đau thật nằm ở đâu?
Ai chịu ảnh hưởng nếu quy trình thay đổi?
Kết quả tốt trông như thế nào?
Dùng con số nào để kiểm tra kết quả đó?
Yêu cầu không phải là danh sách tính năng
Khi nghe từ “requirements” hay “yêu cầu”, nhiều người nghĩ đến một file dài hàng chục trang: chatbot phải có nút này, dashboard phải có biểu đồ kia, agent phải nối được CRM và email.
Nhưng yêu cầu không thực sự bắt đầu từ tính năng. Nó bắt đầu từ nhu cầu cần được thỏa mãn.
Ví dụ, một đội chăm sóc khách hàng nói: “Chúng tôi cần chatbot AI.” Đó mới chỉ là giải pháp họ hình dung, chưa phải vấn đề.
Đào sâu thêm, ta có thể phát hiện:
60% câu hỏi đến ngoài giờ hành chính;
nhân viên mất nhiều thời gian trả lời các câu lặp lại;
khách VIP đôi khi bị xếp chung với câu hỏi thông thường;
thông tin trả lời nằm rải rác trong nhiều tài liệu cũ.
Bây giờ bài toán đã khác. Có thể chatbot là một phần của lời giải. Cũng có thể giải pháp hiệu quả hơn là làm sạch kho tri thức, tự động phân loại yêu cầu và chỉ dùng AI soạn câu trả lời để nhân viên duyệt.
Nếu nhảy thẳng vào “xây chatbot”, ta rất dễ tự động hóa một quy trình vốn đã lộn xộn.
Đây là nguyên tắc mình nghĩ mọi lãnh đạo nên nhớ:
Phần mềm hay AI không phải mục tiêu. Kết quả kinh doanh mới là mục tiêu.
Xây được hệ thống chưa có nghĩa là giải được vấn đề. Một dự án có thể chạy đúng kỹ thuật, đúng deadline, thậm chí được demo rất ấn tượng — nhưng vẫn không tạo ra giá trị cho người dùng.
Khách hàng nói điều họ muốn, chưa chắc nói đúng điều họ cần
Nghe có vẻ nghịch lý, nhưng người dùng không phải lúc nào cũng mô tả chính xác nhu cầu của chính mình.
Không phải họ cố tình cung cấp thông tin sai. Đơn giản là rất khó nhìn toàn bộ hệ thống từ vị trí của một cá nhân. Nhân viên bán hàng thấy một phần. Kế toán thấy một phần. Vận hành thấy một phần. Ban giám đốc lại nhìn một phần khác.
Vì vậy, thu thập yêu cầu không phải là ghi chép nguyên văn mọi đề xuất rồi giao cho đội kỹ thuật. Người phụ trách phải biết hỏi lại, dựng mô hình, làm prototype nhỏ và phản chiếu điều đã hiểu cho các bên kiểm tra.
Với AI, prototype càng trở nên rẻ và nhanh. Đây là lợi thế rất lớn nếu dùng đúng.
Thay vì tranh luận ba tuần về một agent chăm sóc khách hàng, hãy cho nó xử lý 50 tình huống đã ẩn dữ liệu nhạy cảm. Quan sát nơi nó trả lời sai. Hỏi nhân viên vì sao câu đó sai. Bổ sung quy tắc. Chạy lại.
Mỗi vòng thử là một cách hiểu bài toán sâu hơn.
Prototype không chỉ dùng để chứng minh AI làm được. Nó còn dùng để phát hiện chúng ta đã hiểu sai điều gì.
Ba lớp của một yêu cầu AI có thể triển khai
Mình thường rút một yêu cầu AI về ba lớp đơn giản.
1. Giá trị: Tại sao phải làm?
Nếu không làm, doanh nghiệp đang mất gì? Nếu làm tốt, ai được lợi và lợi ở đâu?
Ví dụ: “Giảm thời gian nhân viên tìm thông tin để họ có thêm thời gian xử lý các ca phức tạp.” Câu này tốt hơn nhiều so với “Xây trợ lý hỏi đáp nội bộ”.
Lớp giá trị giúp ta loại bỏ những tính năng nghe hấp dẫn nhưng không đáng đầu tư.
2. Hành vi: Hệ thống cần làm gì?
Mô tả hành vi mong muốn trong ngữ cảnh cụ thể:
nhận câu hỏi của nhân viên;
tìm trong bộ tài liệu đã duyệt;
trích nguồn cho từng câu trả lời;
từ chối khi không đủ căn cứ;
chuyển cho chuyên gia khi gặp nhóm chủ đề rủi ro.
Càng rõ hành vi, AI càng ít phải tự đoán.
3. Tiêu chí: Thế nào mới được coi là đạt?
Đây là phần thường bị bỏ quên nhất.
“Trả lời chính xác” là chưa đủ. Chính xác bao nhiêu? Trên nhóm câu hỏi nào? Tốc độ thế nào? Sai kiểu nào là không chấp nhận được?
Một tiêu chí tốt có thể là:
ít nhất 90% câu trả lời trong bộ kiểm thử được chuyên gia đánh giá là đúng và đủ;
100% câu trả lời về chính sách phải dẫn nguồn từ tài liệu còn hiệu lực;
câu hỏi không có căn cứ phải được từ chối, không được bịa;
thời gian phản hồi dưới 10 giây ở tải vận hành bình thường.
Nếu không đo được, chúng ta chưa có yêu cầu hoàn chỉnh. Chúng ta mới có một mong muốn.
Và quan trọng hơn một điểm số đẹp là quyết định mà phép đo đó cho phép doanh nghiệp đưa ra — chủ đề mình đã phân tích trong bài Đừng hỏi AI được mấy điểm: Hãy hỏi kết quả đó dẫn đến quyết định nào.
Từ “prompt hay” sang quy trình có kiểm chứng
Prompt quan trọng, nhưng prompt không cứu được một bài toán mơ hồ.
Một prompt chỉ là một phần của môi trường làm việc. Dữ liệu, công cụ, quyền hạn và cơ chế kiểm tra mới biến nó thành hệ thống đáng tin; xem thêm Prompt hay chưa đủ: Muốn AI làm việc đáng tin, hãy thiết kế “bàn làm việc” cho nó.
Doanh nghiệp không cần một câu thần chú để AI luôn đúng. Doanh nghiệp cần một quy trình có thứ tự:
Bước 1: Viết vấn đề bằng ngôn ngữ kinh doanh.
Không nhắc đến chatbot, agent hay model. Chỉ mô tả công việc, điểm nghẽn và tác động.
Bước 2: Vẽ lại cách công việc đang diễn ra.
Ai làm gì, nhận dữ liệu từ đâu, quyết định ở điểm nào, ngoại lệ nào thường xuất hiện?
Bước 3: Xác định người chịu giá trị và người chịu rủi ro.
Người dùng AI chưa chắc là người hưởng lợi cuối cùng. Và người chịu hậu quả khi AI sai có thể là một bộ phận khác.
Bước 4: Chọn phạm vi thử nghiệm nhỏ.
Một nhóm khách, một loại hồ sơ, một quy trình lặp lại. Đừng bắt đầu bằng “AI hóa toàn công ty”.
Bước 5: Đặt thước đo trước khi chạy.
Nếu chỉ chọn KPI sau khi xem kết quả, chúng ta rất dễ chọn đúng con số làm dự án trông thành công.
Bước 6: Cho con người kiểm tra và ghi lại lỗi.
Mỗi lỗi phải quay về cải thiện dữ liệu, hướng dẫn, công cụ hoặc chính định nghĩa yêu cầu.
Đó là vòng lặp biến AI từ một màn demo thành một năng lực vận hành.
Một checklist ngắn trước khi giao việc cho AI
Trước khi nhấn Enter, hãy tự hỏi bảy câu:
Tôi đang mô tả vấn đề hay đang áp đặt một giải pháp?
AI đã có đủ bối cảnh về doanh nghiệp và người dùng chưa?
Dữ liệu nào là nguồn sự thật được phép sử dụng?
Có ngoại lệ hoặc rủi ro nào tuyệt đối không được tự đoán?
Kết quả đầu ra sẽ được ai dùng, trong quyết định nào?
Tiêu chí nào cho biết câu trả lời là đạt?
Ai chịu trách nhiệm kiểm tra trước khi hành động thật?
Nếu chưa trả lời được ba câu cuối, đừng vội tự động hóa. Hãy dùng AI để khám phá bài toán trước: yêu cầu nó phỏng vấn bạn, chỉ ra giả định, tạo tình huống phản biện và đề xuất bộ kiểm thử.
Đây mới là cách tận dụng trí tuệ của AI: không phải giao quyền quyết định khi bối cảnh còn thiếu, mà dùng tốc độ của nó để làm rõ bối cảnh nhanh hơn.
AI không thay thế việc hiểu doanh nghiệp
AI có thể thay đổi rất nhiều khâu trong quy trình làm việc. Nhưng nó không xóa bỏ một sự thật căn bản: giải pháp tốt chỉ xuất hiện khi ta hiểu đúng nhu cầu, giá trị và tiêu chí thành công.
Nếu coi AI là một “chuyên gia toàn năng”, bạn sẽ dễ tin vào câu trả lời trôi chảy của nó.
Nếu coi AI là sinh viên năm ba hoặc nhân viên mới có một năm kinh nghiệm, bạn sẽ làm điều hợp lý hơn: cung cấp bối cảnh, giới hạn phạm vi, yêu cầu bằng chứng, kiểm tra đầu ra và tăng quyền theo kết quả thực tế.
Sự khác biệt không nằm ở việc ai có model mạnh hơn.
Nó nằm ở việc ai biết biến một mong muốn mơ hồ thành một bài toán có thể hiểu, có thể đo và có thể kiểm chứng.
Tuần này, hãy chọn một quy trình mà công ty đang muốn “gắn AI” vào. Đừng hỏi AI nên xây gì. Hãy viết ra trước: vấn đề thật là gì, ai đang chịu nó, và con số nào phải thay đổi.
Rất có thể, chỉ riêng ba câu đó đã giúp bạn tiết kiệm vài tháng xây nhầm thứ.