منظومة الذكاء الاصطناعي الصوتي التي تريد معظم فرق المكالمات الصادرة استبدالها هي سلسلة الحلول المؤقتة المحيطة بالذكاء الاصطناعي نفسه: أداة اتصال آلي (dialer) منفصلة لإجراء المكالمات، ومنطق مطوَّر داخليًا لاكتشاف أجهزة الرد الآلي، وطبقة أتمتة تنقل كل مكالمة بين الأنظمة. الهدف ليس صوتًا جديدًا بالذكاء الاصطناعي، بل أنظمة أقل، وعمليات تسليم أقل، وعناصر أقل تحتاج إلى صيانة، وجهة مسؤولة واحدة تتولى الأمر عندما تفشل مكالمة. أما نظام CRM فليس ضمن القائمة.
كيف تبدو منظومة الحلول المؤقتة المعتادة؟
تتكوّن عادةً من خمس طبقات، أُضيفت كلٌّ منها لسبب وجيه. المشكلة أن مكالمة صادرة واحدة باتت تمر الآن عبر الطبقات الخمس جميعها.
| الطبقة | وظيفتها | سبب إضافة الفرق لها |
|---|
| مزوّد الصوت بالذكاء الاصطناعي | يدير المحادثة | السبب الأساسي للمشروع |
| أداة اتصال آلي أو CPaaS (غالبًا Twilio) | تُجري المكالمة الصادرة وتمرّر الصوت إلى الذكاء الاصطناعي | لم يكن مزوّد الذكاء الاصطناعي يُجري المكالمات الصادرة بشكل مدمج، أو لم يكن يفعل ذلك بالحجم المطلوب |
| منطق أجهزة الرد الآلي والبريد الصوتي | يحدد ما إذا كان المجيب إنسانًا أم آلة، ثم ينهي المكالمة أو يترك رسالة | كان لا بد من تحويل نتيجة أداة الاتصال إلى إجراء |
| طبقة الأتمتة (أداة بدون كود أو نصوص برمجية داخلية) | تسحب جهات الاتصال من نظام CRM، وتبدأ المكالمات، وتعيد النتائج إليه | لم يكن هناك ما يربط بين أداة الاتصال والذكاء الاصطناعي ونظام CRM |
| CRM | يحفظ جهة الاتصال والسجل والخطوة التالية | إنه نظام السجلات المرجعي |
احسب عمليات التسليم في مكالمة واحدة: من CRM إلى الأتمتة، ومن الأتمتة إلى أداة الاتصال، ومن أداة الاتصال إلى منطق الرد الآلي، ومن المنطق إلى مزوّد الذكاء الاصطناعي، ومن مزوّد الذكاء الاصطناعي عودةً إلى الأتمتة، ومن الأتمتة عودةً إلى CRM. هذه ست نقاط يمكن أن تفشل فيها المكالمة، موزّعة على أربعة أو خمسة موردين.
أين تتعطل منظومة الحلول المؤقتة؟
تتعطل عند نقاط التسليم، لا داخل أي أداة بعينها. قد تبدو لوحة تحكم كل مورّد سليمة، بينما يفشل مسار المكالمة بينها.
حالة المكالمة موزّعة في مكانين. عندما تُجري أداة الاتصال المكالمة ويدير الذكاء الاصطناعي المحادثة، تُسجَّل حالة عدم الرد في أداة الاتصال ولا تصل أبدًا إلى سجلات مزوّد الذكاء الاصطناعي. ويعني تتبّع الأخطاء مطابقة معرّفات المكالمات بين موردين اثنين. وهذا يجعل الاتصال المدمج قرارًا معماريًا: فالمكان الذي تُجرى منه المكالمة يحدد مكان سجل المكالمة وسبب انقطاعها والتسجيل الصوتي.
قرار التمييز بين الآلة والإنسان يحدث خارج الوكيل. إذا صنّفت أداة الاتصال الرد ثم مرّرت المكالمة، فإن أي تصنيف خاطئ يعني أن الوكيل يتحدث إلى تحية بريد صوتي، أو أن شخصًا حقيقيًا لا يسمع سوى الصمت. وتمثّل قوائم IVR حالة ثالثة لا تتعامل معها كثير من إعدادات أدوات الاتصال على الإطلاق.
طبقة الأتمتة تفشل بصمت. قد تنتهي مهلة سيناريو، أو يُعاد تسمية حقل في CRM، أو تنتهي صلاحية token. فتتوقف المكالمات أو تتوقف كتابة النتائج، دون أن يتلقى أحد تنبيهًا.
كل تغيير يمسّ ثلاثة إعدادات. تعني الحملة الجديدة قائمة في أداة الاتصال، وتعديلًا على الأتمتة، وتحديثًا لـ prompt، وسرعان ما تتباعد الثلاثة عن بعضها.
لا أحد يتولى مسؤولية المكالمة كاملة. عندما تفشل مكالمة، يُلقي مورّد الذكاء الاصطناعي باللوم على أداة الاتصال، وتُلقي أداة الاتصال باللوم على مشغّل الاتصالات، أما الأتمتة فقد بناها شخص انتقل منذ ذلك الحين إلى فريق آخر.
ما الذي يجب دمجه، وما الذي يجب الإبقاء عليه؟
ادمج الطبقات التي لا وجود لها إلا لنقل مكالمة ذكاء اصطناعي واحدة بين الأدوات، واحتفظ بالأنظمة التي تعتمد عليها أعمالك. يمكن نقل أداة الاتصال ومنطق البريد الصوتي ومعظم أدوات الربط على مستوى المكالمة إلى منصّة الذكاء الاصطناعي الصوتي. أما نظام CRM ومشغّل الاتصالات لديك ومركز التواصل البشري فتبقى كما هي.
| الطبقة | الدمج أو الإبقاء | كيف يبدو ذلك على منصّة Retell |
|---|
| أداة اتصال منفصلة لمكالمات الذكاء الاصطناعي | دمج | تبدأ المكالمات الصادرة من Create Phone Call API أو من لوحة التحكم. وتعمل المكالمات المجمّعة على قائمة CSV مع الجدولة والنوافذ الزمنية ومتغيرات ديناميكية لكل مستلم. |
| مشغّل الاتصالات وأرقام الهواتف | إبقاء، إن كانت لديك أسباب لذلك | اشترِ أرقامًا أمريكية أو كندية من منصّة Retell، أو استورد أرقامك الخاصة عبر elastic SIP trunking. وتغطي الأدلة الموثّقة كلًّا من Twilio وTelnyx وVonage. |
| منطق أجهزة الرد الآلي وIVR | دمج داخل الوكيل | اكتشاف البريد الصوتي مع إنهاء المكالمة أو ترك رسالة، وإنهاء المكالمة عند IVR، وأداة Press Digit للتعامل مع قوائم لوحة المفاتيح. |
| أدوات الربط الآلي | تقليصها | وظائف ما قبل المكالمة وما بعدها، وأدوات مدمجة لأنظمة CRM المدعومة، ووظائف مخصّصة مرتبطة بـ API الخاص بك، وwebhooks لأحداث المكالمات. |
| CRM | إبقاء | مزامنة ثنائية الاتجاه لجهات الاتصال، وPost Call Extraction مربوط بحقول CRM، وتسجيل نشاط المكالمات في السجل لكلٍّ من Salesforce وHubSpot وMicrosoft Dynamics 365 وGoHighLevel وZoho CRM. |
| مركز التواصل للموظفين البشريين | إبقاء | تحويل مباشر، وتحويل مُمهَّد، وتحويل مُمهَّد يديره الوكيل، إلى رقم هاتف أو SIP URI. وتتوفر أدلة ربط لكلٍّ من Genesys Cloud وFive9 وAmazon Connect وAvaya. |
الإبقاء على مشغّل الاتصالات لا يعني الإبقاء على أداة اتصال منفصلة. فبمجرد استيراد رقم من Twilio أو Telnyx عبر SIP، تُجري منصّة Retell المكالمة من خلال ذلك الـ trunk، فيبقى مشغّل الاتصالات وتُستغنى عن برمجية أداة الاتصال. وتتناول قائمة التحقق الخاصة بأرقام المكالمات الصادرة قرار الشراء أو جلب أرقامك الخاصة.
نادرًا ما تختفي طبقة الأتمتة بالكامل. فيمكن الإبقاء على توجيه العملاء المحتملين وإثراء البيانات ومنطق الأعمال. أما ما يجب التخلص منه فهو أدوات الربط التي تقتصر وظيفتها على بدء مكالمة أو نسخ نص محادثة. ولمعرفة كيف يبدو جانب CRM من ذلك من البداية إلى النهاية، اطّلع على سير العمل من CRM إلى الذكاء الاصطناعي الصوتي. وللاطلاع على تفاصيل التكامل نظامًا بنظام، راجع كيف يندمج الذكاء الاصطناعي الصوتي في منظومة CRM والاتصالات لديك.
كيف ينبغي أن يعمل اكتشاف أجهزة الرد الآلي بعد نقله إلى الوكيل؟
تعامل مع البريد الصوتي وIVR بوصفهما حالات مكالمة صُمِّم الوكيل للتعامل معها، لا مرشِّحًا يسبقه. فعندما يكون الاكتشاف جزءًا من المحادثة، تُسجَّل النتيجة والإجراء وسبب الإنهاء في سجل مكالمة واحد. على منصّة Retell:
- نافذة الاكتشاف. يعمل اكتشاف البريد الصوتي وIVR خلال أول 3 دقائق بعد اتصال المكالمة الصادرة. هذه النافذة ثابتة، ولا يعمل الاكتشاف على المكالمات الواردة.
- إجراءات البريد الصوتي. إنهاء المكالمة، أو ترك رسالة. ويمكن أن تكون الرسالة prompt مُولَّدًا أو جملة ثابتة تتضمن متغيرات ديناميكية، مثل الاسم الأول لجهة الاتصال.
- التعامل مع IVR. تنهي ميزة IVR Hangup المكالمة عندما تجيب قائمة هاتفية. وبدلًا من ذلك، تتيح أداة Press Digit للوكيل التنقل في قوائم لوحة المفاتيح عندما يكون الهدف هو الوصول إلى قسم معيّن.
- التقارير. تنتهي المكالمات بسبب انقطاع هو
voicemail_reached أو ivr_reached، بحيث يمكن لتقاريرك فصلها عن المحادثات.
ثمة تفصيل مهم: قد تُصنَّف التحية على أنها IVR بدلًا من بريد صوتي، لذا فعّل IVR Hangup إلى جانب إنهاء المكالمة عند البريد الصوتي.
لا تصف وثائق Retell إعادة الاتصال التلقائية، لذا حدّد أين ستوجد قواعد إعادة المحاولة. ومن الأنماط الشائعة قراءة سبب الانقطاع (dial_no_answer، dial_busy، voicemail_reached) من webhook call_ended، وترك نظام CRM أو أداة الجدولة لديك تحدد المحاولة التالية. وللاطلاع على صياغة الرسائل، راجع أفضل ممارسات البريد الصوتي لوكلاء الصوت بالذكاء الاصطناعي.
كيف تبدو المكالمة الواحدة بعد الدمج؟
تمر المكالمة الواحدة عبر نظامين بدلًا من خمسة: منصّة الذكاء الاصطناعي الصوتي ونظام CRM. على منصّة Retell:
- يبدأ نظام CRM أو الخادم الخلفي لديك المكالمة عبر API، أو ترفع قائمة مكالمات مجمّعة. ويُخزَّن كائن
metadata، مثل معرّف السجل في CRM، على المكالمة. - تبحث وظيفة ما قبل المكالمة عن جهة الاتصال، فيبدأ الوكيل وهو مُلمّ بسياق الحساب.
- تتصل منصّة Retell من رقم Retell أو من رقمك المستورد.
- يحدد اكتشاف البريد الصوتي وIVR الخطوة الأولى.
- أثناء المحادثة، تقرأ أدوات التكامل أو الوظائف المخصّصة من أنظمتك وتكتب فيها.
- إذا لزم تدخّل شخص، يحوّل الوكيل المكالمة، وتسجّل أحداث webhook الخاصة بالتحويل ما إذا تمّ الربط.
- بعد المكالمة، تنظّم Post Call Extraction النتيجة، وتحدّث وظائف ما بعد المكالمة نظام CRM، وتُخطر webhooks
call_ended وcall_analyzed أي نظام آخر يحتاج إلى المعرفة.
ترتبط كل خطوة بمعرّف مكالمة واحد، ويحمل سجل المكالمة نص المحادثة والتسجيل الصوتي وسبب الانقطاع.
ما الذي يجب أن تتضمنه قائمة التحقق الخاصة بالتقييم؟
اطلب من كل مورّد أن يعرض لك هذه النقاط في مكالمة حيّة، لا في شريحة عرض.
| السؤال | ما تُظهره الإجابة الجيدة |
|---|
| هل يمكنكم إجراء المكالمات الصادرة بأنفسكم، واحدةً تلو الأخرى ومن قائمة؟ | اتصال عبر API وعبر القوائم مع جداول زمنية ونوافذ زمنية، دون أداة اتصال من طرف ثالث |
| هل يمكننا الإبقاء على مشغّل الاتصالات وأرقامنا؟ | Elastic SIP trunking مع إعداد موثّق لمزوّدك |
| أين يُتخذ قرار البريد الصوتي وIVR، وكيف يُبلَّغ عنه؟ | اكتشاف داخل الوكيل، وإجراءات قابلة للتهيئة، ورمز سبب لكل مكالمة |
| أين تُفحص قائمة عدم الاتصال (do-not-call) الخاصة بنا في كل مسار صادر؟ | إجابة واضحة لكل مسار. على منصّة Retell، يمكن لـ API ولوحة التحكم احترام علامة DNC الداخلية، لكن المكالمات المجمّعة لا تتحقق منها، لذا صفِّ قوائم المكالمات المجمّعة قبل رفعها. |
| كم عدد المكالمات التي يمكن تشغيلها في آنٍ واحد، وما سرعة بدئها؟ | حدود منشورة للتزامن وللمكالمات في الثانية، إضافةً إلى طريقة لحجز سعة للمكالمات الواردة أثناء تشغيل حملة |
| ما إجراءات CRM المدمجة، وما الإجراءات التي تحتاج إلى endpoint خاص بنا؟ | قائمة محددة بأنظمة CRM والإجراءات المدعومة، إضافةً إلى وظائف مخصّصة لما تبقى |
| ما الأحداث التي يمكن لأنظمتنا الاشتراك فيها؟ | Webhooks لبدء المكالمة وانتهائها وتحليلها وكل مرحلة من مراحل التحويل، مع إعادة المحاولة |
| ماذا يحدث عندما يفشل التحويل إلى موظف بشري؟ | fallback محدد داخل الوكيل وحدث يمكن لفريقك إعداد تنبيه عليه |
| ما الذي سيظل يعمل في طبقة الأتمتة لدينا، ومن المسؤول عنه؟ | قائمة قصيرة مكتوبة مع مسؤول محدد بالاسم |
| عندما تفشل مكالمة، بمن نتصل؟ | مسار دعم واحد ومعرّف مكالمة واحد يغطي الاتصال والمحادثة والنتيجة |
ثم اجمع تكلفة كل طبقة، لا سعر الدقيقة للذكاء الاصطناعي فحسب: رسوم أداة الاتصال، ودقائق مشغّل الاتصالات، ومهام الأتمتة، وساعات العمل الهندسي المبذولة لإبقائها متزامنة. ووفقًا لصفحة الأسعار لدى Retell، لا تفرض منصّة Retell أي رسوم اتصالات على الاتصالات المخصّصة وSIP trunking (مع استمرار مشغّل الاتصالات في محاسبتك)، وتبلغ تكلفة أرقام Retell $2.00 شهريًا، وتضيف المكالمات المجمّعة $0.005 لكل اتصال.
من أين تبدأ
اختر حملة صادرة واحدة تمر عبر منظومة الحلول المؤقتة كاملة. ارسم كل نقطة تسليم في مكالمة واحدة، وحدّد المسؤول عن كلٍّ منها، وضع علامة على الطبقات التي لا وجود لها إلا لنقل تلك المكالمة. هذه هي الطبقات المرشّحة للدمج. ثم جرّب على مكالمات حقيقية مع ربط أرقامك ونظام CRM الخاص بك، واحسب عدد الأنظمة المعنية عندما يحدث خطأ ما. وإذا كنت تخطط لهذا الدمج لفريق مكالمات صادرة، فاطّلع على كيف تدير منصّة Retell المكالمات الصادرة لمراكز التواصل، مع الاتصال، والتعامل مع البريد الصوتي، والتحويلات، والكتابة في CRM ضمن منصّة واحدة.
