Phân nhóm theo nhu cầu, dựng chân dung từ thực tế và chọn đúng điểm khởi đầu để AI tạo ra giá trị thay vì thêm một màn hình.
Hãy hình dung một doanh nghiệp rang xay cà phê đang muốn triển khai trợ lý AI.
Trong buổi giới thiệu, trợ lý trả lời trôi chảy về sản phẩm, soạn email báo giá và tóm tắt đơn hàng. Giám đốc hào hứng: “Nếu mọi người đều dùng được thì tốt quá.”
Nhưng sáng hôm sau, khi trở lại công việc, mỗi người lại cần một thứ khác.
Lan bên kinh doanh muốn biết có thể nhận đơn giao sáng mai hay không. Hùng ở kho cần biết lô hàng nào đã được giữ cho khách, tránh xuất nhầm. Mai, chủ một quán cà phê, chỉ muốn đặt lại loại hạt quen thuộc và biết chắc khi nào hàng tới.
Cả ba cùng nhắc đến một đơn hàng. Nhưng họ không cùng giải quyết một bài toán.
Nếu thiết kế cho một “người dùng chung chung”, doanh nghiệp có thể tạo ra một trợ lý nói được rất nhiều, mà chưa giúp ai hoàn thành việc quan trọng nhất.
Trước câu hỏi “chọn AI nào?”, hãy hỏi: “Ta đang giúp nhóm người nào đạt được kết quả gì?”
Đây cũng là bước nối tiếp việc chốt mục tiêu, phạm vi và người quyết định trước khi bắt đầu dự án AI: từ đích đến chung, xác định người cần được phục vụ cụ thể.
1. Chia theo nhu cầu, không chỉ theo sơ đồ tổ chức
Trong ví dụ giả định này, “khách hàng” của giải pháp không chỉ là người trả tiền mua cà phê. Đó còn là nhân viên trực tiếp dùng công cụ và người dựa vào đầu ra của công cụ để ra quyết định.
Người phê duyệt ngân sách có thể muốn thấy năng suất tăng. Người đứng ở kho lại cần thao tác nhanh trên điện thoại. Hai góc nhìn đều quan trọng, nhưng không nên dùng mong muốn của người mua phần mềm để thay thế nhu cầu của người sử dụng.
Điểm bắt đầu hợp lý là phân nhóm theo kết quả cần đạt, trở ngại và bối cảnh làm việc:
Phòng ban là một điểm xuất phát để tìm người phỏng vấn, không phải ranh giới bất biến của các nhóm. Hai nhân viên kinh doanh có thể cần được tách ra: một người tư vấn khách lần đầu, một người xử lý đơn đặt lại. Ngược lại, nhân viên kinh doanh và chăm sóc khách hàng có thể cùng cần xác nhận tiến độ giao hàng.
Tuổi tác hay sở thích chỉ đáng đưa vào nếu chúng làm thay đổi cách sử dụng giải pháp. “Người dùng 30–40 tuổi” chưa nói được họ cần AI làm gì. “Người phải xác nhận đơn gấp trên điện thoại khi đang di chuyển” đã gợi ra yêu cầu thiết kế cụ thể hơn nhiều.
Cùng một đơn hàng, ba nhóm người dùng có ba định nghĩa khác nhau về một công việc được làm tốt.
Đừng dừng ở việc ghi lại thao tác hiện tại. Lan có thể nói: “Tôi cần AI giúp soạn tin nhắn hỏi kho nhanh hơn.” Nhưng nhu cầu sâu hơn của Lan là biết mình có thể hứa gì với khách. Soạn tin nhắn nhanh chỉ là một phương án; một cơ chế xác nhận hàng khả dụng có thể giải quyết đúng vấn đề hơn.
Phân nhóm tốt giúp đội dự án tìm nhu cầu phía sau thao tác, thay vì tự động hóa nguyên trạng những vòng chờ đợi cũ.
2. Chân dung đại diện là một công cụ kiểm tra thiết kế
Sau khi nhận diện nhóm, hãy dựng một chân dung đại diện, thường gọi là persona. Đó là nhân vật tổng hợp giúp đội dự án hình dung người mình đang phục vụ.
Persona không phải tiểu sử trang trí. Thông tin hữu ích là thông tin khiến đội ngũ đưa ra quyết định thiết kế khác đi.
Trong tình huống cà phê, ta có thể viết một chân dung ban đầu như sau:
Lan — người cần chốt đơn mà không hứa quá khả năng giao hàng. Lan thường nhận yêu cầu qua điện thoại, phải phản hồi khi đang ở ngoài văn phòng. Trước khi xác nhận đơn, Lan cần biết lượng hàng khả dụng và lịch giao đã được kiểm tra. Khi dữ liệu chưa đủ, Lan muốn biết phải hỏi ai, thay vì nhận một câu trả lời nghe chắc chắn.
Đây mới là giả thuyết minh họa, chưa phải kết quả nghiên cứu. Trong dự án thật, cần đối chiếu với nhiều người thuộc nhóm: nghe họ kể về một đơn gần đây, quan sát cách xử lý, xem nơi họ phải chờ hoặc sửa sai. Nếu có khác biệt đáng kể, hãy chỉnh chân dung hoặc tách nhóm, đừng ép mọi người vào nhân vật đã viết.
Chân dung ấy biến cuộc tranh luận “giao diện này có đẹp không?” thành những câu hỏi có thể kiểm tra:
Lan có tìm được thông tin quyết định khi dùng điện thoại không?
Lan có phân biệt được tồn kho tổng và lượng còn có thể bán không?
Nếu thông tin chưa cập nhật, màn hình có chỉ rõ điều đó không?
Lan có biết bước tiếp theo và người chịu trách nhiệm không?
Trong ví dụ này, một bản tóm tắt dài về sản phẩm không giúp Lan chốt đơn. Một màn hình ngắn, cho biết nguồn thông tin, thời điểm cập nhật và tình trạng xác nhận, có thể hữu ích hơn.
Persona cũng giúp tránh thiết kế cho chính đội xây dựng. Người làm sản phẩm có thể quen gõ yêu cầu dài trên máy tính; người sử dụng lại đang cầm điện thoại giữa một cuộc gọi. “Tôi dùng được” chưa đồng nghĩa với “họ hoàn thành được việc”.
3. Từ nhu cầu người dùng đến ranh giới của AI
Phân nhóm không chỉ quyết định cách viết lời hướng dẫn. Nó còn giúp xác định dữ liệu nào cần truy cập, thao tác nào được phép thực hiện và kết quả nào phải có người xác nhận.
Lan cần kiểm tra khả năng đáp ứng đơn. Hùng cần đối chiếu hàng thực tế và cập nhật tình trạng chuẩn bị. Mai cần biết thông tin của đơn thuộc quán mình, không phải bảng tồn kho hay danh sách khách hàng của cả doanh nghiệp.
Vì vậy, chung một nền tảng không có nghĩa là chung mọi quyền truy cập. Tách nhóm nhu cầu cũng không đồng nghĩa phải xây một hệ thống độc lập cho mỗi nhóm.
Doanh nghiệp có thể dùng chung dữ liệu sản phẩm, định danh đơn hàng và quy tắc nghiệp vụ. Phía trên nền tảng đó là các luồng làm việc khác nhau, với quyền xem và quyền thao tác phù hợp.
Nhu cầu rõ giúp xác định AI được hỗ trợ đến đâu — và phải dừng ở đâu.
Một điểm phân biệt quan trọng: “hệ thống ghi nhận còn hàng” chưa chắc đã có nghĩa “có thể giao sáng mai”. Lời hứa giao hàng còn phụ thuộc vào lượng đã giữ, tiến độ chuẩn bị và lịch vận chuyển.
Trong một thiết kế thận trọng cho tình huống này, AI có thể tổng hợp các thông tin ấy và soạn phản hồi. Việc giữ hàng hoặc xác nhận lịch giao phải đi qua cơ chế nghiệp vụ có thẩm quyền. Khi thiếu dữ liệu, hệ thống nên chỉ rõ phần chưa xác nhận và chuyển đến người phụ trách, không biến suy đoán thành cam kết với khách.
Nhìn từ nhu cầu cụ thể, đội kiến trúc sẽ dễ phân biệt ba việc: AI giúp đọc và diễn đạt; hệ thống nghiệp vụ kiểm tra và ghi nhận; con người xử lý ngoại lệ hoặc quyết định trong phạm vi được giao. Ranh giới thực tế cần được thống nhất cho từng quy trình, không mặc định từ khả năng trình diễn của trợ lý.
Nếu quy trình có nhiều trợ lý cùng tham gia, có thể đọc thêm góc nhìn về giao việc, chia sẻ dữ liệu và giữ nhịp phối hợp giữa các AI agent.
4. Nhóm tạo doanh thu chưa chắc là nơi nên bắt đầu
Nếu hỏi nên ưu tiên ai, câu trả lời dễ xuất hiện là “kinh doanh, vì họ mang về doanh thu”. Cách nghĩ này có lý, nhưng chưa đủ.
Hãy quay lại lý do Lan phải gọi Hùng. Nếu thông tin về hàng đã giữ chưa được cập nhật, trợ lý của Lan dù trả lời nhanh hơn cũng không có căn cứ tốt hơn. Nút thắt nằm trước màn hình của Lan.
Trong trường hợp ấy, điểm khởi đầu có thể là nhóm chuẩn bị và xuất hàng: làm rõ cách ghi nhận hàng đã giữ, hàng đang chuẩn bị và hàng còn khả dụng. Khi thông tin đó đáng tin hơn, bộ phận kinh doanh mới có cơ sở để phản hồi khách.
Không có quy tắc rằng kho luôn phải đi trước. Nếu dữ liệu đã tốt mà thời gian phản hồi vẫn dài, nhóm tư vấn có thể là ưu tiên phù hợp. Nếu chiến lược là phát triển khách đặt lại trực tuyến, chủ quán đặt hàng định kỳ có thể trở thành nhóm trọng tâm.
Ưu tiên là quyết định về giá trị trong một bối cảnh, không phải bảng xếp hạng tầm quan trọng của con người.
Muốn làm rõ đích đến trước khi xếp thứ tự, hãy đặt việc phân nhóm trong góc nhìn kiến trúc AI bắt đầu bằng giá trị, thay vì bắt đầu từ danh sách mô hình hay tính năng.
Trước khi chọn nhóm đầu tiên, hãy cùng người phụ trách nghiệp vụ và lãnh đạo trả lời:
Giải quyết nhu cầu này có tác động trực tiếp đến mục tiêu kinh doanh nào?
Điểm nghẽn xảy ra thường xuyên đến đâu, và hậu quả của sai sót là gì?
Nhóm này phụ thuộc vào thông tin hoặc quyết định của nhóm nào khác?
Có đủ dữ liệu và người chịu trách nhiệm để kiểm chứng thay đổi chưa?
Làm tốt ở đây có giúp các nhóm tiếp theo bớt khó khăn không?
Nếu quy trình cập nhật kho đã đáp ứng nhu cầu, không cần gắn AI vào đó chỉ để gọi dự án là “AI”. Có khi điều nên làm trước là sửa cách bàn giao và xác nhận dữ liệu.
Trong tình huống dữ liệu kho chưa đáng tin, giá trị cho khách hàng bắt đầu từ một bước nội bộ ít hào nhoáng.
5. Thử nhỏ, nhưng đo theo công việc thật
Một thử nghiệm có ích không cần phục vụ cả công ty ngay. Nó cần đủ rõ để biết thay đổi có giúp nhóm đã chọn hay không.
Nếu chọn nhóm tư vấn đơn đặt lại, phạm vi có thể là một dòng sản phẩm, một khu vực giao hàng và một tập tình huống đã thống nhất. Chưa mở sang tư vấn khách mới, đổi trả hay dự báo nhu cầu.
Trước thử nghiệm, ghi nhận cách làm hiện tại. Sau đó theo dõi những chỉ dấu gắn với kết quả:
Thời gian từ lúc nhận yêu cầu đến lúc có phản hồi đã xác nhận.
Những lần phải sửa lời hứa giao hàng vì thông tin sai hoặc thiếu.
Những trường hợp cần hỏi lại hoặc chuyển người phụ trách.
Khả năng người dùng hoàn thành việc mà không phải quay về cách cũ.
Đọc các chỉ dấu cùng nhau. Thời gian phản hồi giảm mà số lần sửa cam kết tăng thì chưa thể gọi là thành công. Ngược lại, việc chuyển người phụ trách nhiều hơn có thể cho thấy hệ thống đang nhận diện được những trường hợp chưa đủ căn cứ; cần xem từng tình huống để hiểu nguyên nhân.
Một bộ tình huống kiểm tra nên có cả ngày bình thường lẫn ngày khó: đủ hàng, thiếu hàng, dữ liệu cũ, đơn thay đổi phút cuối và yêu cầu vượt quyền truy cập. Điều cần kiểm tra không chỉ là câu trả lời có trôi chảy không, mà là công việc có được xử lý đúng không.
Khi nhóm đầu tiên đạt kết quả, mới xem nhóm tiếp theo khác ở đâu. Tận dụng phần dùng chung, bổ sung phần khác biệt và kiểm tra lại những giả định. Đó là cách mở rộng có học hỏi, thay vì nhân bản một trợ lý chưa hiểu người dùng.
Trước khi vẽ kiến trúc, hãy viết một câu
Một câu mở đầu hữu ích cho dự án là:
“Giải pháp này giúp [nhóm người dùng] đạt [kết quả], trong [bối cảnh]; thành công được kiểm chứng bằng [dấu hiệu], còn [ngoại lệ] do [người phụ trách] xử lý.”
Ví dụ: “Giải pháp giúp người tư vấn đơn đặt lại xác nhận khả năng đáp ứng khi trao đổi với khách trên điện thoại; thành công được kiểm chứng bằng thời gian phản hồi đã xác nhận và số lần sửa cam kết, còn lịch giao chưa rõ do người phụ trách vận hành xác nhận.”
Nếu chưa viết được câu này, có lẽ đội dự án cần hiểu người dùng hơn trước khi mở rộng danh sách tính năng.
AI cho cả công ty có thể là đích đến. Nhưng điểm khởi đầu nên là một nhóm có nhu cầu rõ, một nút thắt đáng giải quyết và một kết quả đủ cụ thể để kiểm chứng.
Trong doanh nghiệp của bạn, nhóm nào cần được phục vụ trước — và đâu là điều đang khiến họ không thể làm tốt công việc hôm nay?