خريطة بيانات الذكاء الاصطناعي الصوتي: التسجيلات والنصوص المفرّغة وواجهات API والكتابة العكسية إلى CRM

خريطة بيانات الذكاء الاصطناعي الصوتي هي صفحة واحدة تسرد كل عنصر بيانات تُنشئه المكالمة، ومكان تخزينه، ومدة الاحتفاظ به، وكيف يغادر المنصّة، وفي أيّ أنظمتك ينتهي به المطاف. يطلبها فريق الأمن قبل التوقيع، ويستخدمها فريقا تقنية المعلومات والعمليات لتخطيط التكامل.

يبني هذا الدليل تلك الخريطة لمنصّة Retell AI استنادًا إلى وثائق Retell. وحيث لا تذكر الوثائق شيئًا، يوضّح لك ما ينبغي أن تسأل عنه.

ما البيانات التي تُنشئها مكالمة واحدة بالذكاء الاصطناعي الصوتي؟

تُنتج المكالمة الموصولة على منصّة Retell سبعة أنواع من البيانات، جميعها ضمن كائن مكالمة واحد يُعرَّف بـ call_id:

• التسجيل. صوت بصيغة WAV، كملف مدمج أحادي القناة وملف متعدد القنوات يكون فيه كل طرف على قناته الخاصة.
• النص المفرّغ. نص عادي، وقائمة بالعبارات مع طوابعها الزمنية، ونسخة مدمجة مع كل استدعاء أداة ونتيجته.
• تحليل ما بعد المكالمة. حقول مدمجة (call_summary، user_sentiment، call_successful، in_voicemail) إضافة إلى حقول مخصّصة تعرّفها بنوع منطقي أو نصي أو رقمي أو قائمة اختيار.
• السجلات. سجل عام لطلبات LLM واستجاباته، إضافة إلى سجل استرجاع من قاعدة المعرفة إذا كان الوكيل يستخدم واحدة.
• المتغيرات والبيانات الوصفية. متغيرات ديناميكية تُمرَّر أو تُجمَع أثناء المكالمة، وكائن metadata حر الشكل لمعرّفاتك الخاصة.
• أرقام الهواتف. معرّف المتصل في المكالمات الواردة والرقم المطلوب في المكالمات الصادرة.
• الحقول التشغيلية. الطوابع الزمنية، والمدة، والحالة، وسبب قطع الاتصال، ووجهة التحويل، وزمن الاستجابة، والتكلفة.

لا يتوفّر معظم هذه البيانات إلا بعد انتهاء المكالمة، وتبقى حقول التحليل المخصّصة فارغة للمكالمات التي لم يُوصَل فيها الاتصال قط.

أين يوجد كل عنصر، وكيف تستخرجه؟

يوجد كل شيء في سجل المكالمة داخل مساحة عمل Retell الخاصة بك، ويخرج عبر ثلاثة منافذ: webhooks وواجهة API وعمليات تصدير CSV من لوحة التحكم.

أربعة تفاصيل مهمّة عند ربط هذه المنظومة:

• يُغفل List Calls النصوص المفرّغة وrecording_url للإبقاء على صغر حجم الاستجابات، لذا تقرنه عملية الاستكمال المجمّعة بـ Get Call لكل call_id.
• تنتهي مهلة webhooks بعد 10 ثوانٍ وتُعاد المحاولة حتى 3 مرات، لذا أزِل التكرار بالاعتماد على call_id.
• يحمل كل webhook ترويسة x-retell-signature تتحقّق منها باستخدام مفتاح API الخاص بك، وتنشر منصّة Retell عنوان IP لإضافته إلى قائمة السماح (100.20.5.228).
• تُنشأ عمليات تصدير CSV في لوحة التحكم استنادًا إلى عوامل التصفية النشطة، ويُحتفظ بها لمدة أسبوع واحد. ويُرجع List Export Requests (GET /v2/list-export-requests) حالة كل عملية تصدير ورابط تنزيلها.

ما المدة التي تحتفظ فيها منصّة Retell ببيانات المكالمات، وهل يمكنك إيقاف التخزين؟

