Câu hỏi thường gặp
Người dùng có cần cài đặt gì không?
Không. Người dùng chỉ cần dán một thẻ script vào HTML của họ — không gói npm, không bước build, không phụ thuộc. Các tính năng bổ sung tự động tải từ cùng một origin.
Nó có xung đột với CSS của tôi không?
Không. Widget render bên trong một Shadow DOM, hoàn toàn cô lập các kiểu của nó khỏi trang của bạn.
Nó có hỗ trợ ứng dụng một trang (React, Vue, Next.js) không?
Có. Script tải một lần và tồn tại qua các thay đổi route. Với React/Next.js, hãy đặt script trong layout gốc của bạn.
// app/layout.tsx (App Router)
import Script from 'next/script';
import { ReactNode } from 'react';
export default function RootLayout({ children }: { children: ReactNode }) {
return (
<html lang="en">
<body>
{children}
<Script id="respondo-init" strategy="afterInteractive">
{`
window.Respondo = window.Respondo || {};
Respondo.init = Respondo.init || function(c) { window.RespondoAIConfig = c; };
Respondo.q = Respondo.q || [];
Respondo.identify = Respondo.identify || function(d) { Respondo.q.push(['identify', d]); };
Respondo.init({
agentId: 'YOUR_AGENT_ID',
channelId: 'YOUR_CHANNEL_ID'
});
`}
</Script>
<Script src="https://api.respondo.ai/widget/widget.js" strategy="afterInteractive" />
</body>
</html>
);
}Điều gì xảy ra khi một cuộc hội thoại được giải quyết?
Một tin nhắn mới sau khi đã giải quyết sẽ tự động mở một cuộc hội thoại tiếp nối được liên kết với cuộc trước đó (hiển thị là "Continued from #N" trong inbox của bạn). Ngữ cảnh như ngôn ngữ và bản ghi trước đó được giữ lại, và khách truy cập thấy một cuộc chat liền mạch. Nếu một thành viên đội ngũ đang xử lý cuộc hội thoại đã giải quyết, cuộc tiếp nối sẽ được định tuyến trở lại đội của bạn thay vì AI; nếu không, AI sẽ tiếp nhận.
Widget được tải như thế nào?
Widget được tải bất đồng bộ (async), nên nó không bao giờ chặn việc render trang. Bundle lõi là ~180KB (~50KB gzip); các tính năng tùy chọn (campaigns, product tours) tải dưới dạng các chunk lazy riêng sau khi widget được mount, nên việc render trang ban đầu không bao giờ bị chặn.
Chuyển cấp hoạt động như thế nào?
Người dùng có thể nhấn nút "Talk to human", gõ một cụm từ yêu cầu người thật, hoặc AI tự bàn giao khi nó không thể trả lời dựa trên cơ sở kiến thức của bạn. Sau khi chuyển cấp, AI ngừng phản hồi và mọi tin nhắn tiếp theo được chuyển cấp đến đội ngũ hỗ trợ của bạn. Xem phần Chuyển cấp & bàn giao để biết chi tiết.
Người dùng có thể tiếp tục chat với AI sau khi chuyển cấp không?
Có. Widget hiển thị một nút "Continue with AI" cho phép người dùng bỏ qua việc chuyển cấp và tiếp tục cuộc hội thoại với AI.
Cơ sở tri thức và thu thập dữ liệu website#
Vì sao việc thu thập dữ liệu website của tôi bị chặn?
"Bị chặn" nghĩa là website — hoặc lớp bảo vệ của nó (Cloudflare, WAF, plugin chống bot) — đã từ chối trình thu thập của chúng tôi: trang bắt đầu hoặc robots.txt trả về lỗi truy cập hay thử thách "đang kiểm tra trình duyệt của bạn" ở mọi lần thử, hoặc robots.txt cấm rõ ràng trình thu thập của chúng tôi. Các trang đã nhập trước đó vẫn nguyên vẹn, và việc đồng bộ lại sẽ thất bại theo cùng cách cho đến khi website cho phép chúng tôi vào. Hãy đề nghị chủ website cho phép User-Agent RespondoAI-Crawler (chuỗi đầy đủ: Mozilla/5.0 (compatible; RespondoAI-Crawler/1.0; +https://respondo.ai/bot)) trong cài đặt bảo vệ — trên Cloudflare là Security → WAF → Custom rules — và, nếu nguyên nhân là robots.txt, thêm quy tắc cho phép đối với User-agent: RespondoAI-Crawler. Respondo không công bố địa chỉ IP cố định của trình thu thập — hãy cho phép theo User-Agent; nếu lỗi hiển thị trên nguồn nêu một IP, hãy cho phép cả IP đó. Nếu không thể thay đổi website, hãy thêm cùng nội dung đó dưới dạng tệp hoặc văn bản dán.
Quá trình thu thập đã xong nhưng chỉ tìm thấy vài trang
Chúng tôi tìm trang từ sitemap của website (dòng Sitemap: trong robots.txt hoặc các vị trí thông dụng như /sitemap.xml) và bằng cách lần theo liên kết từ URL bắt đầu — tối đa 10 cấp liên kết và tối đa 5.000 trang mỗi nguồn. Chỉ các trang trên cùng website và nằm dưới đường dẫn của URL bắt đầu mới được nhập: lần thu thập bắt đầu từ https://example.com/help sẽ bỏ qua /blog, vì vậy hãy bắt đầu từ gốc hoặc thêm đường dẫn cần bao gồm. Các trang không có liên kết hay sitemap nào trỏ tới, các trang bị robots.txt cấm, và các trang sau màn hình đăng nhập sẽ không được tìm thấy. Các trang gần như trùng nhau (bản in, biến thể có tham số theo dõi) được gộp thành một. Các trang có nội dung được vẽ hoàn toàn bằng JavaScript sẽ được phát hiện và kết xuất bằng cơ chế dự phòng dựa trên trình duyệt, nên số trang ít thường là vấn đề về phạm vi hoặc sitemap, không phải kết xuất.
Làm sao giới hạn việc thu thập trong một mục của website?
Mở Advanced trong hộp thoại thêm website và điền Only crawl paths starting with (chỉ thu thập các đường dẫn bắt đầu bằng) và/hoặc Skip paths starting with (bỏ qua các đường dẫn bắt đầu bằng) — mỗi dòng một đường dẫn, tối đa 50 mỗi trường. Việc so khớp theo từng phân đoạn đường dẫn trọn vẹn: /docs khớp với /docs và /docs/getting-started, nhưng không khớp với /docs-archive; dấu gạch chéo cuối bị bỏ qua, và bạn có thể dán URL đầy đủ — chỉ phần đường dẫn được dùng. Quy tắc bỏ qua ưu tiên hơn quy tắc bao gồm. Các quy tắc này cũng áp dụng cho sitemap và cho mọi lần đồng bộ lại sau này của nguồn đó.
Respondo thu thập lại website của tôi bao lâu một lần?
Mỗi nguồn website có lịch Auto-refresh trong bảng trang của nó: Off (tắt), Daily (mỗi 24 giờ) hoặc Weekly (mỗi 7 ngày). Lần thu thập theo lịch mang tính tăng dần: các trang có lastmod trong sitemap cũ hơn lần thu thập trước sẽ bị bỏ qua, trang không đổi không được lập chỉ mục lại, trang đã đổi được lập chỉ mục lại và trang đã biến mất bị xóa. Để làm mới ngay, dùng Re-sync trong menu của nguồn hoặc Re-sync all trên trang Knowledge.
"Lần này chúng tôi không đọc được website" — chuyện gì đã xảy ra?
Đây là lỗi chung: website không phản hồi kịp, tên miền không phân giải được, máy chủ trả về lỗi, trang bắt đầu không có văn bản đọc được, hoặc không tìm thấy địa chỉ. Chi tiết được hiển thị trên nguồn. Hãy kiểm tra URL có mở được trong cửa sổ trình duyệt ẩn danh không, tên miền không có lỗi chính tả và trang bắt đầu là trang nội dung thực chứ không phải màn hình đăng nhập. Mạng xã hội và nền tảng nhắn tin (Facebook, Instagram, LinkedIn, X, YouTube và tương tự) hoàn toàn không thể nhập — chúng bị từ chối trước khi bắt đầu thu thập. Các trang hiện có của bạn được giữ nguyên; nguồn có lịch sẽ thử lại ở lần chạy tiếp theo, nếu không hãy đồng bộ lại khi website truy cập được trở lại.
"Chỉ mục tìm kiếm của chúng tôi đã đầy" và "không thể lập chỉ mục nguồn này" nghĩa là gì?
Cả hai đều xuất hiện sau khi nội dung đã được đọc thành công. Chỉ mục đã đầy nghĩa là chỉ mục tìm kiếm mà nguồn này được sao chép vào không còn chỗ ở phía Respondo — đây là giới hạn của Respondo, không phải vấn đề với nội dung của bạn. Các trang đã được lưu, mọi thứ đã lập chỉ mục vẫn tiếp tục trả lời, đội ngũ của chúng tôi được thông báo tự động và nguồn sẽ được lập chỉ mục ngay khi có chỗ; đồng bộ lại sớm hơn sẽ thất bại theo cùng cách. Không thể lập chỉ mục nguồn này nghĩa là việc xây dựng chỉ mục tìm kiếm lần này đã thất bại — lỗi tạm thời ở phía chúng tôi; dữ liệu hiện có vẫn nguyên vẹn và tác vụ được thử lại tự động. Nếu một trong hai thông báo vẫn còn, hãy dùng "Hỏi Copilot" trên lỗi đó.
Trang dài chỉ được trả lời từ phần đầu?
Không. Mỗi trang đã thu thập được chia thành các đoạn chồng lấn khoảng 1.600 ký tự, mỗi đoạn được lập chỉ mục riêng kèm tiêu đề trang, nên câu trả lời có thể đến từ bất kỳ phần nào của một bài viết dài. Trích dẫn vẫn hiển thị một liên kết cho mỗi trang. Các trang được nhập trước thay đổi này sẽ được chia lại trong các lần đồng bộ lại tiếp theo.
Làm sao để được trợ giúp về lỗi thu thập?
Mọi lỗi thu thập hoặc lập chỉ mục trên trang Knowledge đều đi kèm nút Hỏi Copilot. Nút này mở Copilot với lỗi được đính kèm, và Copilot trả lời dựa trên tài liệu trợ giúp của chính Respondo với các bước cụ thể cho trường hợp của bạn. Trợ giúp này miễn phí — không tính vào số yêu cầu AI của bạn. Nếu các bước không giải quyết được, hãy nói vậy — "cách đó không giúp được" là đủ. Copilot sau đó sẽ đề xuất một thẻ chuyển vấn đề cho đội ngũ Respondo: thẻ liệt kê chính xác những gì sẽ được gửi, không có gì được gửi đi cho đến khi bạn xác nhận, và phản hồi của họ sẽ đến trong cùng luồng Copilot đó. Nếu không thể chuyển giao từ đây, Copilot sẽ nói thẳng thay vì im lặng.
Những tin nhắn không đến được khách hàng#
Một câu trả lời hiển thị "Not delivered" — điều đó nghĩa là gì và tôi nên làm gì trước tiên?
Mọi tin nhắn gửi đi trong hộp thư đều mang một chỉ báo gửi: Queued (đang xếp hàng — các câu trả lời viết liền nhau được gộp lại và rời đi dưới dạng một email duy nhất sau vài phút), Sending…, Sent, Delivered, hoặc một trạng thái lỗi màu đỏ. Lỗi có ba dạng: Not delivered — kênh từ chối tin nhắn; Bounced kèm phân loại phụ của lần trả lại ngay bên cạnh — máy chủ thư của người nhận đã từ chối email; và Marked as spam — người nhận đã báo cáo nó. Di chuột hoặc nhấp vào nhãn: chú giải hiển thị đúng nguyên văn của nhà cung cấp, bao gồm cả chẩn đoán SMTP thô đối với một lần trả lại. Bên cạnh đó có tối đa hai hành động — Retry / Send again, thao tác thực sự gửi lại tin nhắn, và Ask Copilot (hỏi Copilot), mở Copilot kèm theo lỗi. Nếu hoàn toàn không có nút gửi lại, địa chỉ đã bị chặn và gửi lại cũng sẽ thất bại theo cùng cách. Một Sent hoặc Delivered có kèm N files not delivered bên cạnh nghĩa là phần văn bản đã đến nhưng tệp đính kèm thì không — kênh đó không mang được tệp.
Vì sao email của tôi không đến được khách hàng?
Có bốn nguyên nhân khác nhau, và nhãn giúp phân biệt chúng. Trả lại vĩnh viễn nghĩa là địa chỉ không tồn tại hoặc từ chối nhận thư — không có nút gửi lại, và địa chỉ được đưa vào danh sách chặn gửi. Trả lại tạm thời là hộp thư đầy hoặc một sự cố thoáng qua trên máy chủ nhận; khi đó Send again được cung cấp và thường sẽ thành công sau đó. Một lần trả lại mà phần chẩn đoán nhắc đến SPF, DKIM, DMARC hoặc 5.7.515 lại là chuyện khác: hệ thống thư của người nhận từ chối tin nhắn vì tên miền gửi của bạn không vượt qua bước kiểm tra xác thực. Câu trả lời mới sẽ bị trả lại y hệt cho đến khi tên miền được sửa, vì vậy trong lúc đó hãy trả lời bằng kênh khác và khắc phục các bản ghi DNS của kênh email trong Settings → Channels. Cuối cùng, Marked as spam nghĩa là người nhận đã bấm "báo cáo spam": địa chỉ bị chặn gửi và chúng tôi ngừng gửi tới đó. Báo cáo chiến dịch còn có thể hiển thị thêm The email provider rejected this message (nhà cung cấp email đã từ chối tin nhắn này) — một sự từ chối vĩnh viễn ngay trước khi email kịp rời đi, thường do tên miền gửi chưa được xác minh hoặc địa chỉ sai định dạng — và The email provider rejected our credentials (nhà cung cấp email đã từ chối thông tin xác thực của chúng tôi), vốn là vấn đề thiết lập của workspace chứ không liên quan gì đến riêng liên hệ đó.
Danh sách chặn gửi là gì, và làm sao gỡ một địa chỉ khỏi đó?
Đó là danh sách riêng của workspace bạn, gồm các địa chỉ email mà Respondo từ chối gửi tới. Một địa chỉ rơi vào danh sách khi một tin nhắn bị trả lại vĩnh viễn (từ chối dứt khoát), khi ai đó báo cáo một email của bạn là spam, hoặc khi nó bị chặn thủ công. Trả lại tạm thời không bao giờ khiến địa chỉ bị chặn gửi. Trong lúc lệnh chặn còn hiệu lực, các lượt gửi chiến dịch tới địa chỉ đó bị bỏ qua kèm This address is blocked after an earlier bounce or complaint (địa chỉ này bị chặn sau một lần trả lại hoặc khiếu nại trước đó), và câu trả lời trong hộp thư bị từ chối trước khi rời đi. Chỉ người nhận thật của tin nhắn mới bị chặn gửi — một thông báo trả lại không thể chặn một địa chỉ tùy ý. Bảng điều khiển không có màn hình nào cho danh sách này: chủ sở hữu hoặc quản trị viên có thể đọc nó bằng GET https://api.respondo.ai/api/v1/integrations/email/suppressions và gỡ một mục bằng DELETE https://api.respondo.ai/api/v1/integrations/email/suppressions/<email>, hoặc nhờ bộ phận hỗ trợ Respondo làm giúp. Chỉ gỡ một lần trả lại vĩnh viễn khi bạn biết chắc hộp thư đó đã thực sự được khắc phục — gửi lại tới một địa chỉ đã chết sẽ làm tổn hại uy tín tên miền của bạn.
WhatsApp không chấp nhận câu trả lời của tôi — cửa sổ 24 giờ
WhatsApp chỉ cho phép doanh nghiệp gửi tin nhắn tự do trong vòng 24 giờ kể từ tin nhắn cuối của khách hàng; muộn hơn thế Meta sẽ từ chối mọi thứ với lỗi 131047. Respondo theo dõi cửa sổ đó theo từng người, và khi biết cửa sổ đã hết hạn, nó chặn câu trả lời trước khi gửi đi. Khi Respondo hoàn toàn không có ghi nhận nào về cửa sổ — một liên hệ được nhập vào, hoặc một số chưa từng nhắn cho bạn — nó không chặn: tin nhắn được chuyển tới Meta và Meta quyết định. Có đúng hai lối đi tiếp. Chờ khách hàng nhắn lại — tin nhắn của họ mở lại cửa sổ thêm 24 giờ và câu trả lời của bạn khi đó sẽ đi được — hoặc gửi một mẫu tin đã được Meta phê duyệt. Không thể gửi mẫu tin từ khung soạn thảo trong cuộc trò chuyện. Hãy quản lý chúng trong Outbound → WhatsApp templates: Sync (đồng bộ) kéo về những gì đã đăng ký sẵn trên số của bạn, còn New template (mẫu tin mới) gửi một mẫu tới Meta để duyệt, quá trình này mất một ngày hoặc lâu hơn. Sau đó gửi mẫu tin đã được duyệt qua một chiến dịch outbound nhắm tới liên hệ đó. Mẫu tin đến được với mọi người cả trong lẫn ngoài cửa sổ, nhưng chỉ khi trạng thái của nó là approved (đã duyệt).
"Kênh đó đã ngắt kết nối" / "Kênh đó chưa được kết nối"
Disconnected (đã ngắt kết nối) nghĩa là tích hợp vẫn tồn tại nhưng không còn hoạt động — mã truy cập của nó đã bị thu hồi hoặc hết hạn, hoặc ai đó đã ngắt kết nối nó. Not connected (chưa kết nối) nghĩa là điểm liên lạc của liên hệ hoàn toàn không có tích hợp nào phía sau. Cả hai đều được khắc phục trong Settings → Channels, nơi các kênh đã ngắt kết nối được gom dưới một tiêu đề riêng với nút Reconnect trên từng thẻ; hãy kết nối lại, rồi thử gửi lại tin nhắn. Hai trường hợp lân cận trông giống nhưng không phải một: kênh email có tên miền gửi chưa được xác minh thì không thể chuyển sang Live và không gửi được gì cho tới khi DKIM và SPF được xác nhận, còn kênh chỉ nhận thì theo thiết kế từ chối mọi tin nhắn gửi đi, nên Retry ở đó sẽ không bao giờ thành công.
"Không có kênh nào để tiếp cận người này" / "Liên hệ này không có địa chỉ email"
Cả hai đều xuất hiện trên báo cáo gửi của chiến dịch chứ không phải trong hộp thư. Thông báo thứ nhất nghĩa là không điểm liên lạc nào của liên hệ khớp với các kênh mà chiến dịch gửi đi; nếu điểm liên lạc duy nhất của họ nằm trên một kênh chỉ nhận, điều đó được báo cáo riêng như một lượt bỏ qua có chủ đích. Thông báo thứ hai nghĩa là chiến dịch gửi email còn liên hệ thì chưa có địa chỉ nào được lưu. Telegram có biến thể riêng: nếu người đó chưa từng nhắn cho bot của bạn thì không có cuộc trò chuyện nào để nhắn tới, vì Bot API cấm bot nhắn trước — chính họ phải gửi tin nhắn đầu tiên. Hãy khắc phục bằng cách thêm địa chỉ còn thiếu vào liên hệ, mở rộng các kênh mà chiến dịch nhắm tới, hoặc để nó dự phòng sang email.
Liên hệ đã hủy đăng ký — tôi có thể gửi gì?
They had already unsubscribed (họ đã hủy đăng ký từ trước) nghĩa là liên hệ mang trạng thái từ chối nhận toàn cục — được đặt qua liên kết hủy đăng ký trong một email của bạn, mang vào khi nhập dữ liệu, hoặc do đồng nghiệp bật lên. Chiến dịch và chuỗi tin bỏ qua những liên hệ như vậy trên mọi kênh chứ không riêng email, và lượt gửi được ghi nhận là bỏ qua chứ không phải thất bại. Câu trả lời một-một của đồng nghiệp bên trong một cuộc trò chuyện thì cố ý không bị nó chặn: từ chối nhận là chuyện của tin gửi hàng loạt, còn trả lời một người đã nhắn cho bạn là quyết định của con người. Trạng thái này hiển thị trên liên hệ dưới dạng Outbound: Subscribed / Unsubscribed, danh sách liên hệ có thể lọc theo nó, và nút Re-subscribe trên liên hệ sẽ đảo ngược trạng thái — chỉ dùng khi chính người đó yêu cầu bạn.
Bạn thử lại bao nhiêu lần, và bấm Retry có an toàn không?
Câu trả lời từ hộp thư được chuyển cho một hàng đợi thực hiện tối đa năm lần thử, chờ khoảng 3, 10, 30 và 30 phút giữa các lần. Chỉ những lỗi thoáng qua mới được thử lại — hết thời gian chờ, kết nối bị từ chối, giới hạn tần suất, lỗi máy chủ của chính nhà cung cấp. Một sự từ chối vĩnh viễn (địa chỉ không xác định, tên miền gửi chưa xác minh, thông tin xác thực bị từ chối) bị đánh dấu thất bại ngay lập tức, vì lặp lại cũng chỉ nhận về đúng câu trả lời đó. Lượt gửi chiến dịch chạy trên hàng đợi riêng với tối đa sáu lần thử và khoảng chờ ngắn hơn — 5 giây, 30 giây, 2 phút, 10 phút; khi hết số lần đó, lượt gửi được đóng lại với Delivery kept failing and was stopped after several attempts (việc gửi liên tục thất bại và đã dừng sau vài lần thử) thay vì nằm mãi ở trạng thái "đang xếp hàng". Bấm Retry bằng tay là an toàn. Nó chỉ tác động lên tin nhắn thực sự đang ở trạng thái thất bại, và với email nó hỏi nhà cung cấp trước xem bản gốc đã ra sao: nếu email đó thực sự đã đi, dòng trạng thái chuyển thành đã gửi thay vì gửi thêm bản thứ hai, còn một lần gửi lại thật sự sẽ rời đi dưới một khóa idempotency mới. Ở những chỗ mà bản thứ hai sẽ là sai — trả lại vĩnh viễn, khiếu nại spam, một lượt gửi vẫn đang trên đường — nút này không xuất hiện hoặc lần thử lại bị từ chối kèm lý do.
Vẫn chưa rõ nguyên nhân — làm sao để được trợ giúp?
Mọi tin nhắn thất bại đều có nút Ask Copilot (hỏi Copilot) bên cạnh. Nút này mở Copilot kèm theo lỗi, kênh và cuộc trò chuyện, và Copilot trả lời dựa trên tài liệu trợ giúp của chính Respondo với các bước cho đúng lỗi đó. Trợ giúp này miễn phí — không tính vào số yêu cầu AI của bạn. Nếu các bước không giải quyết được, hãy nói vậy — "cách đó không giúp được" là đủ. Copilot sau đó sẽ đề xuất một thẻ chuyển vấn đề cho đội ngũ Respondo: thẻ liệt kê chính xác những gì sẽ được gửi, không có gì được gửi đi cho đến khi bạn xác nhận, và phản hồi của họ sẽ đến trong cùng luồng Copilot đó. Nếu không thể chuyển giao từ đây, Copilot sẽ nói thẳng thay vì im lặng.