Kiến trúc Sale Chat: một lõi, nhiều kênh, nhiều thương hiệu
Một chatbot cho mỗi kênh nghĩa là ba nơi để sửa giá và ba bộ dữ liệu khách rời nhau. Bài này giải thích kiến trúc chatbot bán hàng một lõi, nhiều kênh: tin chuẩn, 4 tầng, 10 làn hành trình, cách gom tin nhắn dồn, đọc ảnh và tin thoại, chạy nhiều thương hiệu bằng một bảng cấu hình, và các bảng dữ liệu cần có. Dữ kiện đối chiếu tài liệu gốc tại ngày 26/10/2026.
Ba kênh, ba chatbot, ba bảng giá
Chị Mai mở spa, nhận khách qua Fanpage, Zalo OA và khung chat trên website. Mỗi kênh một công cụ trả lời: Fanpage dùng chatbot nút bấm, Zalo OA do lễ tân trả lời tay, website gắn một khung chat khác. Đầu tháng spa đổi giá liệu trình. Fanpage sửa xong, website quên sửa. Một khách hỏi cả hai kênh, nhận hai mức giá, rồi hỏi lại "rốt cuộc giá nào đúng?". Dữ liệu khách nằm ở ba nơi, không ai biết đó là cùng một người. (Tình huống minh hoạ.)
Đây là bài toán kiến trúc, không phải bài toán công cụ. Bài trước, Sale Chat Automation là gì, đã giới thiệu 4 tầng ở mức tổng quan. Bài này đi sâu vào cách sắp xếp các phần để một hệ thống chatbot đa kênh nói cùng một giọng, dùng cùng một bảng giá và chạy được cho nhiều thương hiệu.
Kiến trúc một lõi, nhiều kênh là gì?
Kiến trúc một lõi, nhiều kênh là cách dựng chatbot bán hàng trong đó mỗi kênh chỉ lo nhận và gửi tin, mọi tin được đổi về một "tin chuẩn" giống nhau, rồi đi qua một bộ não tư vấn dùng chung cho mọi kênh và mọi thương hiệu.
Mấu chốt nằm ở tin chuẩn. Messenger, Zalo OA và khung chat website gửi dữ liệu theo khuôn khác nhau. Luồng kênh có nhiệm vụ dịch tin về một khuôn chung trước khi chuyển vào lõi. Từ đó trở đi, lõi không cần biết tin đến từ đâu.
| Trường trong tin chuẩn | Ý nghĩa | Vì sao cần |
|---|---|---|
| Kênh | Messenger, Zalo OA, chat website, form | Để gửi trả lời đúng đường và áp đúng luật của kênh |
| Thương hiệu | Tin thuộc thương hiệu nào | Để nạp đúng cấu hình, kiến thức, nhóm báo Sale |
| Mã khách | Mã người gửi trên kênh đó | Để tìm hồ sơ, lịch sử hội thoại |
| Mã tin | Mã riêng của từng tin | Để bỏ tin trùng khi nền tảng gửi lại |
| Loại tin | Chữ, ảnh, tin thoại, tệp | Để đọc ảnh, chép lời tin thoại trước khi trả lời |
| Nội dung, thời điểm | Chữ khách gõ, lúc gửi | Để gom tin dồn và tính khung giờ chăm sóc |
Tên trường ở bảng trên là minh hoạ. Mỗi đội tự đặt tên, miễn là mọi kênh dùng chung một khuôn. Lợi ích đầu tiên thấy ngay: bạn có thể dựng và thử lõi qua khung chat website trước, khi chưa nối Fanpage hay Zalo OA.
Bốn tầng và việc của từng tầng
Tách thành tầng giúp bạn sửa một phần mà không đụng phần khác, và biết ngay khi một phần hỏng thì ảnh hưởng tới đâu.
| Tầng | Thành phần chính | Nếu tầng này trục trặc |
|---|---|---|
| Kênh | Một luồng cho mỗi kênh: Messenger, Zalo OA, chat website, form. Nhận tin, đổi về tin chuẩn, gửi trả lời | Chỉ kênh đó bị ảnh hưởng; các kênh khác vẫn chạy |
| Lõi | Điều phối, gom tin, đọc ảnh và ghi âm, lấy tên khách, bộ não tư vấn, tra kiến thức, tra sản phẩm, gửi tin đa kênh, hồ sơ khách chạy ngầm, báo Sale | Mọi kênh bị ảnh hưởng: cần mô hình AI dự phòng, câu chờ lịch sự và cảnh báo |
| Chăm sóc | Xếp lịch, bộ chạy lịch, gửi lượt chăm sóc, bản tin Sale buổi sáng, nhắc lịch, nút bấm cho Sale, nhắc Sale | Tin chăm sóc bị kẹt hoặc gửi sai giờ: cần cảnh báo "tin kẹt" |
| Vận hành | Báo lỗi, báo cáo cuối ngày, tự học từ hội thoại, cảnh báo khách chờ, kiểm tra sức khoẻ kiến thức | Hệ thống vẫn chạy nhưng không ai biết khi nó bắt đầu sai |
Tầng lõi là nơi cần đầu tư kỹ nhất vì mọi kênh đi qua nó. Hai phần quan trọng trong lõi có bài riêng: kho kiến thức cho trợ lý và lớp bảo vệ trước khi gửi.
10 làn hành trình: khách đi qua những đâu
Nếu tầng là cách chia theo chức năng, thì làn là cách chia theo hành trình của khách. Mỗi làn gom các workflow phục vụ một chặng. Khi có lỗi, nhìn tên làn là biết khách đang kẹt ở đâu và ai cần xử lý.
| Làn | Việc chính | Chạy khi nào | Đọc thêm |
|---|---|---|---|
| H1 Tiếp nhận đa kênh | Nhận tin, trả lời nhanh cho nền tảng, đổi về tin chuẩn | Mỗi tin khách gửi | Messenger, Zalo OA |
| H2 Nhận diện và gom tin | Nhận ra khách mới hay cũ, lấy tên, gom tin nhắn dồn, bỏ tin trùng | Ngay sau H1 | Mục dưới |
| H3 Phân loại và hồ sơ | Xác định sản phẩm, ý định, luồng; cập nhật hồ sơ khách chạy ngầm | Mỗi lượt | Phân loại khách |
| H4 Tra kiến thức và trả lời | Nạp kiến thức liên quan, AI soạn, lớp bảo vệ kiểm tra, gửi | Mỗi lượt cần trả lời | Kho kiến thức |
| H5 Khai thác, xin số, chốt | Dẫn dắt theo 6 bước, xin số khi có tín hiệu mua, báo Sale | Khi khách đủ điều kiện lên bước | Kịch bản 6 bước |
| H6 Xếp lịch chăm sóc | Đặt lịch bám đuổi; khách nhắn lại thì huỷ lịch cũ, xếp lịch mới | Sau mỗi lượt | Chăm sóc tự động |
| H7 Bám đuổi 24 giờ | Gửi các chạm trong cửa sổ cho phép, kiểm tra lại trước khi gửi | Khi khách im lặng | Chăm sóc tự động |
| H8 Nuôi dưỡng dài hạn | Bản tin buổi sáng cho Sale nhắn hoặc gọi tay | Ngoài cửa sổ nền tảng | Chăm sóc tự động |
| H9 Sau mua và bán thêm | Nhắc chuẩn bị, hỏi han, gợi ý nâng cấp, xin giới thiệu | Sau khi Sale bấm chốt | Phối hợp Sale |
| VH Vận hành và giám sát | Báo lỗi, khách chờ, báo cáo ngày, tự học, sức khoẻ kiến thức | Liên tục và định kỳ | Đo lường, kiểm thử |
Bạn không cần dựng đủ 10 làn ngay từ đầu. Bản tối thiểu để chạy thật là H1 đến H5. Các làn chăm sóc và vận hành thêm dần khi lõi đã ổn.
Gom tin nhắn dồn, đọc ảnh và tin thoại
Người Việt nhắn tin hay tách câu: "Shop ơi", "áo khoác này", "còn màu đen không", kèm một tấm ảnh. Nếu trả lời từng tin, khách nhận bốn câu rời rạc, có câu còn trả lời sai vì chưa đọc tin sau. Cách làm của hệ thống:
- Tin mở đầu trả lời ngay. Thường là lời chào, đi lối tắt, không chờ.
- Tin thứ hai tới gần nhau: chờ khoảng 2 giây xem khách còn gõ tiếp không.
- Khách nhắn dồn: chờ khoảng 3 giây tính từ tin mới nhất. Mỗi tin mới tới lại tính lại thời gian chờ.
- Hết thời gian chờ, chỉ trả lời một lần. Lượt của tin cuối được xử lý, mang theo toàn bộ các tin đã gom. Các lượt của tin trước dừng lại.
- Bỏ tin trùng mã. Meta gửi lại thông báo khi máy chủ nhận lỗi và yêu cầu phía nhận tự chống trùng. Mỗi tin Messenger có mã riêng, nên tin trùng mã thì bỏ qua.
Ảnh và tin thoại
Sự kiện tin nhắn của Messenger có thể kèm tệp đính kèm với các loại như ảnh, âm thanh, video, tệp. Hệ thống của Aduca đọc ảnh trước khi trả lời: loại ảnh gì, có chữ hay con số quan trọng nào, khách muốn hỏi điều gì. Tin thoại tiếng Việt được chép lời thành chữ. Nếu không đọc được, trợ lý xin khách mô tả ngắn thay vì đoán.
Nguồn: Meta – Webhooks (gửi lại, chống trùng) · Meta – Webhook messages (mid, attachments)
Trả lời như người nhắn: chia tin và tín hiệu đang soạn
Một đoạn trả lời dài cả màn hình điện thoại khiến khách ngại đọc. Hệ thống chia câu trả lời thành tối đa 3 tin ngắn và dùng các tín hiệu mà Messenger hỗ trợ để khách thấy đang có người lo cho mình.
| Kỹ thuật | Mục đích | Lưu ý khi dựng |
|---|---|---|
| Chia tối đa 3 tin | Dễ đọc trên điện thoại, giống người thật nhắn | Không cắt giữa một con số, một dòng giá |
| Đánh dấu đã xem | Khách biết tin đã được nhận | Meta khuyên gửi ngay khi nhận tin để khách không thấy bị lờ |
| Hiện "đang soạn" | Giảm cảm giác chờ trong lúc gom tin, AI soạn | Bật khi sắp trả lời, tắt khi gửi xong |
| Câu chờ lịch sự | Khi AI chậm hoặc lỗi | Bot tự động phải phản hồi trong 30 giây; nếu AI chưa xong, gửi câu chờ và báo Sale |
Câu chờ và cách chuyển sang mô hình dự phòng khi AI lỗi thuộc lớp bảo vệ, xem Lớp bảo vệ trước khi gửi.
Nguồn: Meta – Sender actions · Meta – Policy overview (30 giây)
Đa thương hiệu bằng một bảng cấu hình
Nhiều chủ doanh nghiệp có hơn một thương hiệu: một spa và một dòng mỹ phẩm, một shop bán lẻ và một kênh bán sỉ. Dựng hai hệ thống là gấp đôi công sửa. Cách gọn hơn: mọi thứ riêng của thương hiệu nằm trong một dòng của bảng cấu hình, lõi đọc dòng đó theo trường "thương hiệu" trong tin chuẩn.
| Cấu hình riêng | Ví dụ | Vì sao để ở bảng thay vì trong workflow |
|---|---|---|
| Xưng hô, giọng văn | Anh/chị – em; hoặc bạn – mình | Đổi giọng không cần sửa lời nhắc trong lõi |
| Giờ được nhắn chủ động | 08:00–22:00 | Mỗi ngành có giờ phù hợp khác nhau |
| Mốc bám đuổi | 30 phút, 3 giờ, 6 giờ… | Chu kỳ mua mỗi sản phẩm khác nhau |
| Thư mục kiến thức | Thư mục ghi chú riêng của thương hiệu | Không lẫn giá, chính sách giữa hai thương hiệu |
| Từ khoá sản phẩm, lối tắt | Tên sản phẩm, câu cố định | Phân loại và trả lời nhanh theo đúng danh mục |
| Nhóm báo Sale | Nhóm chat của đội Sale thương hiệu đó | Khách nóng tới đúng người |
thuong_hieu: <mã thương hiệu>
xung_ho: <vd: anh/chị – em>
gio_duoc_nhan: 08:00-22:00 # trợ lý chỉ gửi tin chủ động trong khung này
moc_bam_duoi: 30 phút, 3 giờ, 6 giờ, 12 giờ, 20 giờ
thu_muc_kien_thuc: <thư mục ghi chú của thương hiệu>
tu_khoa_san_pham: <sản phẩm A: từ khoá 1, từ khoá 2>
loi_tat: <câu cố định: chào, hỏi địa chỉ, cảm ơn>
nhom_bao_sale: <nhóm nhận báo khách nóng>
kenh: messenger, zalo_oa, web_chatVới cách này, thêm thương hiệu mới gồm ba việc: thêm một dòng cấu hình, tạo thư mục kiến thức, nối kênh của thương hiệu đó. Lõi giữ nguyên. Cách tổ chức thư mục kiến thức cho từng thương hiệu: Chatbot n8n đọc Second Brain.
Dữ liệu cần có: các bảng dùng chung
Trợ lý chỉ thông minh khi nhớ được khách. Phần "nhớ" nằm ở các bảng dữ liệu. Dưới đây là các bảng chính, đặt tên chung để dễ hiểu; bạn có thể gộp hoặc tách tuỳ quy mô.
| Bảng | Lưu gì | Ai thay đổi |
|---|---|---|
| Cấu hình thương hiệu | Xưng hô, giờ nhắn, mốc bám đuổi, thư mục kiến thức, nhóm báo Sale | Chủ doanh nghiệp, người kỹ thuật |
| Lượt hội thoại | Từng lượt hỏi và trả lời, thời điểm, kênh | Hệ thống tự ghi |
| Hồ sơ khách | Bước bán hàng, độ nóng, nhu cầu, câu đã hỏi, bước tiếp theo | Hệ thống cập nhật ngầm |
| Khách hàng | Tên, kênh, số điện thoại khi khách tự cho | Hệ thống, Sale |
| Tin chờ gom | Các tin đang chờ để trả lời một lần | Hệ thống tự ghi và xoá |
| Tiếp quản | Khách nào đang do nhân viên trả lời, tới lúc nào | Hệ thống, khi nhân viên vào chat |
| Lịch chăm sóc | Lượt nhắn đã xếp, trạng thái đã gửi hay huỷ | Hệ thống |
| Sản phẩm | Danh mục, giá, lịch, điều kiện | Chủ doanh nghiệp |
| Đăng ký, đơn hàng | Khách đã đăng ký hoặc đã mua | Sale, hệ thống |
| CRM lead | Khách tiềm năng đã để số, trạng thái gọi | Sale bấm nút |
| Nhật ký báo Sale | Đã báo ai, lúc nào, Sale xử lý chưa | Hệ thống |
Nếu dựng trên n8n, Data tables cho phép lưu bảng ngay trong n8n mà không cần cơ sở dữ liệu ngoài. Tài liệu n8n nói rõ đây là nơi lưu dữ liệu nhẹ đến vừa: mặc định mọi bảng trong một máy n8n dùng chung giới hạn 200 MiB (bản tự cài đổi được), khi chạm giới hạn thì thao tác ghi sẽ lỗi. Khối Code không đọc trực tiếp bảng. Khi dữ liệu lớn hơn, cân nhắc cơ sở dữ liệu riêng, hoặc dùng Google Sheets cho phần đội Sale cần xem: Google Sheets làm CRM.
Nguồn: n8n – Data tables
Chọn công cụ: các khối n8n tương ứng
Kiến trúc trên không gắn với một phần mềm. Aduca dựng trên n8n vì mỗi phần đều có khối tương ứng, và bản tự cài giữ dữ liệu khách trên máy chủ của mình. Bảng dưới để người không làm IT hình dung "phần nào làm bằng gì".
| Phần trong kiến trúc | Khối n8n | Ghi chú từ tài liệu n8n |
|---|---|---|
| Nhận tin từ Messenger, Zalo OA | Webhook | Có Test URL khi dựng và Production URL khi publish; lượt chạy thật xem ở tab Executions |
| Khung chat website | Chat Trigger | Chọn khung chat n8n dựng sẵn (Hosted) hoặc tự làm giao diện gọi vào (Embedded) |
| Chia lõi thành phần nhỏ | Execute Sub-workflow | Gọi một workflow khác, truyền dữ liệu vào và nhận kết quả ra |
| Bộ não tư vấn | AI Agent | Nối một chat model và ít nhất một công cụ (tool); Agent tự chọn công cụ cần gọi |
| Bảng dữ liệu | Data tables | Lưu trạng thái giữa các workflow trong cùng project |
Cách nối từng phần đã có trong thư mục n8n: AI Agent trong n8n, chatbot Facebook Messenger bằng n8n, kết nối Zalo OA với n8n, và giám sát lỗi, sao lưu, phiên bản.
Nguồn: n8n – Webhook · n8n – Chat Trigger · n8n – Execute Sub-workflow · n8n – AI Agent
Aduca áp dụng kiến trúc này thế nào?
Hệ thống Sale Chat của Aduca chạy đúng kiến trúc trên. Tại ngày 12/10/2026: 3 kênh vào (Messenger, Zalo OA, chat website), 10 làn hành trình, 32 workflow, 12 bảng dữ liệu. Mọi cấu hình riêng nằm trong bảng cấu hình thương hiệu, nhờ vậy hệ thống đã được nhân bản sang một thương hiệu thứ hai chỉ bằng cấu hình, không viết lại lõi. Thêm kênh mới chỉ thêm một luồng kênh.
| Quyết định kiến trúc | Lý do Aduca chọn |
|---|---|
| Thử lõi qua chat website trước | Kiểm tra kịch bản, kiến thức khi chưa đụng tới khách trên Fanpage, Zalo OA |
| Gom tin 2–3 giây | Câu trả lời đúng ngữ cảnh, ít lượt gọi AI hơn |
| Hồ sơ khách cập nhật ngầm | Không làm chậm câu trả lời của lượt hiện tại |
| Bảng cấu hình thương hiệu | Nhân bản thương hiệu mới bằng dữ liệu, không bằng code |
| Tầng vận hành riêng | Lỗi, khách chờ, tin kẹt đều có cảnh báo, không phụ thuộc người nhớ kiểm tra |
Tự đánh giá kiến trúc của bạn
- Mọi kênh đổi về một tin chuẩn trước khi vào lõi
- Giá, lịch, chính sách chỉ nằm ở một nơi, mọi kênh cùng đọc
- Có chống trùng theo mã tin và gom tin nhắn dồn
- Cấu hình riêng của thương hiệu nằm trong bảng, không rải trong workflow
- Có cảnh báo lỗi, khách chờ, tin kẹt gửi về một nhóm có người trực
Muốn Aduca dựng kiến trúc này theo kênh, sản phẩm và bảng giá của bạn, xem Hệ thống Sale Chat tự động. Muốn đội ngũ tự dựng, khóa Aduca AI Business System có phần thực hành Sale Chat trên n8n. Bài tiếp theo: Kịch bản chatbot bán hàng 6 bước.
Đọc tiếp: Kịch bản dẫn dắt 6 bước →
Câu hỏi thường gặp
Kiến trúc chatbot bán hàng "một lõi, nhiều kênh" là gì?
Là cách dựng trong đó mỗi kênh (Messenger, Zalo OA, chat website) chỉ lo nhận và gửi tin. Mọi tin được đổi về một dạng chung rồi đi qua một bộ não tư vấn dùng chung. Sửa giá, kịch bản ở một chỗ thì mọi kênh cùng dùng.
Có nên làm mỗi kênh một chatbot riêng không?
Làm riêng thì dựng nhanh lúc đầu nhưng về sau phải sửa nhiều chỗ, dữ liệu khách nằm rải rác và mỗi kênh nói một kiểu. Khi đã có từ hai kênh trở lên, một lõi dùng chung dễ quản lý hơn.
"Tin chuẩn" là gì?
Là một khuôn dữ liệu giống nhau cho mọi tin vào: kênh nào, thương hiệu nào, mã khách, mã tin, loại tin, nội dung, thời điểm. Lõi chỉ làm việc với khuôn này nên không phải biết tin đến từ đâu.
Vì sao phải gom tin nhắn dồn?
Khách hay nhắn nhiều tin ngắn liên tiếp. Trả lời từng tin sẽ rời rạc, lặp ý và tốn lượt gọi AI. Hệ thống chờ vài giây, gom cả cụm rồi trả lời một lần.
Một hệ thống chạy được cho nhiều thương hiệu không?
Được, nếu mọi thứ riêng của thương hiệu (xưng hô, giờ nhắn, mốc bám đuổi, thư mục kiến thức, nhóm báo Sale) nằm trong một bảng cấu hình. Thêm thương hiệu là thêm một dòng cấu hình và một bộ kiến thức, không viết lại lõi.
Có bắt buộc dùng n8n không?
Không. Kiến trúc này áp dụng được với nhiều công cụ. Aduca chọn n8n vì có sẵn các khối nhận webhook, khung chat, chia workflow con, AI Agent và bảng dữ liệu, lại tự cài được để giữ dữ liệu khách trong tay.
Tài liệu liên quan
- Sale Chat · AI AgentSale Chat Automation là gì? Hệ thống chốt sale qua inbox bằng AISale Chat Automation là gì: hệ thống chatbot bán hàng trả lời, dẫn dắt, chăm sóc khách qua Fanpage, Zalo OA, website; 4 tầng, 6 nguyên tắc vàng, ví dụ Aduca.
- Sale Chat · AI AgentKịch bản chatbot bán hàng: dẫn dắt 6 bước như người thậtKịch bản chatbot bán hàng 6 bước: điều kiện lên bước, khai thác một ý mỗi lượt, tín hiệu mua, công thức trả lời, xử lý từ chối, chuyển người, mẫu để điền.
- OpenClaw · AI AgentCài đặt OpenClaw trên VPS an toànNền tảng cho mọi Agent: cài VPS bảo mật, OpenClaw chạy 24/7, Telegram, nhiều Agent, Google, Meta, Zalo, sao lưu 3 lớp.
- OpenClaw · Facebook & InstagramAgent Facebook & InstagramBáo cáo Meta Ads qua Meta Ads MCP chính thức, cảnh báo, tạo chiến dịch tạm dừng chờ bạn bật, Fanpage, Instagram, bình luận, Pixel.
Xem tất cả tài liệu hướng dẫn →
Nhận báo giá Hệ thống Sale Chat tự động
Aduca dựng trợ lý AI bán hàng cho Fanpage, Zalo OA, website theo đúng sản phẩm, bảng giá và kịch bản của bạn, có báo Sale và chăm sóc khách tự động. Báo giá sau buổi khảo sát, theo số kênh, số sản phẩm và lượng tin nhắn.
Nguồn tham khảo
- Meta – Messenger Platform Webhooks (trả 200 trong 5 giây, gửi lại, chống trùng)
- Meta – Sự kiện webhook messages (mã tin mid, tệp đính kèm ảnh, âm thanh)
- Meta – Sender actions (đã xem, đang soạn)
- Meta – Chính sách Messenger Platform (bot phản hồi trong 30 giây)
- n8n Docs – Webhook node
- n8n Docs – Chat Trigger (khung chat hosted và embedded)
- n8n Docs – Execute Sub-workflow
- n8n Docs – AI Agent node
- n8n Docs – Data tables
Lịch sử cập nhật
- 29/10/2026 — Bản đầu.
Miễn trừ trách nhiệm
Bài viết thuộc chuỗi kiến thức của Công ty Cổ phần Giáo dục Aduca, chia sẻ miễn phí cho mục đích học tập. Thông tin kỹ thuật đối chiếu với tài liệu chính thức của các dự án và nền tảng tại ngày cập nhật (có ghi nguồn); phần nhận định là quan điểm của Aduca. OpenClaw, Hermes Agent, Claude (thương hiệu của Anthropic), ChatGPT (thương hiệu của OpenAI), n8n (thương hiệu của n8n GmbH), các phần mềm chạy model và các model AI mở (Ollama, LM Studio, Qwen, Gemma, gpt-oss…), Obsidian, Notion, phương pháp Building a Second Brain (Tiago Forte) cùng các phần mềm, dịch vụ nêu trong bài thuộc về chủ sở hữu tương ứng, không thuộc Aduca; Aduca không phải đối tác chính thức của các công ty này. Tính năng, gói và giá có thể thay đổi bất cứ lúc nào – hãy kiểm tra trang chính thức trước khi mua. Kết quả áp dụng phụ thuộc quy trình, dữ liệu và con người của từng doanh nghiệp; bài viết không cam kết doanh thu hay hiệu quả cụ thể. © 2026 Aduca — được trích dẫn khi ghi rõ nguồn aduca.vn.