ਆਮ ਸਵਾਲ
ਕੀ ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਕੁਝ ਲਾਉਣਾ ਪੈਂਦਾ ਹੈ?
ਨਹੀਂ। ਵਰਤੋਂਕਾਰ ਬੱਸ ਇੱਕ script ਟੈਗ ਆਪਣੇ 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>
);
}ਗੱਲਬਾਤ ਹੱਲ ਹੋਣ ਉੱਤੇ ਕੀ ਹੁੰਦਾ ਹੈ?
ਹੱਲ ਹੋਣ ਤੋਂ ਬਾਅਦ ਆਇਆ ਨਵਾਂ ਸੁਨੇਹਾ ਪਿਛਲੀ ਗੱਲਬਾਤ ਨਾਲ ਜੁੜੀ ਅਗਲੇਰੀ (follow-up) ਗੱਲਬਾਤ ਆਪੇ ਖੋਲ੍ਹ ਦਿੰਦਾ ਹੈ (ਤੁਹਾਡੇ ਇਨਬਾਕਸ ਵਿੱਚ "Continued from #N" ਵਜੋਂ ਦਿਸਦੀ ਹੈ)। ਭਾਸ਼ਾ ਅਤੇ ਪਿਛਲੀ ਗੱਲਬਾਤ ਦਾ ਵੇਰਵਾ ਵਰਗਾ ਪ੍ਰਸੰਗ ਨਾਲ ਚਲਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਵਿਜ਼ਿਟਰ ਨੂੰ ਇੱਕੋ ਲਗਾਤਾਰ ਚੈਟ ਦਿਸਦੀ ਹੈ। ਜੇ ਹੱਲ ਹੋਈ ਗੱਲਬਾਤ ਕੋਈ ਟੀਮ ਮੈਂਬਰ ਸੰਭਾਲ ਰਿਹਾ ਸੀ, ਤਾਂ ਅਗਲੇਰੀ ਗੱਲਬਾਤ AI ਦੀ ਥਾਂ ਵਾਪਸ ਤੁਹਾਡੀ ਟੀਮ ਨੂੰ ਜਾਂਦੀ ਹੈ; ਨਹੀਂ ਤਾਂ AI ਹੀ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ।
ਵਿਜੇਟ ਕਿਵੇਂ ਲੋਡ ਹੁੰਦਾ ਹੈ?
ਵਿਜੇਟ ਅਸਿੰਕ ਢੰਗ ਨਾਲ ਲੋਡ ਹੁੰਦਾ ਹੈ (async), ਇਸ ਲਈ ਇਹ ਪੰਨੇ ਦੀ ਰੈਂਡਰਿੰਗ ਕਦੇ ਨਹੀਂ ਰੋਕਦਾ। ਮੂਲ ਬੰਡਲ ~180KB ਹੈ (gzip ਨਾਲ ~50KB); ਚੋਣਵੀਆਂ ਸਹੂਲਤਾਂ (ਮੁਹਿੰਮਾਂ, ਪ੍ਰੋਡਕਟ ਟੂਰ) ਵਿਜੇਟ ਦੇ ਮਾਊਂਟ ਹੋਣ ਮਗਰੋਂ ਵੱਖਰੇ lazy ਟੁਕੜਿਆਂ ਵਜੋਂ ਲੋਡ ਹੁੰਦੀਆਂ ਹਨ, ਇਸ ਲਈ ਪੰਨੇ ਦੀ ਪਹਿਲੀ ਰੈਂਡਰਿੰਗ ਕਦੇ ਨਹੀਂ ਰੁਕਦੀ।
ਐਸਕੇਲੇਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ?
ਵਰਤੋਂਕਾਰ “ਕਿਸੇ ਵਿਅਕਤੀ ਨਾਲ ਗੱਲ ਕਰੋ” ਬਟਨ ਦਬਾ ਸਕਦੇ ਹਨ, ਕਿਸੇ ਵਿਅਕਤੀ ਦੀ ਮੰਗ ਵਾਲਾ ਵਾਕ ਲਿਖ ਸਕਦੇ ਹਨ, ਜਾਂ AI ਆਪੇ ਗੱਲਬਾਤ ਸੌਂਪ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਉਹ ਤੁਹਾਡੇ ਗਿਆਨ ਅਧਾਰ ਤੋਂ ਜਵਾਬ ਨਾ ਦੇ ਸਕੇ। ਐਸਕੇਲੇਟ ਹੋਣ ਮਗਰੋਂ AI ਜਵਾਬ ਦੇਣਾ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ ਅਤੇ ਅਗਲੇ ਸਾਰੇ ਸੁਨੇਹੇ ਤੁਹਾਡੀ ਸਹਾਇਤਾ ਟੀਮ ਨੂੰ ਭੇਜ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਵੇਰਵੇ ਲਈ ਐਸਕੇਲੇਸ਼ਨ ਅਤੇ ਸੌਂਪਣੀ ਭਾਗ ਵੇਖੋ।
ਕੀ ਵਰਤੋਂਕਾਰ ਐਸਕੇਲੇਸ਼ਨ ਤੋਂ ਬਾਅਦ AI ਨਾਲ ਗੱਲ ਜਾਰੀ ਰੱਖ ਸਕਦੇ ਹਨ?
ਹਾਂ। ਵਿਜੇਟ “AI ਨਾਲ ਜਾਰੀ ਰੱਖੋ” ਬਟਨ ਦਿਖਾਉਂਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਵਰਤੋਂਕਾਰ ਐਸਕੇਲੇਸ਼ਨ ਹਟਾ ਕੇ AI ਨਾਲ ਗੱਲਬਾਤ ਮੁੜ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ।
ਨਾਲਜ ਬੇਸ ਅਤੇ ਵੈੱਬਸਾਈਟ ਕ੍ਰੌਲ#
ਮੇਰੀ ਵੈੱਬਸਾਈਟ ਦਾ ਕ੍ਰੌਲ ਬਲਾਕ ਕਿਉਂ ਹੈ?
"ਬਲਾਕ" ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਸਾਈਟ — ਜਾਂ ਇਸਦੀ ਸੁਰੱਖਿਆ ਪਰਤ (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 ਲਈ allow ਨਿਯਮ ਜੋੜੇ। Respondo ਕ੍ਰੌਲਰ ਦਾ ਕੋਈ ਪੱਕਾ IP ਪਤਾ ਪ੍ਰਕਾਸ਼ਿਤ ਨਹੀਂ ਕਰਦਾ — User-Agent ਦੇ ਆਧਾਰ 'ਤੇ ਇਜਾਜ਼ਤ ਦਿਓ; ਜੇ ਸਰੋਤ 'ਤੇ ਦਿਖਾਈ ਗਈ ਗਲਤੀ ਵਿੱਚ ਕੋਈ IP ਲਿਖਿਆ ਹੈ ਤਾਂ ਉਸਨੂੰ ਵੀ ਇਜਾਜ਼ਤ ਦਿਓ। ਜੇ ਸਾਈਟ ਬਦਲੀ ਨਹੀਂ ਜਾ ਸਕਦੀ ਤਾਂ ਉਹੀ ਸਮੱਗਰੀ ਫਾਈਲਾਂ ਜਾਂ ਪੇਸਟ ਕੀਤੇ ਟੈਕਸਟ ਵਜੋਂ ਜੋੜੋ।
ਕ੍ਰੌਲ ਪੂਰਾ ਹੋ ਗਿਆ ਪਰ ਸਿਰਫ਼ ਕੁਝ ਪੰਨੇ ਹੀ ਮਿਲੇ
ਅਸੀਂ ਪੰਨੇ ਸਾਈਟ ਦੇ sitemap (robots.txt ਵਿੱਚ Sitemap: ਲਾਈਨ ਜਾਂ /sitemap.xml ਵਰਗੀਆਂ ਆਮ ਥਾਵਾਂ) ਤੋਂ ਅਤੇ ਸ਼ੁਰੂਆਤੀ URL ਤੋਂ ਲਿੰਕ ਫਾਲੋ ਕਰਕੇ ਲੱਭਦੇ ਹਾਂ — ਵੱਧ ਤੋਂ ਵੱਧ 10 ਲਿੰਕ ਦੀ ਡੂੰਘਾਈ ਤੱਕ ਅਤੇ ਪ੍ਰਤੀ ਸਰੋਤ ਵੱਧ ਤੋਂ ਵੱਧ 5,000 ਪੰਨੇ। ਸਿਰਫ਼ ਉਸੇ ਸਾਈਟ ਦੇ ਅਤੇ ਸ਼ੁਰੂਆਤੀ URL ਦੇ ਪਾਥ ਹੇਠਲੇ ਪੰਨੇ ਹੀ ਇੰਪੋਰਟ ਹੁੰਦੇ ਹਨ: https://example.com/help ਤੋਂ ਸ਼ੁਰੂ ਕੀਤਾ ਕ੍ਰੌਲ /blog ਨੂੰ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਰੂਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ ਜਾਂ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੇ ਪਾਥ ਜੋੜੋ। ਜਿਨ੍ਹਾਂ ਪੰਨਿਆਂ ਵੱਲ ਕੋਈ ਲਿੰਕ ਜਾਂ sitemap ਇਸ਼ਾਰਾ ਨਹੀਂ ਕਰਦਾ, ਜਿਨ੍ਹਾਂ ਨੂੰ robots.txt ਮਨ੍ਹਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੋ ਲੌਗਇਨ ਦੇ ਪਿੱਛੇ ਹਨ, ਉਹ ਨਹੀਂ ਮਿਲਦੇ। ਲਗਭਗ ਇੱਕੋ ਜਿਹੇ ਪੰਨੇ (ਪ੍ਰਿੰਟ ਵਰਜਨ, ਟਰੈਕਿੰਗ ਪੈਰਾਮੀਟਰਾਂ ਵਾਲੇ ਰੂਪ) ਇੱਕ ਵਿੱਚ ਮਿਲਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਜਿਨ੍ਹਾਂ ਪੰਨਿਆਂ ਦੀ ਸਮੱਗਰੀ ਪੂਰੀ ਤਰ੍ਹਾਂ JavaScript ਨਾਲ ਬਣਦੀ ਹੈ, ਉਨ੍ਹਾਂ ਨੂੰ ਪਛਾਣ ਕੇ ਬ੍ਰਾਊਜ਼ਰ-ਆਧਾਰਿਤ ਬਦਲਵੇਂ ਤਰੀਕੇ ਨਾਲ ਰੈਂਡਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਇਸ ਲਈ ਘੱਟ ਪੰਨਿਆਂ ਦੀ ਗਿਣਤੀ ਆਮ ਤੌਰ 'ਤੇ ਦਾਇਰੇ ਜਾਂ sitemap ਦੀ ਸਮੱਸਿਆ ਦੱਸਦੀ ਹੈ, ਰੈਂਡਰਿੰਗ ਦੀ ਨਹੀਂ।
ਕ੍ਰੌਲ ਨੂੰ ਸਾਈਟ ਦੇ ਇੱਕ ਹਿੱਸੇ ਤੱਕ ਕਿਵੇਂ ਸੀਮਤ ਕਰਾਂ?
ਵੈੱਬਸਾਈਟ ਜੋੜਨ ਵਾਲੇ ਡਾਇਲੌਗ ਵਿੱਚ Advanced ਖੋਲ੍ਹੋ ਅਤੇ Only crawl paths starting with (ਸਿਰਫ਼ ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਪਾਥ ਕ੍ਰੌਲ ਕਰੋ) ਅਤੇ/ਜਾਂ Skip paths starting with (ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੇ ਪਾਥ ਛੱਡੋ) ਭਰੋ — ਹਰ ਲਾਈਨ ਵਿੱਚ ਇੱਕ ਪਾਥ, ਪ੍ਰਤੀ ਫੀਲਡ ਵੱਧ ਤੋਂ ਵੱਧ 50। ਮਿਲਾਨ ਪੂਰੇ ਪਾਥ ਸੈਗਮੈਂਟਾਂ ਦੇ ਆਧਾਰ 'ਤੇ ਹੁੰਦਾ ਹੈ: /docs ਦਾ ਮਿਲਾਨ /docs ਅਤੇ /docs/getting-started ਨਾਲ ਹੁੰਦਾ ਹੈ, ਪਰ /docs-archive ਨਾਲ ਨਹੀਂ; ਅੰਤਲੇ ਸਲੈਸ਼ ਨੂੰ ਅਣਡਿੱਠਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਪੂਰਾ URL ਪੇਸਟ ਕਰ ਸਕਦੇ ਹੋ — ਸਿਰਫ਼ ਇਸਦਾ ਪਾਥ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਛੱਡਣ ਵਾਲੇ ਨਿਯਮ ਸ਼ਾਮਲ ਕਰਨ ਵਾਲੇ ਨਿਯਮਾਂ 'ਤੇ ਭਾਰੂ ਹੁੰਦੇ ਹਨ। ਇਹੀ ਨਿਯਮ sitemap 'ਤੇ ਅਤੇ ਉਸ ਸਰੋਤ ਦੇ ਹਰ ਅਗਲੇ ਰੀ-ਸਿੰਕ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ।
Respondo ਮੇਰੀ ਵੈੱਬਸਾਈਟ ਨੂੰ ਕਿੰਨੀ ਵਾਰ ਦੁਬਾਰਾ ਕ੍ਰੌਲ ਕਰਦਾ ਹੈ?
ਹਰ ਵੈੱਬਸਾਈਟ ਸਰੋਤ ਦੇ ਪੰਨਿਆਂ ਦੇ ਪੈਨਲ ਵਿੱਚ ਇੱਕ Auto-refresh ਸ਼ਡਿਊਲ ਹੁੰਦਾ ਹੈ: Off (ਬੰਦ), Daily (ਹਰ 24 ਘੰਟੇ) ਜਾਂ Weekly (ਹਰ 7 ਦਿਨ)। ਸ਼ਡਿਊਲ ਕੀਤਾ ਕ੍ਰੌਲ ਇੰਕ੍ਰੀਮੈਂਟਲ ਹੁੰਦਾ ਹੈ: ਜਿਨ੍ਹਾਂ ਪੰਨਿਆਂ ਦਾ sitemap ਵਿੱਚ lastmod ਪਿਛਲੇ ਕ੍ਰੌਲ ਤੋਂ ਪੁਰਾਣਾ ਹੈ ਉਹ ਛੱਡ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ, ਨਾ ਬਦਲੇ ਪੰਨੇ ਦੁਬਾਰਾ ਇੰਡੈਕਸ ਨਹੀਂ ਹੁੰਦੇ, ਬਦਲੇ ਹੋਏ ਪੰਨੇ ਦੁਬਾਰਾ ਇੰਡੈਕਸ ਹੁੰਦੇ ਹਨ ਅਤੇ ਗਾਇਬ ਹੋਏ ਪੰਨੇ ਹਟਾ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਤੁਰੰਤ ਰਿਫ੍ਰੈਸ਼ ਕਰਨ ਲਈ ਸਰੋਤ ਮੀਨੂ ਵਿੱਚ Re-sync ਜਾਂ Knowledge ਪੰਨੇ 'ਤੇ Re-sync all ਵਰਤੋ।
"ਇਸ ਵਾਰ ਅਸੀਂ ਸਾਈਟ ਨਹੀਂ ਪੜ੍ਹ ਸਕੇ" — ਕੀ ਹੋਇਆ?
ਇਹ ਆਮ ਅਸਫਲਤਾ ਹੈ: ਸਾਈਟ ਨੇ ਸਮੇਂ ਸਿਰ ਜਵਾਬ ਨਹੀਂ ਦਿੱਤਾ, ਡੋਮੇਨ ਰਿਜ਼ੌਲਵ ਨਹੀਂ ਹੋਇਆ, ਸਰਵਰ ਨੇ ਗਲਤੀ ਵਾਪਸ ਕੀਤੀ, ਸ਼ੁਰੂਆਤੀ ਪੰਨੇ 'ਤੇ ਪੜ੍ਹਨਯੋਗ ਟੈਕਸਟ ਨਹੀਂ ਸੀ, ਜਾਂ ਪਤਾ ਨਹੀਂ ਮਿਲਿਆ। ਵੇਰਵਾ ਸਰੋਤ 'ਤੇ ਦਿਖਾਇਆ ਜਾਂਦਾ ਹੈ। ਜਾਂਚੋ ਕਿ URL ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਪ੍ਰਾਈਵੇਟ ਵਿੰਡੋ ਵਿੱਚ ਖੁੱਲ੍ਹਦਾ ਹੈ, ਡੋਮੇਨ ਵਿੱਚ ਕੋਈ ਟਾਈਪੋ ਨਹੀਂ ਹੈ ਅਤੇ ਸ਼ੁਰੂਆਤੀ ਪੰਨਾ ਲੌਗਇਨ ਸਕ੍ਰੀਨ ਨਹੀਂ ਸਗੋਂ ਅਸਲ ਸਮੱਗਰੀ ਵਾਲਾ ਪੰਨਾ ਹੈ। ਸੋਸ਼ਲ ਨੈੱਟਵਰਕ ਅਤੇ ਮੈਸੇਜਿੰਗ ਪਲੇਟਫਾਰਮ (Facebook, Instagram, LinkedIn, X, YouTube ਅਤੇ ਇਸੇ ਤਰ੍ਹਾਂ ਦੇ) ਬਿਲਕੁਲ ਇੰਪੋਰਟ ਨਹੀਂ ਕੀਤੇ ਜਾ ਸਕਦੇ — ਉਹ ਕ੍ਰੌਲ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੱਦ ਹੋ ਜਾਂਦੇ ਹਨ। ਤੁਹਾਡੇ ਮੌਜੂਦਾ ਪੰਨੇ ਬਣੇ ਰਹਿੰਦੇ ਹਨ; ਸ਼ਡਿਊਲ ਵਾਲਾ ਸਰੋਤ ਅਗਲੀ ਰਨ ਵਿੱਚ ਫਿਰ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਨਹੀਂ ਤਾਂ ਸਾਈਟ ਦੁਬਾਰਾ ਉਪਲਬਧ ਹੋਣ 'ਤੇ ਰੀ-ਸਿੰਕ ਕਰੋ।
"ਸਾਡਾ ਸਰਚ ਇੰਡੈਕਸ ਭਰ ਗਿਆ ਹੈ" ਅਤੇ "ਅਸੀਂ ਇਸ ਸਰੋਤ ਨੂੰ ਇੰਡੈਕਸ ਨਹੀਂ ਕਰ ਸਕੇ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ?
ਦੋਵੇਂ ਸੁਨੇਹੇ ਸਮੱਗਰੀ ਸਫਲਤਾਪੂਰਵਕ ਪੜ੍ਹੇ ਜਾਣ ਤੋਂ ਬਾਅਦ ਦਿਖਦੇ ਹਨ। ਇੰਡੈਕਸ ਭਰ ਗਿਆ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਜਿਸ ਸਰਚ ਇੰਡੈਕਸ ਵਿੱਚ ਇਹ ਸਰੋਤ ਕਾਪੀ ਹੁੰਦਾ ਹੈ, ਉਸ ਵਿੱਚ Respondo ਵਾਲੇ ਪਾਸੇ ਥਾਂ ਨਹੀਂ ਹੈ — ਇਹ Respondo ਦੀ ਸੀਮਾ ਹੈ, ਤੁਹਾਡੀ ਸਮੱਗਰੀ ਦੀ ਸਮੱਸਿਆ ਨਹੀਂ। ਪੰਨੇ ਸਟੋਰ ਹਨ, ਜੋ ਕੁਝ ਪਹਿਲਾਂ ਹੀ ਇੰਡੈਕਸ ਹੈ ਉਹ ਜਵਾਬ ਦਿੰਦਾ ਰਹਿੰਦਾ ਹੈ, ਸਾਡੀ ਟੀਮ ਨੂੰ ਆਪਣੇ ਆਪ ਸੂਚਨਾ ਮਿਲ ਜਾਂਦੀ ਹੈ ਅਤੇ ਥਾਂ ਬਣਦਿਆਂ ਹੀ ਸਰੋਤ ਇੰਡੈਕਸ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ; ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਰੀ-ਸਿੰਕ ਇਸੇ ਤਰ੍ਹਾਂ ਅਸਫਲ ਹੋਵੇਗਾ। ਅਸੀਂ ਇਸ ਸਰੋਤ ਨੂੰ ਇੰਡੈਕਸ ਨਹੀਂ ਕਰ ਸਕੇ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਇਸ ਵਾਰ ਸਰਚ ਇੰਡੈਕਸ ਬਣਾਉਣਾ ਅਸਫਲ ਰਿਹਾ — ਸਾਡੇ ਪਾਸੇ ਦੀ ਅਸਥਾਈ ਗਲਤੀ; ਮੌਜੂਦਾ ਡੇਟਾ ਸੁਰੱਖਿਅਤ ਹੈ ਅਤੇ ਕੰਮ ਆਪਣੇ ਆਪ ਦੁਬਾਰਾ ਅਜ਼ਮਾਇਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਸੁਨੇਹਾ ਬਣਿਆ ਰਹੇ ਤਾਂ ਗਲਤੀ 'ਤੇ "Copilot ਤੋਂ ਪੁੱਛੋ" ਵਰਤੋ।
ਕੀ ਲੰਬੇ ਪੰਨਿਆਂ ਦਾ ਜਵਾਬ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਤੋਂ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ?
ਨਹੀਂ। ਹਰ ਕ੍ਰੌਲ ਕੀਤਾ ਪੰਨਾ ਲਗਭਗ 1,600 ਅੱਖਰਾਂ ਦੇ ਇੱਕ-ਦੂਜੇ 'ਤੇ ਓਵਰਲੈਪ ਕਰਦੇ ਟੁਕੜਿਆਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਹਰ ਟੁਕੜਾ ਪੰਨੇ ਦੇ ਸਿਰਲੇਖ ਨਾਲ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਇੰਡੈਕਸ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਜਵਾਬ ਕਿਸੇ ਲੰਬੇ ਲੇਖ ਦੇ ਕਿਸੇ ਵੀ ਹਿੱਸੇ ਤੋਂ ਆ ਸਕਦਾ ਹੈ। ਹਵਾਲੇ ਅਜੇ ਵੀ ਪ੍ਰਤੀ ਪੰਨਾ ਇੱਕ ਲਿੰਕ ਦਿਖਾਉਂਦੇ ਹਨ। ਇਸ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਇੰਪੋਰਟ ਕੀਤੇ ਪੰਨੇ ਆਪਣੇ ਅਗਲੇ ਰੀ-ਸਿੰਕ ਵਿੱਚ ਦੁਬਾਰਾ ਵੰਡੇ ਜਾਂਦੇ ਹਨ।
ਕ੍ਰੌਲ ਗਲਤੀ ਲਈ ਮਦਦ ਕਿਵੇਂ ਲਵਾਂ?
Knowledge ਪੰਨੇ 'ਤੇ ਹਰ ਕ੍ਰੌਲ ਜਾਂ ਇੰਡੈਕਸਿੰਗ ਗਲਤੀ ਨਾਲ Copilot ਤੋਂ ਪੁੱਛੋ ਬਟਨ ਹੁੰਦਾ ਹੈ। ਇਹ ਗਲਤੀ ਨੱਥੀ ਕਰਕੇ Copilot ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ Copilot ਤੁਹਾਡੇ ਕੇਸ ਲਈ ਠੋਸ ਕਦਮਾਂ ਨਾਲ Respondo ਦੇ ਆਪਣੇ ਮਦਦ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਮਦਦ ਮੁਫ਼ਤ ਹੈ — ਇਹ ਤੁਹਾਡੀਆਂ AI ਬੇਨਤੀਆਂ ਵਿੱਚ ਨਹੀਂ ਗਿਣੀ ਜਾਂਦੀ। ਜੇ ਕਦਮਾਂ ਨਾਲ ਸਮੱਸਿਆ ਹੱਲ ਨਾ ਹੋਵੇ ਤਾਂ ਬੱਸ ਇਹੀ ਕਹਿ ਦਿਓ — "ਇਸ ਨਾਲ ਮਦਦ ਨਹੀਂ ਮਿਲੀ" ਕਾਫ਼ੀ ਹੈ। ਫਿਰ Copilot ਇੱਕ ਕਾਰਡ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਸਮੱਸਿਆ Respondo ਟੀਮ ਨੂੰ ਸੌਂਪਦਾ ਹੈ: ਕਾਰਡ ਵਿੱਚ ਠੀਕ-ਠੀਕ ਲਿਖਿਆ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਭੇਜਿਆ ਜਾਵੇਗਾ, ਤੁਹਾਡੀ ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਨਹੀਂ ਜਾਂਦਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਜਵਾਬ ਉਸੇ Copilot ਥ੍ਰੈੱਡ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਜੇ ਇੱਥੋਂ ਸੌਂਪਣਾ ਸੰਭਵ ਨਾ ਹੋਵੇ ਤਾਂ Copilot ਚੁੱਪ ਰਹਿਣ ਦੀ ਬਜਾਏ ਸਾਫ਼ ਦੱਸ ਦਿੰਦਾ ਹੈ।
ਸੁਨੇਹੇ ਜੋ ਗਾਹਕ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੇ#
ਜਵਾਬ 'ਤੇ "Not delivered" ਲਿਖਿਆ ਹੈ — ਇਸਦਾ ਕੀ ਮਤਲਬ ਹੈ ਅਤੇ ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਕੀ ਕਰਾਂ?
ਇਨਬਾਕਸ ਵਿੱਚ ਹਰ ਬਾਹਰ ਜਾਂਦੇ ਸੁਨੇਹੇ ਨਾਲ ਇੱਕ ਡਿਲੀਵਰੀ ਸੰਕੇਤਕ ਹੁੰਦਾ ਹੈ: Queued (ਥੋੜ੍ਹੇ-ਥੋੜ੍ਹੇ ਵਕਫ਼ੇ ਨਾਲ ਲਿਖੇ ਜਵਾਬ ਇਕੱਠੇ ਜੋੜ ਕੇ ਕੁਝ ਮਿੰਟਾਂ ਵਿੱਚ ਇੱਕੋ ਈਮੇਲ ਵਜੋਂ ਭੇਜੇ ਜਾਂਦੇ ਹਨ), Sending…, Sent, Delivered, ਜਾਂ ਲਾਲ ਰੰਗ ਵਿੱਚ ਅਸਫਲਤਾ। ਅਸਫਲਤਾ ਤਿੰਨ ਰੂਪਾਂ ਵਿੱਚ ਆਉਂਦੀ ਹੈ: Not delivered — ਚੈਨਲ ਨੇ ਸੁਨੇਹਾ ਲੈਣ ਤੋਂ ਹੀ ਨਾਂਹ ਕਰ ਦਿੱਤੀ; Bounced ਅਤੇ ਨਾਲ ਬਾਊਂਸ ਦੀ ਉਪ-ਕਿਸਮ — ਪ੍ਰਾਪਤਕਰਤਾ ਦੇ ਮੇਲ ਸਰਵਰ ਨੇ ਈਮੇਲ ਰੱਦ ਕਰ ਦਿੱਤੀ; ਅਤੇ Marked as spam — ਪ੍ਰਾਪਤਕਰਤਾ ਨੇ ਇਸਦੀ ਸ਼ਿਕਾਇਤ ਕੀਤੀ। ਲੇਬਲ 'ਤੇ ਹੋਵਰ ਕਰੋ ਜਾਂ ਕਲਿੱਕ ਕਰੋ: ਟੂਲਟਿਪ ਵਿੱਚ ਪ੍ਰੋਵਾਈਡਰ ਦੇ ਆਪਣੇ ਸ਼ਬਦ ਹੁੰਦੇ ਹਨ, ਬਾਊਂਸ ਲਈ ਕੱਚਾ SMTP ਡਾਇਗਨੌਸਟਿਕ ਵੀ। ਨਾਲ ਹੀ ਵੱਧ ਤੋਂ ਵੱਧ ਦੋ ਕਾਰਵਾਈਆਂ ਹੁੰਦੀਆਂ ਹਨ — Retry / Send again, ਜੋ ਸੱਚਮੁੱਚ ਦੁਬਾਰਾ ਭੇਜਦਾ ਹੈ, ਅਤੇ Ask Copilot (Copilot ਤੋਂ ਪੁੱਛੋ), ਜੋ ਗਲਤੀ ਨੱਥੀ ਕਰਕੇ Copilot ਖੋਲ੍ਹਦਾ ਹੈ। ਜੇ ਦੁਬਾਰਾ ਭੇਜਣ ਵਾਲਾ ਬਟਨ ਬਿਲਕੁਲ ਹੀ ਨਹੀਂ ਹੈ ਤਾਂ ਪਤਾ ਬਲਾਕ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਭੇਜਣਾ ਉਸੇ ਤਰ੍ਹਾਂ ਅਸਫਲ ਹੋਵੇਗਾ। ਜਿਸ Sent ਜਾਂ Delivered ਦੇ ਨਾਲ N files not delivered ਲਿਖਿਆ ਹੋਵੇ, ਉਸਦਾ ਮਤਲਬ ਹੈ ਟੈਕਸਟ ਪਹੁੰਚ ਗਿਆ ਪਰ ਅਟੈਚਮੈਂਟ ਨਹੀਂ — ਉਹ ਚੈਨਲ ਫਾਈਲ ਨਹੀਂ ਲਿਜਾ ਸਕਿਆ।
ਮੇਰੀ ਈਮੇਲ ਗਾਹਕ ਤੱਕ ਕਿਉਂ ਨਹੀਂ ਪਹੁੰਚੀ?
ਚਾਰ ਵੱਖ-ਵੱਖ ਕਾਰਨ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਲੇਬਲ ਹੀ ਇਨ੍ਹਾਂ ਨੂੰ ਵੱਖ ਕਰਦਾ ਹੈ। ਪੱਕਾ ਬਾਊਂਸ ਦਾ ਮਤਲਬ ਹੈ ਪਤਾ ਮੌਜੂਦ ਹੀ ਨਹੀਂ ਜਾਂ ਮੇਲ ਲੈਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ — ਦੁਬਾਰਾ ਭੇਜਣ ਦਾ ਬਟਨ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਪਤਾ ਸਪ੍ਰੈਸ਼ਨ ਸੂਚੀ ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ। ਆਰਜ਼ੀ ਬਾਊਂਸ ਭਰਿਆ ਹੋਇਆ ਮੇਲਬਾਕਸ ਜਾਂ ਪ੍ਰਾਪਤ ਕਰਨ ਵਾਲੇ ਸਰਵਰ ਦੀ ਲੰਘ ਜਾਣ ਵਾਲੀ ਸਮੱਸਿਆ ਹੁੰਦੀ ਹੈ; Send again ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਬਾਅਦ ਵਿੱਚ ਕੰਮ ਕਰ ਜਾਂਦਾ ਹੈ। ਜਿਸ ਬਾਊਂਸ ਦੇ ਡਾਇਗਨੌਸਟਿਕ ਵਿੱਚ SPF, DKIM, DMARC ਜਾਂ 5.7.515 ਦਾ ਜ਼ਿਕਰ ਹੋਵੇ, ਉਹ ਵੱਖਰੀ ਗੱਲ ਹੈ: ਪ੍ਰਾਪਤਕਰਤਾ ਦੇ ਮੇਲ ਸਿਸਟਮ ਨੇ ਸੁਨੇਹਾ ਇਸ ਲਈ ਰੱਦ ਕੀਤਾ ਕਿਉਂਕਿ ਤੁਹਾਡਾ ਭੇਜਣ ਵਾਲਾ ਡੋਮੇਨ ਪ੍ਰਮਾਣਿਕਤਾ ਜਾਂਚ ਵਿੱਚ ਫੇਲ੍ਹ ਹੋਇਆ। ਡੋਮੇਨ ਠੀਕ ਹੋਣ ਤੱਕ ਹਰ ਨਵਾਂ ਜਵਾਬ ਬਿਲਕੁਲ ਇਸੇ ਤਰ੍ਹਾਂ ਬਾਊਂਸ ਹੋਵੇਗਾ, ਇਸ ਲਈ ਉਦੋਂ ਤੱਕ ਕਿਸੇ ਹੋਰ ਚੈਨਲ ਵਿੱਚ ਜਵਾਬ ਦਿਓ ਅਤੇ Settings → Channels ਵਿੱਚ ਈਮੇਲ ਚੈਨਲ ਦੇ DNS ਰਿਕਾਰਡ ਠੀਕ ਕਰੋ। ਅੰਤ ਵਿੱਚ, Marked as spam ਦਾ ਮਤਲਬ ਹੈ ਪ੍ਰਾਪਤਕਰਤਾ ਨੇ "report spam" ਦਬਾਇਆ: ਪਤਾ ਸਪ੍ਰੈੱਸ ਹੋ ਜਾਂਦਾ ਹੈ ਅਤੇ ਅਸੀਂ ਉਸ 'ਤੇ ਭੇਜਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਾਂ। ਮੁਹਿੰਮ ਦੀ ਰਿਪੋਰਟ ਵਿੱਚ ਇਸ ਤੋਂ ਇਲਾਵਾ The email provider rejected this message ਵੀ ਦਿਖ ਸਕਦਾ ਹੈ — ਈਮੇਲ ਦੇ ਰਵਾਨਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਪੱਕਾ ਇਨਕਾਰ, ਆਮ ਤੌਰ 'ਤੇ ਗੈਰ-ਪ੍ਰਮਾਣਿਤ ਭੇਜਣ ਵਾਲਾ ਡੋਮੇਨ ਜਾਂ ਗਲਤ ਬਣਤਰ ਵਾਲਾ ਪਤਾ — ਅਤੇ The email provider rejected our credentials, ਜੋ ਉਸ ਇੱਕ ਸੰਪਰਕ ਨਾਲ ਨਹੀਂ ਸਗੋਂ ਵਰਕਸਪੇਸ ਦੇ ਸੈੱਟਅੱਪ ਨਾਲ ਜੁੜੀ ਸਮੱਸਿਆ ਹੈ।
ਸਪ੍ਰੈਸ਼ਨ ਸੂਚੀ ਕੀ ਹੈ, ਅਤੇ ਕੋਈ ਪਤਾ ਇਸ ਵਿੱਚੋਂ ਕਿਵੇਂ ਨਿਕਲਦਾ ਹੈ?
ਇਹ ਤੁਹਾਡੇ ਵਰਕਸਪੇਸ ਦੀ ਨਿੱਜੀ ਸੂਚੀ ਹੈ ਜਿਸ ਵਿੱਚ ਉਹ ਈਮੇਲ ਪਤੇ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ Respondo ਭੇਜਣ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ। ਪਤਾ ਇਸ ਵਿੱਚ ਉਦੋਂ ਆਉਂਦਾ ਹੈ ਜਦੋਂ ਕੋਈ ਸੁਨੇਹਾ ਹਾਰਡ-ਬਾਊਂਸ ਹੁੰਦਾ ਹੈ (ਪੱਕਾ ਇਨਕਾਰ), ਜਦੋਂ ਕੋਈ ਤੁਹਾਡੀ ਈਮੇਲ ਨੂੰ ਸਪੈਮ ਦੱਸਦਾ ਹੈ, ਜਾਂ ਜਦੋਂ ਉਸਨੂੰ ਹੱਥੀਂ ਬਲਾਕ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਸਾਫਟ ਬਾਊਂਸ ਕਦੇ ਵੀ ਪਤਾ ਸਪ੍ਰੈੱਸ ਨਹੀਂ ਕਰਦੇ। ਜਦੋਂ ਤੱਕ ਬਲਾਕ ਲਾਗੂ ਹੈ, ਮੁਹਿੰਮ ਦੀਆਂ ਡਿਲੀਵਰੀਆਂ 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 ਸਪੋਰਟ ਨੂੰ ਕਹਿ ਸਕਦਾ ਹੈ। ਹਾਰਡ ਬਾਊਂਸ ਸਿਰਫ਼ ਉਦੋਂ ਖੋਲ੍ਹੋ ਜਦੋਂ ਤੁਹਾਨੂੰ ਪਤਾ ਹੋਵੇ ਕਿ ਮੇਲਬਾਕਸ ਸੱਚਮੁੱਚ ਠੀਕ ਹੋ ਗਿਆ ਹੈ — ਮਰੇ ਹੋਏ ਪਤੇ 'ਤੇ ਦੁਬਾਰਾ ਭੇਜਣਾ ਤੁਹਾਡੇ ਡੋਮੇਨ ਦੀ ਸਾਖ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦਾ ਹੈ।
WhatsApp ਮੇਰਾ ਜਵਾਬ ਨਹੀਂ ਲੈ ਰਿਹਾ — 24-ਘੰਟੇ ਦੀ ਵਿੰਡੋ
WhatsApp ਕਾਰੋਬਾਰ ਨੂੰ ਖੁੱਲ੍ਹੇ ਸੁਨੇਹੇ ਸਿਰਫ਼ ਗਾਹਕ ਦੇ ਆਖ਼ਰੀ ਸੁਨੇਹੇ ਤੋਂ 24 ਘੰਟਿਆਂ ਦੇ ਅੰਦਰ ਭੇਜਣ ਦਿੰਦਾ ਹੈ; ਇਸ ਤੋਂ ਬਾਅਦ Meta ਹਰ ਚੀਜ਼ ਨੂੰ 131047 ਗਲਤੀ ਨਾਲ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ। Respondo ਹਰ ਵਿਅਕਤੀ ਲਈ ਇਹ ਵਿੰਡੋ ਟਰੈਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਉਸਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਵਿੰਡੋ ਖ਼ਤਮ ਹੋ ਚੁੱਕੀ ਹੈ ਤਾਂ ਜਵਾਬ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਰੋਕ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ Respondo ਕੋਲ ਵਿੰਡੋ ਦਾ ਕੋਈ ਰਿਕਾਰਡ ਹੀ ਨਹੀਂ ਹੁੰਦਾ — ਇੰਪੋਰਟ ਕੀਤਾ ਸੰਪਰਕ, ਜਾਂ ਅਜਿਹਾ ਨੰਬਰ ਜਿਸਨੇ ਤੁਹਾਨੂੰ ਕਦੇ ਲਿਖਿਆ ਹੀ ਨਹੀਂ — ਤਾਂ ਉਹ ਨਹੀਂ ਰੋਕਦਾ: ਸੁਨੇਹਾ Meta ਕੋਲ ਜਾਂਦਾ ਹੈ ਅਤੇ ਫ਼ੈਸਲਾ Meta ਕਰਦਾ ਹੈ। ਅੱਗੇ ਵਧਣ ਦੇ ਠੀਕ ਦੋ ਰਾਹ ਹਨ। ਜਾਂ ਤਾਂ ਗਾਹਕ ਦੇ ਦੁਬਾਰਾ ਲਿਖਣ ਦੀ ਉਡੀਕ ਕਰੋ — ਉਸਦਾ ਸੁਨੇਹਾ ਵਿੰਡੋ ਨੂੰ ਹੋਰ 24 ਘੰਟਿਆਂ ਲਈ ਖੋਲ੍ਹ ਦਿੰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਤੁਹਾਡਾ ਜਵਾਬ ਚਲਾ ਜਾਂਦਾ ਹੈ — ਜਾਂ 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" — ਪਹੁੰਚਣ ਲਈ ਚੈਨਲ ਜਾਂ ਪਤਾ ਨਹੀਂ
ਇਹ ਦੋਵੇਂ ਇਨਬਾਕਸ ਵਿੱਚ ਨਹੀਂ ਸਗੋਂ ਮੁਹਿੰਮ ਦੀ ਡਿਲੀਵਰੀ ਰਿਪੋਰਟ ਵਿੱਚ ਦਿਖਦੇ ਹਨ। ਪਹਿਲੇ ਦਾ ਮਤਲਬ ਹੈ ਸੰਪਰਕ ਦਾ ਕੋਈ ਵੀ ਪਤਾ ਉਨ੍ਹਾਂ ਚੈਨਲਾਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ ਜਿਨ੍ਹਾਂ 'ਤੇ ਮੁਹਿੰਮ ਭੇਜਦੀ ਹੈ; ਜੇ ਉਸਦਾ ਇੱਕੋ-ਇੱਕ ਪਤਾ ਸਿਰਫ਼-ਪ੍ਰਾਪਤੀ ਵਾਲੇ ਚੈਨਲ 'ਤੇ ਹੈ ਤਾਂ ਇਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਣ-ਬੁੱਝ ਕੇ ਛੱਡੀ ਗਈ ਡਿਲੀਵਰੀ ਵਜੋਂ ਦਰਜ ਹੁੰਦਾ ਹੈ। ਦੂਜੇ ਦਾ ਮਤਲਬ ਹੈ ਮੁਹਿੰਮ ਈਮੇਲ ਭੇਜਦੀ ਹੈ ਪਰ ਸੰਪਰਕ ਦਾ ਕੋਈ ਪਤਾ ਦਰਜ ਨਹੀਂ। Telegram ਦਾ ਆਪਣਾ ਰੂਪ ਹੈ: ਜੇ ਵਿਅਕਤੀ ਨੇ ਤੁਹਾਡੇ ਬੋਟ ਨੂੰ ਕਦੇ ਲਿਖਿਆ ਹੀ ਨਹੀਂ ਤਾਂ ਲਿਖਣ ਲਈ ਕੋਈ ਚੈਟ ਹੀ ਨਹੀਂ ਹੁੰਦੀ, ਕਿਉਂਕਿ Bot API ਬੋਟ ਨੂੰ ਪਹਿਲਾਂ ਸੁਨੇਹਾ ਭੇਜਣ ਤੋਂ ਮਨ੍ਹਾ ਕਰਦਾ ਹੈ — ਪਹਿਲਾ ਸੁਨੇਹਾ ਉਨ੍ਹਾਂ ਨੂੰ ਹੀ ਭੇਜਣਾ ਪੈਂਦਾ ਹੈ। ਇਸਨੂੰ ਸੰਪਰਕ ਵਿੱਚ ਗੁੰਮ ਪਤਾ ਜੋੜ ਕੇ, ਮੁਹਿੰਮ ਦੇ ਚੈਨਲਾਂ ਦਾ ਦਾਇਰਾ ਵਧਾ ਕੇ, ਜਾਂ ਉਸਨੂੰ ਈਮੇਲ 'ਤੇ ਵਾਪਸ ਡਿੱਗਣ ਦੇ ਕੇ ਠੀਕ ਕਰੋ।
ਸੰਪਰਕ ਨੇ ਅਨਸਬਸਕ੍ਰਾਈਬ ਕਰ ਦਿੱਤਾ — ਮੈਂ ਕੀ ਭੇਜ ਸਕਦਾ ਹਾਂ?
They had already unsubscribed ਦਾ ਮਤਲਬ ਹੈ ਸੰਪਰਕ 'ਤੇ ਗਲੋਬਲ ਓਪਟ-ਆਊਟ ਲੱਗਾ ਹੈ — ਤੁਹਾਡੀ ਕਿਸੇ ਈਮੇਲ ਦੇ ਅਨਸਬਸਕ੍ਰਾਈਬ ਲਿੰਕ ਰਾਹੀਂ, ਇੰਪੋਰਟ ਨਾਲ ਆਇਆ, ਜਾਂ ਕਿਸੇ ਸਾਥੀ ਨੇ ਲਾਇਆ। ਮੁਹਿੰਮਾਂ ਅਤੇ ਸੀਰੀਜ਼ ਅਜਿਹੇ ਸੰਪਰਕਾਂ ਨੂੰ ਹਰ ਚੈਨਲ 'ਤੇ ਛੱਡ ਦਿੰਦੀਆਂ ਹਨ, ਸਿਰਫ਼ ਈਮੇਲ 'ਤੇ ਨਹੀਂ, ਅਤੇ ਡਿਲੀਵਰੀ ਅਸਫਲਤਾ ਵਜੋਂ ਨਹੀਂ ਸਗੋਂ ਛੱਡੀ ਗਈ ਵਜੋਂ ਦਰਜ ਹੁੰਦੀ ਹੈ। ਗੱਲਬਾਤ ਵਿੱਚ ਕਿਸੇ ਸਾਥੀ ਦਾ ਇੱਕ-ਤੋਂ-ਇੱਕ ਜਵਾਬ ਜਾਣ-ਬੁੱਝ ਕੇ ਇਸ ਨਾਲ ਨਹੀਂ ਰੁਕਦਾ: ਓਪਟ-ਆਊਟ ਸਮੂਹਿਕ ਭੇਜਣ ਬਾਰੇ ਹੈ, ਅਤੇ ਜਿਸ ਵਿਅਕਤੀ ਨੇ ਤੁਹਾਨੂੰ ਲਿਖਿਆ ਉਸਨੂੰ ਜਵਾਬ ਦੇਣਾ ਇਨਸਾਨੀ ਫ਼ੈਸਲਾ ਹੈ। ਇਹ ਸਥਿਤੀ ਸੰਪਰਕ 'ਤੇ Outbound: Subscribed / Unsubscribed ਵਜੋਂ ਦਿਖਦੀ ਹੈ, ਸੰਪਰਕ ਸੂਚੀ ਨੂੰ ਇਸ ਹਿਸਾਬ ਨਾਲ ਫਿਲਟਰ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਸੰਪਰਕ 'ਤੇ Re-subscribe ਬਟਨ ਇਸਨੂੰ ਉਲਟਾ ਦਿੰਦਾ ਹੈ — ਇਸਨੂੰ ਸਿਰਫ਼ ਉਦੋਂ ਵਰਤੋ ਜਦੋਂ ਵਿਅਕਤੀ ਨੇ ਖ਼ੁਦ ਕਿਹਾ ਹੋਵੇ।
ਤੁਸੀਂ ਕਿੰਨੀ ਵਾਰ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ, ਅਤੇ ਕੀ Retry ਦਬਾਉਣਾ ਸੁਰੱਖਿਅਤ ਹੈ?
ਇਨਬਾਕਸ ਤੋਂ ਭੇਜਿਆ ਜਵਾਬ ਇੱਕ ਕਤਾਰ ਨੂੰ ਸੌਂਪਿਆ ਜਾਂਦਾ ਹੈ ਜੋ ਵੱਧ ਤੋਂ ਵੱਧ ਪੰਜ ਕੋਸ਼ਿਸ਼ਾਂ ਕਰਦੀ ਹੈ, ਵਿਚਕਾਰ ਲਗਭਗ 3, 10, 30 ਅਤੇ 30 ਮਿੰਟ ਦੀ ਉਡੀਕ ਨਾਲ। ਸਿਰਫ਼ ਆਰਜ਼ੀ ਅਸਫਲਤਾਵਾਂ ਦੁਬਾਰਾ ਅਜ਼ਮਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ — ਟਾਈਮਆਊਟ, ਠੁਕਰਾਏ ਕਨੈਕਸ਼ਨ, ਰੇਟ ਲਿਮਿਟ, ਪ੍ਰੋਵਾਈਡਰ ਦੇ ਆਪਣੇ ਸਰਵਰ ਦੀਆਂ ਗਲਤੀਆਂ। ਪੱਕਾ ਇਨਕਾਰ (ਅਣਜਾਣ ਪਤਾ, ਗੈਰ-ਪ੍ਰਮਾਣਿਤ ਭੇਜਣ ਵਾਲਾ ਡੋਮੇਨ, ਠੁਕਰਾਏ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ) ਤੁਰੰਤ ਅਸਫਲ ਮੰਨ ਲਿਆ ਜਾਂਦਾ ਹੈ, ਕਿਉਂਕਿ ਦੁਹਰਾਉਣ 'ਤੇ ਜਵਾਬ ਉਹੀ ਆਵੇਗਾ। ਮੁਹਿੰਮ ਦੀਆਂ ਡਿਲੀਵਰੀਆਂ ਆਪਣੀ ਵੱਖਰੀ ਕਤਾਰ ਵਿੱਚ ਚੱਲਦੀਆਂ ਹਨ, ਵੱਧ ਤੋਂ ਵੱਧ ਛੇ ਕੋਸ਼ਿਸ਼ਾਂ ਅਤੇ ਛੋਟੀ ਉਡੀਕ ਨਾਲ — 5 ਸਕਿੰਟ, 30 ਸਕਿੰਟ, 2 ਮਿੰਟ, 10 ਮਿੰਟ; ਇਹ ਮੁੱਕ ਜਾਣ 'ਤੇ ਡਿਲੀਵਰੀ "queued" ਵਿੱਚ ਹਮੇਸ਼ਾ ਲਈ ਟਿਕੇ ਰਹਿਣ ਦੀ ਥਾਂ Delivery kept failing and was stopped after several attempts ਨਾਲ ਬੰਦ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ। ਹੱਥੀਂ Retry ਦਬਾਉਣਾ ਸੁਰੱਖਿਅਤ ਹੈ। ਇਹ ਸਿਰਫ਼ ਉਸ ਸੁਨੇਹੇ 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ ਜੋ ਸੱਚਮੁੱਚ ਅਸਫਲ ਸਥਿਤੀ ਵਿੱਚ ਹੈ, ਅਤੇ ਈਮੇਲ ਲਈ ਪਹਿਲਾਂ ਪ੍ਰੋਵਾਈਡਰ ਤੋਂ ਪੁੱਛਦਾ ਹੈ ਕਿ ਅਸਲ ਸੁਨੇਹੇ ਦਾ ਕੀ ਬਣਿਆ: ਜੇ ਉਹ ਈਮੇਲ ਸੱਚਮੁੱਚ ਚਲੀ ਗਈ ਸੀ ਤਾਂ ਦੂਜੀ ਕਾਪੀ ਭੇਜਣ ਦੀ ਥਾਂ ਕਤਾਰ ਦੀ ਲਾਈਨ delivered ਵਿੱਚ ਬਦਲ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਅਸਲੀ ਦੁਬਾਰਾ-ਭੇਜ ਨਵੀਂ idempotency ਕੁੰਜੀ ਨਾਲ ਜਾਂਦਾ ਹੈ। ਜਿੱਥੇ ਦੂਜੀ ਕਾਪੀ ਗਲਤ ਹੋਵੇਗੀ — ਹਾਰਡ ਬਾਊਂਸ, ਸਪੈਮ ਸ਼ਿਕਾਇਤ, ਜਾਂ ਪਹਿਲਾਂ ਤੋਂ ਰਾਹ ਵਿੱਚ ਪਿਆ ਸੁਨੇਹਾ — ਉੱਥੇ ਬਟਨ ਹੁੰਦਾ ਹੀ ਨਹੀਂ ਜਾਂ ਕੋਸ਼ਿਸ਼ ਕਾਰਨ ਦੱਸ ਕੇ ਰੱਦ ਕਰ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ।
ਕਾਰਨ ਹਾਲੇ ਵੀ ਸਾਫ਼ ਨਹੀਂ — ਮਦਦ ਕਿਵੇਂ ਲਵਾਂ?
ਹਰ ਅਸਫਲ ਸੁਨੇਹੇ ਦੇ ਨਾਲ Ask Copilot ਬਟਨ ਹੁੰਦਾ ਹੈ। ਇਹ ਗਲਤੀ, ਚੈਨਲ ਅਤੇ ਗੱਲਬਾਤ ਨੱਥੀ ਕਰਕੇ Copilot ਖੋਲ੍ਹਦਾ ਹੈ, ਅਤੇ Copilot ਉਸੇ ਅਸਫਲਤਾ ਲਈ ਠੋਸ ਕਦਮਾਂ ਨਾਲ Respondo ਦੇ ਆਪਣੇ ਮਦਦ ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਇਹ ਮਦਦ ਮੁਫ਼ਤ ਹੈ — ਇਹ ਤੁਹਾਡੀਆਂ AI ਬੇਨਤੀਆਂ ਵਿੱਚ ਨਹੀਂ ਗਿਣੀ ਜਾਂਦੀ। ਜੇ ਕਦਮਾਂ ਨਾਲ ਸਮੱਸਿਆ ਹੱਲ ਨਾ ਹੋਵੇ ਤਾਂ ਬੱਸ ਇਹੀ ਕਹਿ ਦਿਓ — "ਇਸ ਨਾਲ ਮਦਦ ਨਹੀਂ ਮਿਲੀ" ਕਾਫ਼ੀ ਹੈ। ਫਿਰ Copilot ਇੱਕ ਕਾਰਡ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਜੋ ਸਮੱਸਿਆ Respondo ਟੀਮ ਨੂੰ ਸੌਂਪਦਾ ਹੈ: ਕਾਰਡ ਵਿੱਚ ਠੀਕ-ਠੀਕ ਲਿਖਿਆ ਹੁੰਦਾ ਹੈ ਕਿ ਕੀ ਭੇਜਿਆ ਜਾਵੇਗਾ, ਤੁਹਾਡੀ ਪੁਸ਼ਟੀ ਤੋਂ ਪਹਿਲਾਂ ਕੁਝ ਨਹੀਂ ਜਾਂਦਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਦਾ ਜਵਾਬ ਉਸੇ Copilot ਥ੍ਰੈੱਡ ਵਿੱਚ ਆਉਂਦਾ ਹੈ। ਜੇ ਇੱਥੋਂ ਸੌਂਪਣਾ ਸੰਭਵ ਨਾ ਹੋਵੇ ਤਾਂ Copilot ਚੁੱਪ ਰਹਿਣ ਦੀ ਬਜਾਏ ਸਾਫ਼ ਦੱਸ ਦਿੰਦਾ ਹੈ।