افتراضيًا، تحتفظ منصّة Retell ببيانات المكالمات إلى أجل غير مسمّى. ويمكنك تغيير ذلك لكل وكيل ضمن Security & fallback settings (إعدادات الأمان والبديل الاحتياطي).

مدة الاحتفاظ. اختر 1 أو 3 أو 7 أو 30 أو 60 أو 90 أو 180 أو 365 أو 730 يومًا، أو الاحتفاظ الدائم؛ وعبر API، اضبط data_storage_retention_days. تُحذف البيانات المنتهية يوميًا وبشكل نهائي، بما يشمل التسجيلات والنصوص المفرّغة والسجلات والمتغيرات الديناميكية والبيانات الوصفية. تحتفظ منصّة Retell ببعض البيانات الوصفية الأساسية داخليًا، لكن المكالمة لا تعود تظهر في السجل أو في استجابات API.

وضع التخزين. اختر واحدًا من ثلاثة:

• Everything (كل شيء). تُخزَّن النصوص المفرّغة والتسجيلات والسجلات.
• Everything except PII (كل شيء باستثناء PII). يُخزَّن المحتوى بعد إزالة فئات PII التي اخترتها، وتُحذف النسخ الأصلية الخام.
• Basic Attributes Only (السمات الأساسية فقط). لا تُخزَّن أي نصوص مفرّغة أو تسجيلات أو سجلات، ويُرجع Get Call المكالمة من دونها.

إذا ألغيت الاشتراك في التخزين، فستظل webhooks تحمل النص المفرّغ والتسجيل، لكن صلاحية رابط التسجيل تنتهي بعد 10 دقائق من وصول webhook. أنشئ مستقبِل webhook قبل إجراء هذا التغيير.

يمكن لـ data_storage_setting في Update Call أن يجعل مكالمة واحدة أكثر صرامة، لا أقل صرامة أبدًا. ويمكن لمستخدمي لوحة التحكم المصرّح لهم إزالة البيانات الحساسة لمكالمة ما أو حذف المكالمة، ويؤدي Delete Call (DELETE /v2/delete-call/{call_id}) الأمر نفسه عبر API. وكلا الإجراءين لا رجعة فيه.

لا تنتهي صلاحية روابط التسجيلات والسجلات افتراضيًا. فعّل Opt In Secure URLs (opt_in_signed_url) ليصبح كل رابط تطلبه موقّعًا وتنتهي صلاحيته بعد 24 ساعة، أو بعد مدة تحدّدها بين دقيقة واحدة و7 أيام.

ما الذي يزيله تنقيح PII فعليًا؟

في وضع Everything except PII، تكتشف منصّة Retell الفئات التي تختارها بعد المكالمة وتستبدل كل ظهور لها بعنصر نائب مرقّم مثل [email 1]. والفئات الـ 13 هي: اسم الشخص، والعنوان، والبريد الإلكتروني، ورقم الضمان الاجتماعي (SSN)، وجواز السفر، ورخصة القيادة، وبطاقة الائتمان، والحساب المصرفي، وكلمة المرور، ورمز PIN، والمعرّف الطبي، وتاريخ الميلاد، ورقم حساب العميل.

يشمل التنقيح أكثر من النص المفرّغ: التسجيل (تتحوّل فترات PII إلى صفير)، والسجلات العامة، والمتغيرات الديناميكية، والبيانات الوصفية، وملخّص المكالمة وبيانات التحليل المخصّصة، ووسائط استدعاءات الأدوات ونتائجها. وتتحوّل أرقام DTMF إلى [PII INFO] كلما كانت أي فئة مفعّلة.

يؤدي اختيار phone_number إلى إزالة رقم العميل من سجل المكالمة نفسه (from_number في المكالمات الواردة، وto_number في المكالمات الصادرة). اتركه غير مفعّل إذا كان أحد الأنظمة اللاحقة يعتمد على هذا الرقم في المطابقة.

