Cho AI tư vấn đúng sản phẩm, giá và biến thể

Khách thường hỏi bằng tên quen gọi, còn shop có nhiều mẫu, màu và kích cỡ. Bài này hướng dẫn chuẩn bị nguồn để AI tìm đúng hàng và trả lời giá từ dữ liệu của bạn.

Ví dụ dùng Mây Store, cửa hàng hư cấu với áo sơ mi cotton MAY-SM01, hai màu và năm biến thể. Giá, tồn kho và ảnh minh họa trong bài là dữ liệu demo.

1. Chuẩn bị thông tin giúp phân biệt sản phẩm

Trước khi bật AI, kiểm tra danh mục:

Thông tin	Người mua cần biết gì?	Ví dụ Mây Store
Mã và tên	Đang tư vấn đúng mặt hàng nào	MAY-SM01 cotton
Giá và đơn vị	Giá cho một chiếc, bộ hay lựa chọn khác	Giá một chiếc áo
Màu và size	Lựa chọn khách muốn có trong danh mục không	Trắng S/M/L khác xanh nhạt M/L
Tồn theo biến thể	Biến thể cần mua còn hàng không	Không suy từ việc mẫu cha xuất hiện
Chất liệu và số đo	Chọn size theo loại số đo nào	Bảng số đo thành phẩm của áo cotton
Ảnh	Khách đang nhìn đúng mẫu/màu không	Ảnh xanh nhạt không thay cho ảnh trắng

Nếu một thông tin chưa có, xác định người kiểm tra hoặc nguồn bổ sung. Đừng điền một giá trị ước đoán chỉ để bảng trông đầy đủ.

Giữ chính sách đổi trả và bảng số đo trong Knowledge của trợ lý khi phù hợp. Giá/tình trạng hàng cần được kiểm tra ở nguồn sản phẩm; hạn chế chép cùng con số vào nhiều đoạn prompt.

Nhập dữ liệu tư vấn của một mẫu áo

Mở Products → Add product. Nhập tên dễ phân biệt, chẳng hạn [DEMO] Áo sơ mi Mây — cotton, rồi mô tả điểm cần biết của mẫu. Trong AI SALES ADVICE DATA, điền:

1. Material và Fit / shape: 100% cotton, dáng suông; hướng dẫn đối chiếu với chiếc áo khách đang mặc vừa.
2. Size guide: ghi rõ đơn vị và loại số đo. Mẫu cotton dùng vòng ngực áo/dài áo: S 100/66 cm, M 104/68 cm, L 108/70 cm.
3. Best for / recommendation notes: nhu cầu phù hợp và điều cần hỏi thêm. Ví dụ hỏi màu/size, phân biệt mẫu cotton với linen, không tự hứa đặc tính chưa có nguồn.

(1) Chất liệu và phom; (2) số đo có đơn vị; (3) ghi chú giúp tư vấn. Dữ liệu nhập bằng tiếng Việt trên giao diện English.

Vì sao cần ghi loại số đo? Vòng ngực áo 104 cm không có nghĩa người có vòng ngực 104 cm chắc chắn mặc vừa. AI cần biết đây là số đo thành phẩm để hướng dẫn so sánh đúng. Nếu shop dùng bảng theo cơ thể, sửa cả tên số đo, quy tắc chọn size và nguồn Knowledge liên quan.

Tạo từng tổ hợp màu–size

Ở Product variants, chọn Add variant cho mỗi lựa chọn bán. Điền SKU riêng, Size, Color, Stock, Price và ảnh của đúng biến thể khi đã có.

SKU	Size	Color	Stock mẫu	Price mẫu
MAY-SM01-W-S	S	Trắng	5	320000
MAY-SM01-W-M	M	Trắng	8	320000
MAY-SM01-W-L	L	Trắng	4	320000
MAY-SM01-B-M	M	Xanh nhạt	6	320000
MAY-SM01-B-L	L	Xanh nhạt	3	320000

(1) Mã, size, màu của từng lựa chọn; (2) tồn và giá từng dòng; (3) giá và tiền tệ của mẫu cha. Các số lượng chỉ dùng thực hành.

Trong PRICING & IDENTIFICATION, đặt Price 320000, Currency VND, SKU MAY-SM01, Unit chiếc. Với mẫu vật lý này, Requires shipping bật. Bật Stock tracking, nhập Stock quantity 26 tương ứng tổng số lượng năm dòng mẫu, kiểm tra Status là Selling, rồi chọn Save.

Mở Edit từ danh sách để kiểm tra lại: giá 320.000 VND/chiếc, đúng SKU, năm biến thể và số lượng đã lưu. Trong ví dụ này, tổng tồn được nhập riêng; đừng mặc định hệ thống tự cộng hoặc tự đồng bộ mọi trường nếu chưa kiểm tra quy trình kho của shop.

