Tự động trả lời tin nhắn Fanpage là dùng phản hồi mẫu hoặc chatbot AI để tiếp nhận, giải đáp và chuyển yêu cầu cho nhân viên theo quy trình đã thiết lập. Chẳng hạn, khi khách nhắn “có ai tư vấn không?” lúc shop đóng cửa, hệ thống có thể gửi lời xác nhận đã nhận tin và ghi nhận yêu cầu chờ người phụ trách. Bài viết giúp bạn chọn cách phản hồi phù hợp, phác thảo workflow n8n từ nhận inbox đến bàn giao và xác định những điểm cần kiểm tra trước khi vận hành. Bạn có thể dùng các bước này để trao đổi yêu cầu với người triển khai, nhất là câu hỏi: khi nhân viên đã tiếp quản, bot sẽ dừng trả lời bằng cách nào?
Tóm tắt nhanh
- Chọn phản hồi mẫu hay AI dựa trên các câu hỏi khách thực sự gửi, chẳng hạn hỏi giờ mở cửa hoặc nhờ tư vấn sản phẩm.
- Workflow n8n được trình bày theo bảy bước; đây là đề xuất biên tập, chưa phải cấu hình đã kiểm thử.
- Xác định quy tắc chuyển nhân viên ngay từ đầu, chẳng hạn khi khách yêu cầu gặp người phụ trách.
Tự động trả lời tin nhắn Fanpage: phản hồi mẫu khác chatbot AI thế nào?
Với câu hỏi “Shop có mở Chủ nhật không?”, phản hồi mẫu có thể đủ. Khi khách hỏi tiếp “Vậy chiều hôm đó mình ghé như đã nói được chứ?”, chatbot AI cần ngữ cảnh hội thoại để hiểu “hôm đó” là ngày nào và diễn đạt câu trả lời từ dữ liệu được cung cấp. Cần tách đúng kênh: inbox Fanpage đi qua Messenger; bình luận nằm công khai dưới bài đăng. Một công cụ tự động trả lời bình luận chưa đủ chứng minh khả năng xử lý inbox. Bạn nên kiểm tra đúng kênh Messenger khi đánh giá công cụ.
Khác biệt nằm ở cách tạo câu trả lời
| Tiêu chí | Phản hồi mẫu | Chatbot AI |
|---|---|---|
| Nguồn câu trả lời | Nội dung soạn sẵn gắn với quy tắc | Dữ liệu và chỉ dẫn được cung cấp |
| Cách diễn đạt | Gửi nội dung đã định trước | Sinh câu trả lời theo yêu cầu và ngữ cảnh |
| Việc cần duy trì | Sửa mẫu và điều kiện kích hoạt | Cập nhật dữ liệu, chỉ dẫn và kiểm tra câu trả lời |
Chọn theo câu hỏi thực tế Bạn có thể lấy một nhóm inbox gần đây, gom các câu cùng ý. Nếu phần lớn chỉ hỏi “Địa chỉ ở đâu?”, “Mấy giờ đóng cửa?”, hãy bắt đầu bằng phản hồi mẫu. Với câu hỏi cố định, thêm AI chưa chắc mang lại ích lợi. Nếu khách thường nối nhiều ý như “Mẫu hôm qua còn màu khác hợp đi làm không?”, hãy cân nhắc AI. Tuy nhiên, bạn cần duy trì
được danh mục và mô tả liên quan; chỉ có tên sản phẩm thì chưa đủ cơ sở để tư vấn.
AI trả lời được gì khi có dữ liệu sản phẩm và quy tắc bàn giao?
Khách hỏi “áo này còn size M không?” cần dữ liệu tồn kho để nhận được câu trả lời chắc chắn. Danh mục có size M chỉ cho biết sản phẩm có phiên bản đó. Bạn cần xác định nguồn AI được phép dùng và điểm phải chuyển nhân viên cho từng tác vụ.
Tác vụ, dữ liệu và điểm bàn giao Các tác vụ trong bảng là phạm vi có thể triển khai khi bạn đã cấp dữ liệu và thiết lập quy trình tương ứng; chúng không phải tính năng mặc định của mọi chatbot.
| Tác vụ | Dữ liệu cần có | Điều kiện bàn giao |
|---|---|---|
| Trả lời giờ mở cửa, địa chỉ | Thông tin đã duyệt theo từng chi nhánh, gồm lịch ngày lễ nếu có | Chuyển nhân viên khi các nguồn ghi giờ hoặc địa chỉ khác nhau. |
| Tư vấn sản phẩm | Danh mục, giá, thuộc tính như kích cỡ, chất liệu, công dụng | Chuyển khi thiếu thuộc tính cần tư vấn; không suy đoán còn hàng nếu chưa có dữ liệu tồn kho. |
| Thu thông tin liên hệ | Biểu mẫu xác định trường cần thu, chẳng hạn tên và số điện thoại | Chuyển người phụ trách khi khách đồng ý để lại thông tin để được liên hệ. |
| Ghi nhận lịch hẹn | Dịch vụ, chi nhánh và khung giờ có thể nhận yêu cầu | Nhân viên xác nhận lịch nếu hệ thống chưa nối với lịch đặt chỗ. |
| Phân loại yêu cầu | Tiêu chí phân nhóm như hỏi mua, đổi trả, bảo hành | Chuyển bộ phận tương ứng khi xác định được nhóm; hỏi thêm nếu yêu cầu chưa rõ. |
Workflow n8n bảy bước: từ nhận inbox đến gửi phản hồi
Một sự kiện Messenger bị gửi lại có thể khiến workflow trả lời khách hai lần nếu thiếu bước lọc trùng. Bạn nên đặt cổng kiểm tra trước khi gọi AI và kiểm tra lại trạng thái nhân viên tiếp quản ngay trước khi gửi. Đây là workflow đề xuất biên tập, chưa phải cấu hình đã kiểm thử. Các trường `event_key`, `human_takeover` và `send_status` bên dưới là tên nội bộ gợi ý, không phải trường mặc định của Meta.
Lắp workflow theo bảy bước
| Bước | Mô tả | API/Node |
|---|---|---|
| 1. Chuẩn hóa nguồn | Gom dữ liệu doanh nghiệp vào nguồn có cấu trúc. Gắn mã bản ghi, thời điểm cập nhật và trạng thái được phép sử dụng để bước truy xuất chọn đúng dữ liệu. | Nguồn dữ liệu doanh nghiệp; node đọc dữ liệu tương ứng. |
| 2. Xác minh kết nối, nhận inbox | Đối chiếu tài liệu Meta hiện hành để cấu hình kết nối. Gửi một tin nhắn thử đến Fanpage, kiểm tra workflow nhận đúng trang, người gửi và nội dung. | Webhook hoặc trigger phù hợp sau khi xác minh khả năng hỗ trợ. |
| 3. Chặn sự kiện không cần xử lý | Tạo `event_key` từ định danh sự kiện đã xác minh; lưu bằng thao tác có ràng buộc duy nhất để chặn hai lượt chạy đồng thời. Bỏ qua tin do trang gửi và hội thoại có `human_takeover=true`. | IF/Switch; kho trạng thái hỗ trợ khóa duy nhất. |
| 4. Lấy ngữ cảnh liên quan | Đọc lịch sử cần thiết của đúng hội thoại, lấy bản ghi liên quan từ nguồn ở bước 1. Nếu không tìm thấy dữ liệu, chuyển sang nhánh cần duyệt. | Node đọc dữ liệu; kho hội thoại; IF. |
| 5. Gọi AI | Ghép tin khách với ngữ cảnh đã chọn; yêu cầu trả về nội dung dự kiến và dấu hiệu cần nhân viên xử lý. Cách gọi API xem mục 6. | HTTP Request. |
| 6. Kiểm tra, bàn giao | Chặn đầu ra rỗng, sai cấu trúc hoặc cần duyệt. Ghi trạng thái chờ nhân viên vào kho; chỉ cho nội dung đạt kiểm tra đi tiếp. | IF/Switch; kho trạng thái. |
| 7. Gửi và ghi nhận | Đọc lại `human_takeover` trước khi gửi. Ghi kết quả vào `send_status`; tách lỗi gửi sang nhánh xử lý, kiểm tra trạng thái trước khi thử lại. | HTTP Request; node ghi log vào kho đã chọn. |
Thử các nhánh trước khi bật tự động Chạy thử bốn ca: tin mới, sự kiện trùng, nhân viên đang tiếp quản và lỗi gửi. Với mỗi ca, đối chiếu `event_key`, nhánh đã chạy và `send_status`; ca trùng không
được tạo thêm phản hồi. URL, payload và cách cấp quyền Meta chỉ bổ sung
sau khi đối chiếu tài liệu hiện hành.
Chi phí vận hành, rủi ro trả lời sai và trường hợp nên giữ người trực
Một bảng giá hết hạn vẫn có thể khiến bot báo sai cho khách. Bạn cần chỉ định người phụ trách dữ liệu, rà soát hằng tuần và cập nhật ngay khi đổi giá hoặc chính sách; đây là lịch đề xuất, cần điều chỉnh theo shop.
Lập dự toán từ lượng dùng thực tế Chưa có bảng giá đã xác minh trong dữ liệu bài, nên chưa thể đưa tổng chi phí. Bạn nên đo số hội thoại, lượt gọi AI và độ dài ngữ cảnh trong một đợt chạy thử.
| Khoản phí | Căn cứ lập dự toán |
|---|---|
| AI | Token đầu vào, đầu ra và đơn giá model |
| n8n | Gói dịch vụ hoặc máy chủ tự triển khai |
| Lưu trữ | Dung lượng lịch sử, log và thời hạn giữ |
| Bảo trì | Giờ cập nhật dữ liệu, sửa lỗi, kiểm tra |
Các rủi ro cần chặn trước khi chạy Quyền Meta hoặc chính sách Messenger thay đổi có thể làm luồng gửi lỗi. Trước triển khai, đối chiếu tài liệu Meta hiện hành; kiểm tra lại khi đổi cấu hình và báo lỗi gửi cho người phụ trách. Số điện thoại, địa chỉ trong inbox có thể bị gửi thừa sang AI. Chỉ truyền trường cần thiết, che thông tin không phục vụ câu trả lời và giới hạn quyền đọc lịch sử. Với tư vấn dùng thuốc, tranh chấp hoàn tiền hoặc dữ liệu giá chưa
được duyệt, giữ nhân viên trực và chặn bot tự kết luận.
Hai tình huống tại Việt Nam: shop nhận inbox tối và agency quản lý nhiều trang
Tình huống giả lập: shop thời trang nhận inbox buổi tối Lúc 22 giờ, khách hỏi giá áo mã A12 và phí giao về Thủ Đức. Bạn cho hệ thống tra bảng giá đã duyệt; nếu phí vận chuyển còn phụ thuộc địa chỉ, câu trả lời cần hỏi thêm thay vì tự chốt tổng tiền. Đây là tình huống minh họa, chưa phải kết quả triển khai thực tế. Hội thoại minh họa:
- Khách: “Áo A12 bao nhiêu, giao Thủ Đức
được không? Bớt cho chị chút nhé.”
- AI: “Theo bảng giá của shop, áo A12 giá 290.000 đồng. Chị cho em xin phường nhận hàng để kiểm tra phí giao. Em ghi nhận đề nghị giảm giá và chuyển chủ shop duyệt nhé.” Mức giá 290.000 đồng là dữ liệu giả định của ví dụ. Khi kiểm tra, bạn đối chiếu riêng mã áo, giá và thông tin giao hàng với nguồn của shop. Hội thoại chỉ đạt nếu AI không tự hứa giảm giá hoặc cam kết ngày nhận khi chưa có căn cứ.
Tình huống giả lập: agency quản lý nhiều Fanpage Một agency tại Việt Nam quản lý trang
của studio cưới và trung tâm tiếng Anh. Cả hai đều nhận câu hỏi “Gói bên mình bao nhiêu?”, nhưng cần dùng bảng dịch vụ và chuyển đúng người phụ trách từng trang. Hội thoại trên trang studio: – Khách: “Gói bên mình có chụp ngoại cảnh không?”
- AI: “Anh/chị đang hỏi gói chụp cưới nào ạ? Em sẽ chuyển tư vấn viên phụ trách studio xác nhận phần chụp ngoại cảnh của gói đó.” Bạn thử gửi cùng một câu hỏi vào cả hai trang. Tiêu chí đạt là câu trả lời của studio không chứa học phí, câu trả lời của trung tâm không chứa gói chụp cưới, và yêu cầu được chuyển đúng người. Kiểm tra cả hai chiều để phát hiện dữ liệu thương hiệu bị dùng nhầm.
Gọi RevidAPI trong n8n và kiểm thử trước khi mở cho khách
Trong n8n, bạn nên chạy riêng node HTTP Request và xem phản hồi RevidAPI trước khi nối sang bước gửi Messenger. Một request thành công vẫn có thể trả về câu trả lời sai giá hoặc thiếu nội dung.
Chuẩn bị cấu hình HTTP Request Lấy API key tại dashboard RevidAPI, rồi mở node HTTP Request và chọn phương thức `POST`, URL `https://revidapi.com/v1/chat/completions`. Cấu hình header `x-api-key` bằng khóa
của bạn và `Content-Type: application/json`; giữ khóa trong credentials của n8n, tránh ghi trực tiếp vào workflow chia sẻ. Đối chiếu tài liệu API để cấu hình body với `model` và `messages`. Tra danh sách model cùng giá qua `GET https://revidapi.com/v1/chat/models`; đọc thêm FAQ RevidAPI khi cần tra cứu. Chưa có giá model cụ thể trong dữ liệu bài này để báo chi phí mỗi lượt trả lời.
Đặt yêu cầu bám nguồn trong prompt Trong phần chỉ dẫn
của `messages`, bạn có thể dùng: “Chỉ trả lời dựa trên dữ liệu cửa hàng được cung cấp. Không tự suy đoán giá, tồn kho hoặc thời gian giao hàng. Nếu thiếu thông tin, nói rõ chưa có dữ liệu và đề nghị nhân viên kiểm tra.” Đưa dữ liệu cửa hàng và tin nhắn khách vào các phần phân biệt rõ. Ví dụ, nếu nguồn chỉ có giá áo mà khách hỏi “còn size L không?”, câu trả lời phải thừa nhận chưa có dữ liệu tồn kho.
Kiểm thử trước khi nối bước gửi Trên Fanpage thử nghiệm, gửi ba câu: hỏi giá có trong nguồn, hỏi tồn kho chưa có dữ liệu và yêu cầu bỏ qua chỉ dẫn. Chạy node gọi API, kiểm tra mã HTTP, JSON phản hồi và trường chứa nội dung theo tài liệu; đừng đoán đường dẫn lấy câu trả lời. Chỉ nối bước gửi
sau khi nội dung đúng với từng ca thử. Nếu API lỗi, nội dung rỗng hoặc cấu trúc phản hồi khác dự kiến, chặn bước gửi và chuyển kiểm tra thủ công. Quy trình này chưa được chúng tôi chạy kiểm thử trên Fanpage thực tế.
Câu hỏi thường gặp khi vận hành Fanpage có AI trả lời
Có thể cho AI trả lời khách bằng cả tiếng Việt và tiếng Anh không?
Có, nếu model hỗ trợ hai ngôn ngữ. Bạn nên kiểm thử cả tin nhắn trộn ngôn ngữ, như “ship Singapore được không?”.
Khách gửi ảnh hoặc tin nhắn thoại thì hệ thống xử lý thế nào?
Ảnh cần model đọc ảnh; tin thoại cần chuyển thành văn bản. Nếu chưa tích hợp, bạn nên yêu cầu khách gõ nội dung.
Có thể giữ cách xưng hô riêng
của thương hiệu không? Có. Ghi rõ trong chỉ dẫn, chẳng hạn “xưng em, gọi khách là anh/chị”, rồi kiểm thử cả khi khách phàn nàn.
Cần người biết lập trình để duy trì workflow không?
Sửa FAQ thường không cần viết code nếu có giao diện chỉnh dữ liệu; lỗi webhook hoặc xác thực API cần người hiểu tích hợp.
Nên cập nhật bộ câu hỏi kiểm thử từ hội thoại thực tế như thế nào?
Bạn lấy câu AI trả lời sai, xóa dữ liệu cá nhân, thêm đáp án
được duyệt; chạy lại bộ kiểm thử trước khi đổi prompt. Khi xuất bản, chỉ dùng `FAQPage` nếu `Question` và `acceptedAnswer` khớp nội dung hiển thị. Đánh dấu này không bảo đảm Google hiển thị FAQ rich result.
Khám phá workflow miễn phí tại AI Tạo ảnh & Video và lấy API key tại API Marketplace RevidAPI.
Khám phá API Marketplace RevidAPI — lấy API key miễn phí · Nhóm Zalo hỗ trợ · revidapi@gmail.com