بعض الحقول لا تُنقَّح أبدًا، ومنها call_id وagent_id والطوابع الزمنية والحالة وسبب قطع الاتصال وcall_successful وuser_sentiment والتكلفة والسمات المخصّصة. ولحذف هذه الحقول أيضًا، استخدم وضع Basic Attributes Only أو مدة احتفاظ.

يعتمد الوصول على الأدوار. فدور Member لا يرى إلا السجل المنقّح، بينما يمكن لدوري Admin وDeveloper عرض النصوص المفرّغة والتسجيلات الخام.

أين تُستضاف البيانات، وما الذي يجب أن يسأل عنه فريق الأمن؟

تنص وثائق الامتثال الخاصة بـ Retell على أن منصّة Retell متوافقة مع HIPAA وGDPR وحاصلة على شهادتي SOC 2 Type 1 وType 2، وأنها تستوفي متطلبات GDPR باستخدام AWS مع ملحق معالجة بيانات (Data Processing Addendum) متوافق مع GDPR، وأنها لا تشغّل حاليًا خدمات داخل الاتحاد الأوروبي. ويُوقَّع كلٌّ من BAA وDPA (مع البنود التعاقدية القياسية للاتحاد الأوروبي) ذاتيًا دون رسوم إضافية، وتتوفّر الشهادات والتقارير في Compliance Trust Center.

لا تحدّد الوثائق العامة منطقة تخزين لكل عنصر بيانات ولا تسمّي خدمة التخزين الأساسية، لذا لا تفترض أيًّا منها. اسأل منصّة Retell كتابيًا (يتولّى support@retellai.com مراجعات الأمان وتقييمات الموردين وقوائم المعالجين الفرعيين)، وتحقّق من إعداداتك الخاصة:

• أين يُعالَج صوت المكالمات، وأين يُخزَّن كل عنصر بيانات في الجدول؟
• ما المعالجون الفرعيون الذين يتعاملون مع الصوت والنصوص المفرّغة والتحليلات؟
• هل تتوافق مدة الاحتفاظ ووضع التخزين لكل وكيل في بيئة الإنتاج مع سياستنا؟
• هل الروابط الآمنة مفعّلة، وبمدة صلاحية نقبلها؟
• أيّ مستخدمينا يحملون دوري Admin أو Developer ويمكنهم رؤية البيانات الخام؟
• هل يتحقّق مستقبِل webhook لدينا من التواقيع ويحتفظ بما نحتاجه قبل أن تحذفه سياسة الاحتفاظ؟

للجانب التعاقدي (BAA مقابل DPA، وعوائق إقامة البيانات، ومراحل الشراء)، اطّلع على ما يحتاج المشترون من المؤسسات إلى معرفته قبل نشر الذكاء الاصطناعي الصوتي.

ما الذي يصل إلى CRM لديك، وعبر أي مسار؟

يعتمد ذلك على المسار. تعمل تكاملات Retell الأصلية مع Salesforce وHubSpot وMicrosoft Dynamics 365 وGoHighLevel وZoho CRM على استيراد جهات الاتصال (كل 5 دقائق اعتبارًا من أغسطس 2026)، وربط حقول تحليل ما بعد المكالمة بحقول جهات الاتصال، وإعادة دفع تغييرات الحقول، وتسجيل كل مكالمة كنشاط. فعلى سبيل المثال، تحمل مهمة Task في Salesforce المدة والملخّص ومعرّف المحادثة وأرقام الهواتف وسبب قطع الاتصال. ولا تُحدّث المزامنة الصادرة إلا السجلات الموجودة ما لم تفعّل Create new contacts in CRM، ولا يُسجَّل النشاط إلا لجهات الاتصال المستوردة من CRM المتصل.

لا تصل التسجيلات والنصوص المفرّغة الكاملة إلى CRM إلا عندما يحملها المسار، كما يفعل سجل المكالمات في تطبيق HubSpot Marketplace أو أداة الكتابة الخاصة بك عبر webhook. ولآليات الانتقال من المُشغِّل إلى الكتابة العكسية، اطّلع على سير العمل من CRM إلى الذكاء الاصطناعي الصوتي؛ ويسرد دليل التكاملات ما يتّصل بشكل أصلي.