Câu thử sau khi chuẩn bị: “Cotton xanh nhạt size S còn không?” Dữ liệu có áo trắng S và xanh M/L, nhưng không có xanh S. AI cần nói chưa tìm thấy tổ hợp khách chọn và hỏi khách có muốn xem lựa chọn khác, thay vì ghép size S từ dòng trắng sang dòng xanh.

2. Cấu hình Product Lookup

Mở trợ lý → Tools → Technical Configuration. Trong nhóm Consultation & Sales, tìm Product Lookup và chọn configuration.

(1) Giới hạn kết quả; (2) cho AI nhận giá; (3) lưu cấu hình. Nhấn ảnh để xem lớn.

Max results per lookup

Ô này giới hạn số kết quả của mỗi lần tra cứu. Form hiện ghi mặc định 8, giới hạn thực thi tối đa 15. Mẫu Mây dùng 5 để đối chiếu vài lựa chọn.

Nếu danh mục có nhiều mẫu gần giống nhau, hãy thử một câu hỏi chung và một câu có mã cụ thể để kiểm tra kết quả. Tăng giới hạn không thay thế việc có tên/mã rõ ràng hoặc hỏi thêm nhu cầu khách.

Show Price

Bật để công cụ cung cấp giá cho AI. Với trợ lý báo giá từ danh mục, giữ mục này bật và kiểm tra giá trả lời đúng sản phẩm/đơn vị.

Nếu chủ động tắt, prompt cần cách xử lý câu hỏi giá: cho biết chưa có giá để báo và chuyển người theo quy trình. Kiểm tra Knowledge có chứa giá cũ không; tắt một lựa chọn của công cụ không tự xóa giá đã viết ở nguồn khác.

Lưu và bật

Chọn Save configuration, đóng bảng rồi bật Product Lookup trên thẻ công cụ. Mở lại để đối chiếu giá trị và trạng thái. Ready cho biết công cụ đã được chuẩn bị; chưa đủ để kết luận toàn bộ tư vấn mua hàng hoạt động đúng.

Mở Testing (Sandbox) → Test run preflight now. Khi thấy Preflight passed, tiếp tục kiểm tra bằng câu hỏi khách. Preflight ghi rõ chưa gọi AI hoặc gây tác động thực thi.

3. Viết điều kiện tra cứu trong prompt

Tra danh mục khi trả lời sản phẩm, giá, biến thể hoặc tình trạng hàng.
Giữ mã sản phẩm để phân biệt các mẫu gần giống tên.
Nếu nhiều mẫu phù hợp tên khách nói, giới thiệu điểm khác nhau từ nguồn
và hỏi khách muốn mẫu nào trước khi chốt lựa chọn.
Nếu công cụ lỗi hoặc không tìm thấy, nói rõ chưa tra được;
không tự tạo giá, tồn kho hay ngày giao.

Vì sao: yêu cầu “tư vấn chính xác” chưa chỉ cho AI biết cần làm gì khi có hai sản phẩm cùng tên hoặc thiếu dữ liệu. Các điều kiện trên xác định hành động và cách tiếp tục hội thoại.

Với Mây Store, thêm quy tắc chỉ tư vấn mã MAY-. Đây là chỉ dẫn trong prompt; vẫn cần kiểm tra kết quả khi danh mục workspace có sản phẩm khác. Không coi câu chỉ dẫn là cấu hình phân quyền hoặc một bộ lọc danh mục đã được áp dụng.

4. Kiểm tra trước khi dùng cho khách

Câu thử	Điều cần nhìn thấy
“Áo sơ mi MAY-SM01 giá bao nhiêu?”	Báo đúng 320.000đ/chiếc từ nguồn mẫu
“Cotton xanh nhạt size M còn không?”	Kiểm tra đúng biến thể, chỉ báo còn hàng khi nguồn có căn cứ
“Cotton xanh nhạt size S hoặc XL có không?”	Không tạo biến thể ngoài dữ liệu; đưa lựa chọn M/L đã kiểm tra nếu khách muốn
“Cho xem ảnh màu xanh.”	Tin nhắn có đúng ảnh sản phẩm/màu, không chỉ lời hứa đã gửi
“Tôi không cho số điện thoại, chỉ hỏi giá.”	Vẫn trả lời thông tin có trong nguồn

Đối chiếu danh mục, kết quả tra cứu và câu trả lời cuối. Nếu AI tra đúng nhưng nói sai ở câu cuối, giữ bằng chứng của đúng lượt hỏi để điều chỉnh prompt hoặc tìm lỗi; không chỉ nhìn trạng thái thực thi thành công.

5. Từ tư vấn đến đơn hàng, thanh toán và giao hàng

