پرسش‌های متداول
آیا کاربران باید چیزی نصب کنند؟
نه. کاربران فقط یک تگ اسکریپت را در HTML خود می‌چسبانند — بدون بستهٔ npm، بدون مرحلهٔ ساخت، بدون وابستگی. قابلیت‌های اضافی خودکار از همان origin بارگذاری می‌شوند.
آیا با CSS من تداخل پیدا می‌کند؟
نه. ویجت درون Shadow DOM رندر می‌شود و سبک‌هایش کاملاً از صفحهٔ شما جدا می‌ماند.
آیا از برنامه‌های تک‌صفحه‌ای (React، Vue، Next.js) پشتیبانی می‌کند؟
بله. اسکریپت یک بار بارگذاری می‌شود و با تغییر مسیرها پابرجا می‌ماند. برای React/Next.js اسکریپت را در layout ریشه بگذارید.
// 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>
);
}وقتی گفت‌وگو حل می‌شود چه اتفاقی می‌افتد؟
پیام تازه پس از حل‌شدن، خودکار گفت‌وگوی پیگیری پیونددار با گفت‌وگوی پیشین باز می‌کند (در صندوق ورودی با «Continued from #N» نشان داده می‌شود). زمینه‌ای مانند زبان و متن گفت‌وگوی پیشین منتقل می‌شود و بازدیدکننده یک چت پیوسته می‌بیند. اگر گفت‌وگوی حل‌شده در دست یک هم‌تیمی بود، پیگیری به‌جای هوش مصنوعی دوباره به تیم شما هدایت می‌شود؛ وگرنه هوش مصنوعی آن را برمی‌دارد.
ویجت چگونه بارگذاری می‌شود؟
ویجت به‌صورت ناهمگام (async) بارگذاری می‌شود، پس هرگز جلوی رندر صفحه را نمی‌گیرد. بستهٔ اصلی حدود 180KB است (با gzip حدود 50KB)؛ قابلیت‌های اختیاری (کمپین‌ها، تورهای محصول) پس از سوارشدن ویجت به‌صورت chunkهای تنبل جداگانه بارگذاری می‌شوند، پس رندر آغازین صفحه هرگز مسدود نمی‌شود.
ارجاع چگونه کار می‌کند؟
کاربران می‌توانند دکمهٔ «گفت‌وگو با انسان» را بزنند، عبارتی بنویسند که در آن انسان بخواهند، یا هوش مصنوعی خودش ارجاع دهد وقتی نتواند از پایگاه دانش شما پاسخ بدهد. پس از ارجاع، هوش مصنوعی دیگر پاسخ نمی‌دهد و همهٔ پیام‌های بعدی به تیم پشتیبانی شما فرستاده می‌شوند. جزئیات در بخش «ارجاع و تحویل» آمده است.
آیا کاربران می‌توانند پس از ارجاع، گفت‌وگو با هوش مصنوعی را ادامه دهند؟
بله. ویجت دکمهٔ «ادامه با هوش مصنوعی» را نشان می‌دهد که با آن کاربر می‌تواند ارجاع را کنار بگذارد و به گفت‌وگو با هوش مصنوعی برگردد.
پایگاه دانش و خزش وب‌سایت#
چرا خزش وب‌سایت من مسدود شده است؟
«مسدود» یعنی سایت — یا لایهٔ محافظتی آن (Cloudflare، WAF، افزونهٔ ضدربات) — خزندهٔ ما را رد کرده است: صفحهٔ شروع یا robots.txt در هر تلاش با خطای دسترسی یا چالش «در حال بررسی مرورگر شما» پاسخ داده‌اند، یا robots.txt صراحتاً خزندهٔ ما را ممنوع کرده است. صفحاتی که قبلاً وارد کرده‌اید دست‌نخورده می‌مانند و همگام‌سازی مجدد تا زمانی که سایت به ما اجازهٔ ورود ندهد، به همان شکل شکست می‌خورد. از مالک سایت بخواهید User-Agent RespondoAI-Crawler (رشتهٔ کامل: Mozilla/5.0 (compatible; RespondoAI-Crawler/1.0; +https://respondo.ai/bot)) را در تنظیمات محافظتی مجاز کند — در Cloudflare این مسیر Security → WAF → Custom rules است — و اگر علت robots.txt است، یک قانون مجازسازی برای User-agent: RespondoAI-Crawler اضافه کند. Respondo نشانی IP ثابتی برای خزنده منتشر نمی‌کند — بر اساس User-Agent در فهرست مجاز قرار دهید؛ اگر خطای نمایش‌داده‌شده روی منبع یک IP را نام می‌برد، آن را هم مجاز کنید. اگر امکان تغییر سایت وجود ندارد، همان محتوا را به‌صورت فایل یا متن چسبانده‌شده اضافه کنید.
خزش تمام شد اما فقط چند صفحه پیدا کرد
ما صفحات را از طریق نقشهٔ سایت (خط Sitemap: در robots.txt یا مکان‌های رایجی مانند /sitemap.xml) و با دنبال‌کردن پیوندها از URL شروع پیدا می‌کنیم — تا عمق ۱۰ پیوند و حداکثر ۵٬۰۰۰ صفحه برای هر منبع. فقط صفحاتی که در همان سایت و زیر مسیر URL شروع هستند وارد می‌شوند: خزشی که از https://example.com/help شروع شود، /blog را رد می‌کند؛ پس از ریشه شروع کنید یا مسیرهای شامل‌شونده اضافه کنید. صفحاتی که هیچ پیوند یا نقشهٔ سایتی به آن‌ها اشاره نمی‌کند، صفحاتی که robots.txt ممنوع کرده و صفحات پشت ورود پیدا نمی‌شوند. صفحات تقریباً یکسان (نسخه‌های چاپی، گونه‌های دارای پارامتر ردیابی) در یک صفحه ادغام می‌شوند. صفحاتی که محتوایشان کاملاً با JavaScript ترسیم می‌شود شناسایی و با سازوکار پشتیبان مبتنی بر مرورگر رندر می‌شوند؛ بنابراین تعداد کم صفحات معمولاً نشانهٔ مشکل در محدوده یا نقشهٔ سایت است، نه رندر.
چگونه خزش را به یک بخش از سایت محدود کنم؟
در پنجرهٔ افزودن وب‌سایت، Advanced را باز کنید و Only crawl paths starting with (فقط مسیرهایی که با این شروع می‌شوند خزش شود) و/یا Skip paths starting with (مسیرهایی که با این شروع می‌شوند رد شود) را پر کنید — هر مسیر در یک خط، حداکثر ۵۰ مورد در هر فیلد. تطبیق بر اساس بخش‌های کامل مسیر انجام می‌شود: /docs با /docs و /docs/getting-started تطبیق دارد، اما با /docs-archive نه؛ اسلش انتهایی نادیده گرفته می‌شود و می‌توانید یک URL کامل بچسبانید — فقط مسیر آن استفاده می‌شود. قوانین ردکردن بر قوانین شامل‌کردن اولویت دارند. همین قوانین برای نقشهٔ سایت و هر همگام‌سازی مجدد بعدیِ آن منبع اعمال می‌شود.
Respondo هر چند وقت یک‌بار وب‌سایت من را دوباره خزش می‌کند؟
هر منبع وب‌سایت در پنل صفحاتش یک زمان‌بندی Auto-refresh دارد: Off (خاموش)، Daily (هر ۲۴ ساعت) یا Weekly (هر ۷ روز). خزش زمان‌بندی‌شده افزایشی است: صفحاتی که lastmod آن‌ها در نقشهٔ سایت قدیمی‌تر از خزش قبلی است رد می‌شوند، صفحات بدون تغییر دوباره نمایه نمی‌شوند، صفحات تغییریافته دوباره نمایه می‌شوند و صفحات ناپدیدشده حذف می‌شوند. برای به‌روزرسانی فوری، از Re-sync در منوی منبع یا Re-sync all در صفحهٔ Knowledge استفاده کنید.
«این بار نتوانستیم سایت را بخوانیم» — چه اتفاقی افتاد؟
این خطای عمومی است: سایت به‌موقع پاسخ نداده، دامنه حل نشده، سرور خطا برگردانده، صفحهٔ شروع متن قابل‌خواندنی نداشته یا نشانی پیدا نشده است. جزئیات روی منبع نمایش داده می‌شود. بررسی کنید که URL در یک پنجرهٔ خصوصی مرورگر باز شود، دامنه غلط املایی نداشته باشد و صفحهٔ شروع یک صفحهٔ محتوای واقعی باشد نه صفحهٔ ورود. شبکه‌های اجتماعی و پلتفرم‌های پیام‌رسان (Facebook، Instagram، LinkedIn، X، YouTube و مشابه آن‌ها) اصلاً قابل واردکردن نیستند — پیش از شروع خزش رد می‌شوند. صفحات موجود شما حفظ می‌شوند؛ منبع زمان‌بندی‌شده در اجرای بعدی دوباره تلاش می‌کند، در غیر این صورت وقتی سایت دوباره در دسترس شد، همگام‌سازی مجدد کنید.
«نمایهٔ جست‌وجوی ما پر است» و «نتوانستیم این منبع را نمایه کنیم» یعنی چه؟
هر دو پس از خوانده‌شدن موفق محتوا ظاهر می‌شوند. نمایه پر است یعنی نمایهٔ جست‌وجویی که این منبع در آن کپی می‌شود در سمت Respondo جا ندارد — این محدودیت Respondo است، نه مشکلی در محتوای شما. صفحات ذخیره شده‌اند، هر چیزی که قبلاً نمایه شده همچنان پاسخ می‌دهد، تیم ما به‌طور خودکار مطلع می‌شود و به‌محض آزادشدن فضا منبع نمایه خواهد شد؛ همگام‌سازی مجدد زودتر از آن به همان شکل شکست می‌خورد. نتوانستیم این منبع را نمایه کنیم یعنی ساخت نمایهٔ جست‌وجو این بار شکست خورده است — خطایی موقت در سمت ما؛ داده‌های موجود سالم‌اند و کار به‌طور خودکار دوباره تلاش می‌شود. اگر هر یک از این پیام‌ها ادامه یافت، از «پرسش از Copilot» روی خطا استفاده کنید.
آیا صفحات طولانی فقط از ابتدایشان پاسخ داده می‌شوند؟
خیر. هر صفحهٔ خزش‌شده به قطعات هم‌پوشان تقریباً ۱٬۶۰۰ نویسه‌ای تقسیم می‌شود و هر قطعه جداگانه همراه با عنوان صفحه نمایه می‌شود؛ بنابراین پاسخ می‌تواند از هر بخشی از یک مقالهٔ طولانی بیاید. ارجاع‌ها همچنان برای هر صفحه یک پیوند نشان می‌دهند. صفحاتی که پیش از این تغییر وارد شده‌اند در همگام‌سازی‌های مجدد بعدی دوباره تقسیم می‌شوند.
چگونه برای خطای خزش کمک بگیرم؟
هر خطای خزش یا نمایه‌سازی در صفحهٔ Knowledge دکمهٔ پرسش از Copilot دارد. این دکمه Copilot را با خطای پیوست‌شده باز می‌کند و Copilot بر اساس مستندات راهنمای خود Respondo با گام‌های مشخص برای مورد شما پاسخ می‌دهد. این کمک رایگان است — در شمار درخواست‌های هوش مصنوعی شما حساب نمی‌شود. اگر گام‌ها مشکل را حل نکردند، همین را بگویید — «کمکی نکرد» کافی است. Copilot آن‌گاه کارتی پیشنهاد می‌کند که مشکل را به تیم Respondo می‌سپارد: کارت دقیقاً فهرست می‌کند چه چیزی ارسال می‌شود، تا شما تأیید نکنید چیزی ارسال نمی‌شود و پاسخ آن‌ها در همان رشتهٔ Copilot می‌رسد. اگر سپردن از اینجا ممکن نباشد، Copilot به‌جای سکوت این را صریح می‌گوید.
پیام‌هایی که به مشتری نمی‌رسند#
یک پاسخ «Not delivered» نشان می‌دهد — یعنی چه و اول از همه چه کنم؟
هر پیام خروجی در صندوق ورودی یک نشانگر تحویل دارد: Queued (در صف — پاسخ‌هایی که پشت سر هم نوشته می‌شوند یکی می‌شوند و ظرف چند دقیقه به‌صورت یک ایمیل خارج می‌شوند)، Sending…، Sent، Delivered یا یک خطای قرمز. خطاها سه شکل دارند: Not delivered — کانال پیام را نپذیرفته است؛ Bounced به‌همراه زیرنوع برگشت در کنارش — سرور ایمیل گیرنده پیام را رد کرده است؛ و Marked as spam — گیرنده آن را گزارش کرده است. نشانگر را روی برچسب ببرید یا رویش کلیک کنید: راهنمای شناور عین جملهٔ ارائه‌دهنده را نشان می‌دهد، از جمله تشخیص خام SMTP در مورد برگشت. کنار آن حداکثر دو کنش قرار دارد — Retry / Send again که واقعاً پیام را دوباره می‌فرستد، و Ask Copilot که Copilot را با پیوستِ خطا باز می‌کند. اگر دکمهٔ تلاش مجدد اصلاً وجود نداشته باشد، نشانی مسدود است و ارسال دوباره به همان شکل شکست می‌خورد. یک Sent یا Delivered که کنارش N files not delivered آمده یعنی متن رسیده اما یک پیوست نرسیده است — آن کانال نتوانسته فایل را حمل کند.
چرا ایمیل من به مشتری نرسید؟
چهار چیز متفاوت، و برچسب آن‌ها را از هم جدا می‌کند. برگشت دائمی یعنی نشانی وجود ندارد یا ایمیل را نمی‌پذیرد — دکمهٔ تلاش مجدد وجود ندارد و نشانی به فهرست مسدودسازی می‌رود. برگشت موقت یعنی صندوق پر است یا مشکلی گذرا روی سرور گیرنده وجود دارد؛ گزینهٔ Send again ارائه می‌شود و معمولاً بعداً کار می‌کند. برگشتی که در تشخیص آن SPF، DKIM، DMARC یا 5.7.515 آمده باشد فرق دارد: سامانهٔ ایمیل گیرنده پیام را رد کرده چون دامنهٔ ارسال شما در بررسی احراز اصالت رد شده است. تا زمانی که دامنه درست نشود، هر پاسخ تازه دقیقاً به همان شکل برمی‌گردد؛ پس در این فاصله از کانال دیگری پاسخ دهید و رکوردهای DNS کانال ایمیل را در Settings → Channels اصلاح کنید. در نهایت، Marked as spam یعنی گیرنده «گزارش هرزنامه» را زده است: نشانی مسدود می‌شود و دیگر برایش ارسال نمی‌کنیم. گزارش یک کمپین می‌تواند علاوه بر این The email provider rejected this message را هم نشان دهد — ردی قطعی پیش از آنکه ایمیل اصلاً خارج شود، معمولاً به‌دلیل دامنهٔ ارسال تأییدنشده یا نشانی نادرست — و همچنین The email provider rejected our credentials که مشکلِ پیکربندی فضای کاری است، نه چیزی مربوط به آن یک مخاطب.
فهرست مسدودسازی چیست و یک نشانی چطور از آن خارج می‌شود؟
فهرستی است مخصوص فضای کاری شما از نشانی‌های ایمیلی که Respondo از ارسال به آن‌ها خودداری می‌کند. یک نشانی وقتی وارد آن می‌شود که پیامی برگشت سخت بخورد (hard bounce، یعنی رد قطعی)، وقتی کسی یکی از ایمیل‌های شما را هرزنامه گزارش کند، یا وقتی دستی مسدود شود. برگشت‌های نرم هرگز نشانی را مسدود نمی‌کنند. تا وقتی مسدودی فعال است، تحویل‌های کمپین به آن نشانی با پیام This address is blocked after an earlier bounce or complaint رد می‌شوند و پاسخ در صندوق ورودی پیش از خروج رد می‌شود. همیشه فقط گیرندهٔ واقعی پیام مسدود می‌شود — یک اعلان برگشت نمی‌تواند نشانی دلخواهی را مسدود کند. در داشبورد صفحه‌ای برای این فهرست وجود ندارد: مالک یا مدیر می‌تواند آن را با GET https://api.respondo.ai/api/v1/integrations/email/suppressions بخواند و یک مورد را با DELETE https://api.respondo.ai/api/v1/integrations/email/suppressions/<email> بردارد، یا از پشتیبانی Respondo بخواهد این کار را انجام دهد. برگشت سخت را فقط وقتی آزاد کنید که مطمئن باشید صندوق واقعاً درست شده است — ارسال دوبارهٔ ایمیل به نشانی مرده به اعتبار دامنهٔ شما آسیب می‌زند.
واتساپ پاسخ من را نمی‌پذیرد — پنجرهٔ ۲۴ ساعته
واتساپ به کسب‌وکار اجازه می‌دهد پیام آزاد را فقط تا ۲۴ ساعت پس از آخرین پیام مشتری بفرستد؛ Meta هر چیزی دیرتر از آن را با خطای 131047 رد می‌کند. Respondo این پنجره را برای هر فرد دنبال می‌کند و وقتی بداند پنجره بسته شده، پاسخ را پیش از ارسال متوقف می‌کند. وقتی Respondo هیچ سابقه‌ای از پنجره نداشته باشد — مخاطبی که وارد شده، یا شماره‌ای که هرگز به شما ننوشته — جلوی ارسال را نمی‌گیرد: پیام به Meta می‌رود و Meta تصمیم می‌گیرد. دقیقاً دو راه پیش رو دارید. صبر کنید تا مشتری دوباره بنویسد — پیام او پنجره را برای ۲۴ ساعت دیگر باز می‌کند و آن‌وقت پاسخ شما می‌رود — یا یک template (قالب) تأییدشده از سوی Meta بفرستید. قالب‌ها را نمی‌توان از نگارندهٔ پیام در گفت‌وگو فرستاد. آن‌ها را در Outbound → WhatsApp templates مدیریت کنید: Sync آنچه را که از قبل روی شمارهٔ شما ثبت شده می‌آورد و New template قالبی را به Meta می‌فرستد که بررسی‌اش یک روز یا بیشتر طول می‌کشد. سپس قالب تأییدشده را از طریق یک کمپین خروجی برای آن مخاطب بفرستید. قالب هم به افراد داخل پنجره و هم بیرون آن می‌رسد، اما فقط تا وقتی وضعیتش approved باشد.
«That channel is disconnected» / «That channel is not connected»
Disconnected یعنی یکپارچه‌سازی وجود دارد اما دیگر فعال نیست — توکن دسترسی‌اش باطل یا منقضی شده، یا کسی آن را قطع کرده است. Not connected یعنی پشت نقطهٔ ارتباطی مخاطب اصلاً هیچ یکپارچه‌سازی‌ای وجود ندارد. هر دو در Settings → Channels رفع می‌شوند؛ آنجا کانال‌های قطع‌شده زیر عنوان جداگانهٔ خود گروه‌بندی شده‌اند و روی هر کارت دکمهٔ Reconnect هست؛ دوباره وصل کنید و سپس پیام را دوباره بفرستید. دو حالت همسایه شبیه به هم به نظر می‌رسند اما یکی نیستند: کانال ایمیلی که دامنهٔ ارسالش تأیید نشده را نمی‌توان به Live تغییر داد و تا تأیید DKIM و SPF چیزی نمی‌فرستد، و کانال فقط‌دریافتی طبق طراحی پیام خروجی را نمی‌پذیرد، پس Retry آنجا هرگز موفق نخواهد شد.
«No channel to reach this person on» / «No email address on this contact»
هر دو در گزارش تحویل کمپین دیده می‌شوند، نه در صندوق ورودی. اولی یعنی هیچ‌کدام از نقاط ارتباطی مخاطب با کانال‌هایی که کمپین روی آن‌ها می‌فرستد جور درنیامده است؛ اگر تنها نقطهٔ ارتباطی او روی کانال فقط‌دریافتی باشد، این مورد جداگانه به‌عنوان ردکردن عمدی گزارش می‌شود. دومی یعنی کمپین ایمیل می‌فرستد و برای مخاطب هیچ نشانی ثبت نشده است. تلگرام گونهٔ خودش را دارد: اگر فرد هرگز به ربات شما ننوشته باشد، گفت‌وگویی برای نوشتن وجود ندارد، چون Bot API اجازه نمی‌دهد ربات اول پیام بدهد — اولین پیام باید از سوی او بیاید. این‌ها را با افزودن نشانی جامانده به مخاطب، با گسترش کانال‌های هدف کمپین، یا با اجازه دادن به بازگشت آن به ایمیل حل کنید.
مخاطب لغو اشتراک کرده — چه چیزی می‌توانم بفرستم؟
They had already unsubscribed یعنی مخاطب یک انصراف سراسری دارد — از طریق پیوند لغو اشتراک در یکی از ایمیل‌های شما تنظیم شده، با یک ورود داده آمده، یا یکی از هم‌تیمی‌ها آن را تغییر داده است. کمپین‌ها و سری‌ها چنین مخاطبانی را روی هر کانالی رد می‌کنند، نه فقط ایمیل، و تحویل به‌عنوان ردکردن ثبت می‌شود نه خطا. پاسخ یک‌به‌یکِ یک هم‌تیمی داخل گفت‌وگو عمداً با آن مسدود نمی‌شود: انصراف دربارهٔ ارسال انبوه است و پاسخ دادن به کسی که به شما نوشته یک تصمیم انسانی است. این وضعیت روی مخاطب به‌صورت Outbound: Subscribed / Unsubscribed نمایش داده می‌شود، فهرست مخاطبان را می‌توان بر اساس آن فیلتر کرد و دکمهٔ Re-subscribe روی مخاطب آن را برمی‌گرداند — فقط وقتی از آن استفاده کنید که خود فرد خواسته باشد.
چند بار تلاش مجدد می‌کنید و آیا زدن Retry امن است؟
پاسخی که از صندوق ورودی می‌رود به صفی سپرده می‌شود که تا پنج تلاش انجام می‌دهد و بین آن‌ها تقریباً ۳، ۱۰، ۳۰ و ۳۰ دقیقه صبر می‌کند. فقط خطاهای گذرا دوباره تلاش می‌شوند — پایان مهلت، اتصال ردشده، محدودیت نرخ، خطاهای خودِ سرور ارائه‌دهنده. رد قطعی (نشانی ناشناس، دامنهٔ ارسال تأییدنشده، اعتبارنامهٔ ردشده) بی‌درنگ ناموفق علامت می‌خورد، چون تکرار همان پاسخ را برمی‌گرداند. تحویل‌های کمپین روی صف مخصوص خود با تا شش تلاش و انتظارهای کوتاه‌تر اجرا می‌شوند — ۵ ثانیه، ۳۰ ثانیه، ۲ دقیقه، ۱۰ دقیقه؛ وقتی این‌ها تمام شود، تحویل با پیام Delivery kept failing and was stopped after several attempts بسته می‌شود به‌جای آنکه تا ابد در «queued» بماند. زدن دستی Retry امن است. فقط روی پیامی اثر می‌گذارد که واقعاً در وضعیت خطاست، و برای ایمیل نخست از ارائه‌دهنده می‌پرسد بر سر پیام اصلی چه آمده: اگر آن ایمیل واقعاً خارج شده باشد، ردیف به‌جای فرستادن نسخهٔ دوم به «تحویل‌شده» تغییر می‌کند و ارسال مجدد واقعی با کلید ایدمپوتنسی تازه خارج می‌شود. جایی که نسخهٔ دوم اشتباه باشد — برگشت سخت، شکایت هرزنامه، ارسالی که هنوز در جریان است — دکمه وجود ندارد یا تلاش مجدد با ذکر دلیل رد می‌شود.
علت هنوز روشن نیست — چگونه کمک بگیرم؟
هر پیام ناموفق کنارش یک دکمهٔ Ask Copilot دارد. این دکمه Copilot را با پیوستِ خطا، کانال و گفت‌وگو باز می‌کند و Copilot از مستندات راهنمای خودِ Respondo با گام‌هایی دقیقاً برای همان خطا پاسخ می‌دهد. این کمک رایگان است — به سهم درخواست‌های هوش مصنوعی شما حساب نمی‌شود. اگر گام‌ها مشکل را حل نکردند، همین را بگویید — «کمکی نکرد» کافی است. Copilot آن‌گاه کارتی پیشنهاد می‌کند که مشکل را به تیم Respondo می‌سپارد: کارت دقیقاً فهرست می‌کند چه چیزی ارسال می‌شود، تا شما تأیید نکنید چیزی ارسال نمی‌شود و پاسخ آن‌ها در همان رشتهٔ Copilot می‌رسد. اگر سپردن از اینجا ممکن نباشد، Copilot به‌جای سکوت این را صریح می‌گوید.