كيف تشكّل القراءة قبل المكالمة والكتابة بعدها حلقة واحدة قابلة للاختبار؟

يكتمل التكامل عندما تقرأ مكالمة واحدة السجل الصحيح قبل بدئها، وتحجز الموعد أثناءها، وتكتب ملاحظة الفني بعدها، وكل ذلك على السجل نفسه. وتنمذج صفحة Workflow الخاصة بالوكيل في Retell ذلك كرسم بياني واحد. على خط لخدمة ميدانية:

1. القراءة قبل المكالمة. تبحث دالة ما قبل المكالمة في CRM عن {{user_number}} وتربط معرّف السجل بمتغيّر. تنتظرها المكالمات الواردة حتى دقيقة واحدة؛ وتتيح المكالمات الصادرة 5 دقائق قبل الاتصال.
2. الحجز أثناء المكالمة. يحجز الوكيل باستخدام أداة تقويم (Cal.com أو Calendly أو تقويمات GoHighLevel) أو دالة مخصّصة تستدعي API نظام الجدولة لديك، والذي يمكنه التحقّق من ترويسة X-Retell-Signature. ويُحفظ معرّف الحجز في متغيّر.
3. الكتابة بعد المكالمة. تُنشئ دالة ما بعد المكالمة الملاحظة: تُنشئ أدوات Salesforce وDynamics 365 وZoho ملاحظات، ويضيف Zendesk ملاحظات خاصة، وأي نظام آخر يتطلّب دالة مخصّصة. وتعيد الدالة استخدام معرّف السجل من مرحلة ما قبل المكالمة، وتكتب {{call_summary}} أو حقلًا مخصّصًا مثل access_instructions، ولا تعمل إلا عند وجود متغيّر الحجز. وتتوقف دوال ما بعد المكالمة عند 5 دقائق.

إذا فشل البحث، تُتخطّى كل دالة تعتمد عليه، فلا تُكتب أي ملاحظة دون معرّف سجل، وتستمر المكالمة رغم ذلك. وثمة قيد واحد لفرق المنصّات: تُهيّأ دوال سير العمل في لوحة التحكم فقط وليست جزءًا من واجهة API العامة (اعتبارًا من أغسطس 2026)، لذا لن تكون ضمن البنية التحتية كرمز (infrastructure-as-code) لديك.

اختبر الحلقة على مرحلتين:

• اختبارات المحاكاة باستخدام البدائل الوهمية (mocks). أنشئ بديلًا وهميًا لكل دالة مخصّصة وأداة تقويم. فالدالة غير المحاكاة تستدعي endpoint الحقيقي الخاص بها وقد تُنشئ حجزًا حقيقيًا.
• مكالمة حقيقية واحدة على سجل تجريبي (sandbox). أجرِ مكالمة اختبار عبر الويب أو الهاتف وافتحها في سجل المكالمات. تظهر دوال ما قبل المكالمة ضمن Before call ودوال ما بعد المكالمة ضمن Call ended، مع الوسائط المُرسلة والاستجابات المُعادة. ولا يُعدّ الاختبار ناجحًا إلا إذا كان الحجز موجودًا، والملاحظة على السجل نفسه، وسجّل المستقبِل لديك حدث call_analyzed واحدًا لذلك call_id.

لخطة التجربة الأوسع، اطّلع على كيفية تقييم منصّة الوكلاء الصوتيين قبل الإطلاق. ولمعرفة كيفية عمل دوال ما قبل المكالمة وما بعدها، اطّلع على Retell Workflows.

ضع الخريطة موضع التطبيق

املأ الجدول لكل وكيل وأرفق إجابات فريق الأمن، لتخدم صفحة واحدة مراجعتك وخطة التكامل وسجل التدقيق. ولمعرفة ما تستخرجه منصّة Retell من كل مكالمة وكيف يتدفّق إلى أنظمتك، ابدأ بـ تحليل ما بعد المكالمة في Retell.