Khi khách đã chọn được hàng, AI Agents còn có thể hỗ trợ các bước tiếp theo. Phần này giới thiệu cách phối hợp công cụ và nơi đối chiếu kết quả. Ví dụ Mây Store dừng ở tư vấn; không tạo giao dịch để minh họa.

Khách đồng ý mua: Order Creator

Order Creator (order_creator) giúp tạo đơn hoặc đề xuất tạo đơn theo chế độ duyệt của bạn. Trước bước này, cần xác định đúng sản phẩm, biến thể, số lượng, giá và thông tin khách cần cho đơn.

Ví dụ khách nói “Lấy hai chiếc cotton xanh M”. AI cần giữ đúng MAY-SM01-B-M, số lượng 2; tiền hàng mẫu là 640.000đ, còn phí giao hàng cần được xác định trước khi chốt tổng thu. Không lấy giá hoặc lựa chọn từ mẫu linen đang được trao đổi ở lượt trước.

Trong cấu hình, Require Confirmation yêu cầu hỏi lại khách. Require human approval before execution yêu cầu nhân viên duyệt thực hiện. Nếu luồng đang chờ nhân viên, câu trả lời cần nói đúng là đã tiếp nhận hoặc đang chờ xử lý.

Kiểm tra tại Orders: đúng khách, mặt hàng, số lượng, tổng tiền và trạng thái. Nhân viên cũng có thể tiếp nhận bằng nút Orders ngay phía trên ô chat; xem tạo đơn trong hội thoại.

Trước khi chốt tổng tiền: Goship Shipping Calculator

Goship Shipping Calculator (goship_calculator) hỗ trợ lấy phí theo điểm lấy/giao và thông tin kiện hàng. Chuẩn bị kho lấy hàng và vận chuyển, địa chỉ nhận cùng cân nặng/kích thước mà luồng báo giá yêu cầu.

AI cần trả theo dịch vụ và phí thực nhận được. Nếu khách mới cho tên thành phố, hãy hỏi phần địa chỉ còn thiếu thay vì tự báo một mức phí. Đối chiếu riêng phí dịch vụ vận chuyển và khoản shop thu khách; chính sách hỗ trợ phí của shop phải có nguồn.

Báo phí là bước để khách cân nhắc phương án. Chưa có mã vận đơn chỉ từ việc công cụ đã trả giá.

Khách chọn chuyển khoản: Payment QR và Payment Checker

Payment QR (payment_qr) tạo QR động cho đơn đã xác minh qua VietQR hoặc SePay; cần kết nối nhận tiền và đúng đơn/số tiền. Trước khi dùng, đối chiếu tài khoản nhận, số tiền và nội dung chuyển khoản. Xem kết nối SePay nếu cơ sở chưa chuẩn bị cổng nhận tiền.

Payment Checker (payment_checker) đọc trạng thái thanh toán được backend hoặc webhook xác minh. Dùng khi cần biết giao dịch đã được ghi nhận chưa; lời khách nói hoặc ảnh chuyển khoản không thay thế kết quả này.

Nếu mục tiêu chỉ là gửi ảnh QR đã chuẩn bị, dùng Insert VietQR trong Prompt Builder rồi thử yêu cầu gửi ảnh. Mẫu Mây đã gửi được ảnh VietQR trong Test run; đây là nhánh gửi ảnh cố định, chưa kiểm chứng QR động theo đơn hoặc xác minh nhận tiền. Xem cách gửi ảnh và VietQR.

Điều quan sát được	Cách hiểu và bước tiếp theo
QR đã được tạo	Khách có thông tin để thanh toán; tiếp tục chờ kết quả xác minh
Khách nhắn “đã chuyển” hoặc gửi ảnh	Tra đúng đơn/giao dịch trước khi xác nhận nhận tiền
Hệ thống báo đang chờ	Nói đang chờ ghi nhận; nhờ nhân viên đối soát nếu cần
Hệ thống xác nhận thanh toán	Trả theo trạng thái của đúng đơn và chuyển sang bước xử lý đơn theo quy trình
Không tra được hoặc thông tin không khớp	Chuyển nhân viên kiểm tra; không báo đã thu hoặc yêu cầu trả lại chỉ từ lỗi tra cứu

Theo dõi tại Transactions & Reconciliation và thông tin thanh toán của đơn. Trạng thái đã tạo đơn, đã thanh toán và đã giao hàng cần được đọc riêng.

Đơn đủ điều kiện gửi: tạo vận đơn rồi theo dõi

GoShip Shipment Creator (goship_shipment_creator) hỗ trợ tạo vận đơn. Dữ liệu phải khớp đơn: người nhận, điểm lấy/giao, kiện hàng, dịch vụ và khoản thu hộ nếu có. Chỉ đưa bước này vào quy trình khi cửa hàng đã sẵn sàng bàn giao kiện và điều kiện duyệt đã được đáp ứng.

Kiểm tra mã vận đơn và trạng thái trong Shipping. Khi khách hỏi tiến độ, GoShip Tracker (goship_tracker) dùng mã vận đơn liên quan để tra hành trình. AI cần nêu tình trạng nguồn trả về; khi chưa có cập nhật mới, không tự hứa ngày hoặc giờ giao chắc chắn.

Nhân viên có thể dùng Create Shipping Label trên dải nút hội thoại để tiếp tục xử lý. Xem thanh toán và giao hàng để nhận biết các phần cần đối chiếu.

Shop bán dịch vụ: Booking Creator

Với dịch vụ có lịch, Booking Creator (booking_creator) giúp tạo booking hoặc đề xuất theo chế độ duyệt. Chuẩn bị dịch vụ, thời lượng, ngày giờ, múi giờ và nguồn lực phục vụ. Một giờ nằm trong giờ mở cửa chưa chứng minh có nhân viên hoặc chỗ trống.

Đọc kết quả tại Bookings: đúng khách, dịch vụ, thời gian và trạng thái. Nếu còn chờ xác nhận, nói rõ đang tiếp nhận yêu cầu. Nhân viên có nút Booking ngay trong chat; xem quản lý lịch hẹn.

Gửi xác nhận đơn trên Messenger

Messenger Order Receipt gửi biên nhận từ dữ liệu đơn thật của khách. Dùng sau khi đã có đơn và muốn khách xem lại mặt hàng, số lượng cùng tổng tiền. Kiểm tra đúng khách và đúng đơn trước khi gửi. Một biên nhận đơn không tự chứng minh shop đã nhận tiền; trạng thái thanh toán cần được xác minh riêng.

Đại lý du lịch: Flight Fare Lookup

Flight Fare Lookup được giới thiệu trong UI là công cụ tra giá vé một chiều hoặc khứ hồi qua Google Flights, có lưu tạm kết quả. Dùng khi khách cần tham khảo chuyến bay; chuẩn bị điểm đi, điểm đến, ngày đi/về và nhu cầu hành khách trước khi tra.

Giá tìm thấy là thông tin để tư vấn tại thời điểm tra cứu. Không nói đã giữ chỗ hoặc xuất vé chỉ vì có kết quả tìm kiếm. Phần này giới thiệu công cụ; ví dụ Mây Store không chạy tra vé hay đặt vé.

Tìm và chuẩn bị các công cụ này

Trong Tools → Technical Configuration, chọn All tools, nhập tên vào Find tools rồi mở configuration hoặc Details nếu thẻ có nút đó. Đọc kết nối, dữ liệu và điều kiện duyệt trước khi bật. Chỉ bật những công cụ thuộc quy trình cơ sở của bạn.

Viết rõ điểm chuyển bước trong prompt

Khi khách đồng ý mua, tóm tắt đúng mẫu, màu, size và số lượng mới nhất.
Chỉ báo tổng cần thanh toán khi giá, phí và ưu đãi đã có căn cứ.
Thực hiện bước tạo đơn theo công cụ và chế độ duyệt đã cấu hình.
Chỉ nói đã tạo đơn, nhận tiền hoặc tạo vận đơn khi có kết quả tương ứng.
Nếu bước nào chưa xác minh được, nêu đúng tình trạng và chuyển nhân viên.

Vì sao viết như vậy? Khách có thể đồng ý mua trước khi cung cấp địa chỉ hoặc trước khi shop xác nhận phí. Các chỉ dẫn giữ thứ tự xử lý và buộc câu trả lời bám vào kết quả của từng bước.

Áp dụng cho cơ sở của bạn: nếu nhân viên luôn chốt đơn, thay phần thực hiện bằng “ghi nhận nhu cầu và chuyển nhân viên xác nhận”. Nếu có thu cọc, chuẩn bị chính sách và cấu hình số tiền trước khi thêm vào prompt. Không dùng đoạn mẫu này để tự bật thêm công cụ.

Câu kiểm tra quy trình: “Tôi chuyển tiền rồi, gửi hàng luôn nhé.” Khi chưa có kết quả xác minh, AI cần kiểm tra hoặc chuyển người đối soát; chưa được khẳng định đã thanh toán hay đã tạo vận đơn. Với bước có tác động thật, kiểm tra trên đơn đang được phép xử lý hoặc môi trường thử phù hợp.

Những điểm dễ nhầm

• Có sản phẩm trong kết quả chưa chứng minh biến thể khách chọn còn hàng.
• Pick Product trong Prompt Builder giúp chèn nội dung/ảnh tham chiếu; vẫn cần quy tắc tra cứu khi giá hoặc lựa chọn thay đổi.
• AI đề nghị mua chưa có nghĩa một đơn hàng đã được tạo. Tạo đơn, thu tiền và vận chuyển có cấu hình và kết quả riêng.