وكيل ذكاء اصطناعي لـ Magento يتقن كتالوجك ويتعامل مع واجهات برمجة التطبيقات الخاصة بك

تحتل Magento مكانة فريدة في التجارة الإلكترونية. إنها المنصة التي يختارها التجار عندما يكون كتالوجهم معقدًا للغاية بالنسبة للحلول الأبسط — عندما تأتي المنتجات بتعقيدات سمات متعددة، وعندما يخدم نفس المتجر مشترين من B2B و B2C، وعندما تمتد الإعدادات متعددة المتاجر عبر علامات تجارية أو مناطق مختلفة تحت لوحة إدارة واحدة. هذا التعقيد هو ما يجعل Magento قوية. وهو أيضًا ما يجعل دعم العملاء على متجر Magento صعبًا للغاية لأتمتته.

كتالوج Magento النموذجي ليس مجرد قائمة مسطحة من المنتجات التي تحتوي على اسم وسعر ووصف. إنه شبكة من أنواع المنتجات، لكل منها منطق هيكلي مختلف. قد يحتوي المنتج القابل للتكوين — على سبيل المثال، جاكيت جري عالي الأداء — على 48 منتجًا بسيطًا تابعًا يمثل كل مجموعة من الحجم (من XS إلى XXL) واللون (أسود، كحلي، قرمزي، فحمي، كاكي، فولاذي). قد يسمح المنتج المُجمَّع للعميل باختيار المكونات — نظام مسرح منزلي حيث يختارون جهاز الاستقبال ومكبرات الصوت ومضخم الصوت من قوائم خيارات منسقة، لكل منها تسعيره الخاص. تربط المنتجات المُجمَّعة العناصر ذات الصلة — مجموعة أثاث حيث يتم عرض طاولة الطعام والكراسي والمقعد معًا ولكن يتم شراؤها بشكل فردي. كل محادثة دعم حول أحد هذه المنتجات تتطلب فهم ليس فقط المنتج نفسه ولكن نوعه وأطفاله وسماته وكيفية تعيينها لما يسأل عنه العميل بالفعل.

عندما يتصل العميل بالدعم ويسأل "هل جاكيت Alpine Performance متوفر باللون الأحمر مقاس L؟" — هذا ليس بحثًا بسيطًا. في نموذج بيانات Magento، يسأل العميل عما إذا كان منتج بسيط محدد موجودًا ضمن مصفوفة سمات المنتج القابل للتكوين. لن يتمكن روبوت الدردشة للأسئلة الشائعة من الإجابة على هذا بدقة. سيقدم إما ردًا عامًا "يرجى التحقق من صفحة المنتج" أو سيخمن بشكل خاطئ. وكيل الذكاء الاصطناعي الذي قام بالزحف إلى واجهة المتجر ويفهم هيكل المنتج يمكنه تقديم إجابة مباشرة — "نعم، جاكيت Alpine Performance متوفر باللون الأحمر / الكبير. يبلغ سعره 129.00 دولارًا وهو متوفر حاليًا في المخزون. سيتم شحنه في غضون يومي عمل. هل ترغب في أن أشاركك رابطًا مباشرًا لهذا المنتج؟" — لأنه تعلم مصفوفة سمات المنتج من خلال الزحف إلى صفحة تفاصيل المنتج نفسها التي يراها العميل.

يقترب وكيل Asyntai للذكاء الاصطناعي من كتالوج Magento بالطريقة التي يفعلها وكيل دعم مدرب جيدًا: من خلال قراءة واجهة المتجر. إنه يزحف إلى صفحات المنتجات وصفحات الفئات وصفحات محتوى CMS وصفحات السياسات الخاصة بك. يقرأ أوصاف المنتجات وجداول السمات وهياكل الفئات وخيارات التنقل الطبقي. يقرأ كتل CMS التي قمت بتضمينها في رؤوس الفئات والصفحات الثابتة التي تحتوي على سياسات الشحن والإرجاع الخاصة بك. عندما يسأل العميل سؤالاً، يعتمد الوكيل على قاعدة المعارف التي تم الزحف إليها — وهي نفس المعلومات التي يمكن للعميل العثور عليها من خلال التنقل في موقعك، ولكن يتم تسليمها على الفور بتنسيق محادثة دون جهد التصفح.

لكن المحتوى الذي تم الزحف إليه يغطي نصف معادلة الدعم فقط. النصف الآخر — والنصف الذي يولد غالبية تذاكر الدعم — يتضمن بيانات حية. "أين طلبي؟" "هل هذا الرمز متوفر في المخزون؟" "ما هو رصيد حسابي؟" "هل لا يزال بإمكاني إرجاع هذا؟" لا يمكن الإجابة على هذه الأسئلة من قاعدة معارف ثابتة لأن الإجابات تتغير مع كل معاملة، وكل شحنة، وكل تعديل للمخزون. وهنا يصبح تكامل واجهة برمجة تطبيقات REST الخاصة بـ Magento نقطة تكامل حاسمة، وهنا تحول الأدوات المخصصة من Asyntai وكيل الذكاء الاصطناعي من مساعد مطلع إلى وكيل تشغيلي.

تأتي Magento 2 مزودة بواجهة برمجة تطبيقات REST شاملة. تعيش بيانات الطلب على /rest/V1/orders. يمكن الاستعلام عن المخزون عبر /rest/V1/stockItems/{sku}. تقع بيانات العملاء خلف /rest/V1/customers. محتوى CMS، وقواعد الكتالوج، وبيانات سلة التسوق، وتتبع الشحنة — يمكن الوصول إلى كل كيان تقريبًا في بنية Magento عبر واجهة برمجة التطبيقات. تتيح الأدوات المخصصة لوكيل الذكاء الاصطناعي استدعاء نقاط النهاية هذه في منتصف المحادثة. يسأل العميل عن طلبه. يستخرج الوكيل معرف الزيادة في الطلب من الرسالة، ويستدعي نقطة نهاية طلب Magento الخاصة بك، ويتلقى حالة الطلب وتفاصيل العنصر وتتبع الشحنة ومعلومات الدفع، ويؤلف إجابة كاملة. تحدث دورة كاملة — تحليل السؤال، وإجراء استدعاء واجهة برمجة التطبيقات، وتفسير الاستجابة، وتوليد الرد — في ثوانٍ.

الفرق العملي الذي يخلقه هذا كبير. بدون الوصول إلى واجهة برمجة التطبيقات، فإن أفضل ما يمكن أن يفعله الذكاء الاصطناعي بسؤال الطلب هو تلاوة تعليمات التتبع العامة الخاصة بك: "يمكنك العثور على حالة طلبك في حسابي ضمن الطلبات والمرتجعات." باستخدام الأدوات المخصصة المتصلة بواجهة برمجة تطبيقات الطلبات في Magento، يقول الوكيل: "تم شحن طلبك رقم 100000042 في 17 يونيو عبر UPS Ground — رقم التتبع 1Z999AA10123456784. إنه حاليًا قيد النقل عبر مركز شيكاغو ومن المتوقع وصوله بحلول 21 يونيو. يتضمن الطلب جاكيت Alpine Performance باللون الكحلي / المتوسط وقبعة الجري في الغابة بلون الفحم. هل هناك أي شيء آخر بخصوص هذا الطلب؟" هذه ليست مساعدة. هذا حل. حصل العميل على إجابته. تم إغلاق التذكرة. لم يشارك أي إنسان.

تعد أسئلة المخزون ذات قيمة عالية بشكل خاص في متاجر Magento بسبب تعقيد الكتالوج. يريد العميل الذي يتصفح منتجًا قابلاً للتكوين يحتوي على 48 متغيرًا أن يعرف ما إذا كان مزيجه المحدد متوفرًا في المخزون قبل أن يلتزم. في العديد من متاجر Magento، تعرض صفحة المنتج "متوفر في المخزون" على مستوى المنتج القابل للتكوين حتى عندما تكون مجموعات ألوان/أحجام محددة قد نفدت — لا يكتشف العميل ذلك إلا بعد تحديد خياراته ويرى "نفد المخزون" باللون الأحمر. هذا يخلق إحباطًا وتذاكر دعم. يمكن لوكيل الذكاء الاصطناعي تجاوز هذا تمامًا. "هل جاكيت Alpine Performance متوفر باللون الزيتوني، مقاس XL؟" — يستدعي الوكيل نقطة نهاية المخزون لرمز SKU الخاص بهذا المنتج البسيط المحدد، ويتحقق من الكمية، ويرد: "جاكيت WRJ-NVY-M (جاكيت الجري المقاوم للطقس، الكحلي، المتوسط) لديه حاليًا 23 وحدة متاحة عبر مستودعك المعين. خمس وحدات ليست مشكلة — إنها جاهزة للشحن. هل ترغب في أن أتحقق من أي أحجام أو ألوان أخرى في هذا النمط بينما أنا في ذلك؟"

تعد المرتجعات مجالًا آخر حيث يؤدي تعقيد Magento إلى زيادة عبء الدعم. قد يحتوي متجر Magento على سياسات إرجاع مختلفة لأنواع منتجات مختلفة — إلكترونيات بحد أقصى 15 يومًا، ملابس بحد أقصى 30 يومًا، عناصر مخصصة أو شخصية نهائية البيع. قد تعيش سياسة الإرجاع في صفحة CMS. تعيش بيانات الطلب في قاعدة البيانات، ويمكن الوصول إليها عبر واجهة برمجة التطبيقات. يتطلب طلب الإرجاع كليهما: التحقق من تاريخ الطلب مقابل السياسة المعمول بها ومعالجة طلب الإرجاع (RMA). باستخدام الأدوات المخصصة، يتعامل وكيل الذكاء الاصطناعي مع سير العمل الكامل. يستدعي واجهة برمجة تطبيقات الطلب للحصول على تاريخ الشراء وتفاصيل العنصر. يتحقق من تلك التفاصيل مقابل سياسة الإرجاع التي تعلمها من الزحف إلى محتوى CMS الخاص بك. إذا كان العميل مؤهلاً، فيمكنه استدعاء نقطة نهاية المرتجعات لبدء طلب الإرجاع (RMA) — حيث يلتقط العنصر والسبب ومعلومات العميل. يحصل العميل على حل في محادثة واحدة. يحصل فريق الدعم الخاص بك على طلب إرجاع مكتمل في قائمة الانتظار الخاصة به بدلاً من بريد إلكتروني غير منظم يحتاج إلى بحث.

تعد المتاجر المتعددة ميزة مميزة لـ Magento، وتخلق تحديًا فريدًا للدعم. يمكن لتثبيت Magento واحد أن يخدم مواقع ويب متعددة، لكل منها عروض متجر متعددة — علامات تجارية مختلفة، مناطق مختلفة، لغات مختلفة، كتالوجات مختلفة، أسعار مختلفة. يحتاج التاجر الذي يدير واجهة متجر B2C وبوابة جملة B2B من نفس تثبيت Magento إلى دعم يفهم المتجر الذي يتواجد فيه العميل ويطبق الكتالوج والتسعير والسياسات الصحيحة. يتعامل Asyntai مع هذا من خلال السماح لكل عرض متجر بالحصول على تكوين الأداة الخاص به. يحصل متجر B2C على وكيل يجيب باستخدام صفحات منتجات المستهلكين مع سياسات البيع بالتجزئة القياسية. تحصل بوابة B2B على وكيل يجيب باستخدام كتالوجات الجملة مع منطق التسعير المتفاوض عليه وسير عمل حساب الشركة. يزحف كل عنصر واجهة مستخدم إلى واجهة متجره الخاصة. يتصل كل واحد بنطاق واجهة برمجة التطبيقات المناسب. يسأل العميل الموجود في بوابة الجملة الخاصة بك عن تسعير شركته المتفاوض عليه — يعرف الوكيل هذا السياق لأنه يعمل ضمن عرض المتجر هذا.

يضيف بُعد B2B في Magento — خاصة في Adobe Commerce — طبقة أخرى من تعقيد الدعم. لدى مشترين B2B حسابات شركات، وكتالوجات مشتركة بأسعار مخصصة، وقوائم إعادة توريد، وأوامر شراء، وسير عمل طلبات الاقتباس. هذه ليست حالات حافة — إنها أساسية لكيفية تفاعل مشترين B2B مع المنصة. يمكن لوكيل الذكاء الاصطناعي المتصل بنقاط نهاية واجهة برمجة تطبيقات REST الخاصة بـ B2B في Magento البحث في كتالوج الشركة المشترك لتأكيد أسعارها المتفاوض عليها على منتج معين. يمكنه التحقق من قائمة إعادة التوريد وإخبار المشتري بما إذا كانت أي عناصر قد نفدت من المخزون منذ آخر مرة قاموا فيها بتحديثها. يمكنه استرداد حالة عرض أو أمر شراء معلق للموافقة. بالنسبة لتجار B2B، هذه ليست راحة — إنها تحل محل جزء كبير من عمل إدارة الحسابات الذي كان سيتطلب بخلاف ذلك مندوب مبيعات مخصصًا أو وكيل خدمة عملاء للتعامل معه يدويًا.

الأداء مصدر قلق دائم لتجار Magento، وحقًا. تعمل متاجر Magento عادةً خلف ذاكرة التخزين المؤقت للصفحة الكاملة Varnish، وغالبًا ما يكون لديها Fastly أو Cloudflare كطبقة CDN. لقد أمضوا وقتًا في تكوين تدفئة ذاكرة التخزين المؤقت، وثقب التخزين المؤقت للمحتوى الديناميكي، وقواعد TTL لأنواع الصفحات المختلفة. يجب أن تعمل أي أداة تتم إضافتها إلى الموقع ضمن هذه البنية التحتية، وليس ضدها. يتم تحميل مقتطف JS الخاص بـ Asyntai بشكل غير متزامن — فهو لا يمنع عرض الصفحة، ولا يتداخل مع قواعد ذاكرة التخزين المؤقت لـ Varnish، ولا يتطلب أي تكوين لتحديث ذاكرة التخزين المؤقت أو ثقب التخزين المؤقت. المقتطف هو علامة برنامج نصي غير متزامن واحد. يقرأ الزاحف نفس الصفحات المخزنة مؤقتًا التي يراها زوارك. تظل مكدسة أداء Magento المُحسَّن بعناية دون تغيير.

تعكس عملية التثبيت كيفية عمل متاجر Magento بالفعل. لديك مساران. مسار المطور: أضف علامة البرنامج النصي إلى ملف تخطيط default_head_blocks.xml الخاص بالسمة، وقم بالنشر، وانتهيت. مسار المسؤول: الصق البرنامج النصي في كتلة ثابتة في CMS يتم الرجوع إليها في رأسك، واحفظ، ومسح ذاكرة التخزين المؤقت، انتهى. إذا كنت تستخدم بالفعل Google Tag Manager على متجرك، فيمكنك إضافة المقتطف كعلامة HTML مخصصة — لا توجد تغييرات في السمة، ولا نشر، ولا تحديثات Composer. النقطة هي أن إضافة وكيل الذكاء الاصطناعي لا تلمس قاعدة بيانات Magento الخاصة بك. لا توجد وحدة لتثبيتها، ولا حاجة لتشغيل setup:upgrade، ولا تكوين DI، ولا خطوة تجميع. إنه من جانب الواجهة الأمامية فقط — ملف JavaScript يتم تحميله في المتصفح، ويتحدث إلى الواجهة الخلفية لـ Asyntai. إصدار Magento الخاص بك، ووحداتك المخصصة، وخط أنابيب النشر الخاص بك — لا شيء منها يتغير.

نموذج المصادقة لأدوات واجهة برمجة تطبيقات Magento بسيط. تدعم Magento رموز التكامل — رموز واجهة برمجة تطبيقات طويلة الأمد تم إنشاؤها في لوحة الإدارة ضمن النظام > عمليات التكامل. تقوم بإنشاء تكامل مع إمكانية الوصول إلى موارد واجهة برمجة التطبيقات المحددة التي يحتاجها وكيل الذكاء الاصطناعي (الطلبات، المخزون، العملاء)، ونسخ رمز الوصول، ولصقه في حقل رأس المصادقة في لوحة تحكم الأدوات المخصصة كـ Authorization: Bearer your-integration-token. لا يصل الرمز أبدًا إلى متصفح العميل — يستدعي Asyntai واجهة برمجة تطبيقات Magento الخاصة بك من جانب الخادم، ويتلقى الاستجابة، ويستخدم البيانات لتكوين رد الدردشة. يبقى رمز التكامل الخاص بك بين البنية التحتية لـ Asyntai والواجهة الخلفية لـ Magento. يمكنك تحديد نطاق وصول التكامل إلى موارد القراءة فقط إذا كنت تريد أن يبحث الوكيل عن البيانات ولكن لا يعدلها — وهي نقطة بداية معقولة قبل تمكين عمليات الكتابة مثل إنشاء RMA.

تؤثر أنماط حركة المرور الموسمية على متاجر Magento بشكل خاص. الجمعة السوداء، والاثنين السيبراني، وتسوق العطلات، ومبيعات التصفية الموسمية — يمكن لهذه الأحداث أن تضاعف حركة المرور وحجم الطلبات بمقدار 5x أو 10x في غضون ساعات. يتبع حجم تذاكر الدعم. ترتفع "أين طلبي؟" في اليوم التالي لعملية بيع كبيرة. تزداد "هل هذا لا يزال متوفرًا في المخزون؟" خلال العروض الترويجية السريعة. تبلغ طلبات الإرجاع ذروتها في يناير. يعد توظيف موظفي دعم موسمي لمدة ثلاث أسابيع أمرًا مكلفًا ووقت الإعداد يعني أنهم بالكاد مدربون قبل أن تمر فترة الذروة. لا يحتاج وكيل الذكاء الاصطناعي إلى تدريب، ولا يحتاج إلى تعلم سياسة الإرجاع الخاصة بك، ولا يتباطأ عندما يرتفع الحجم. إنه يجيب على الألف "أين طلبي؟" بنفس الطريقة التي أجاب بها على الأول — من خلال استدعاء واجهة برمجة تطبيقات Magento الخاصة بك، والحصول على البيانات الحية، وتقديم إجابة كاملة. يركز فريق الدعم الخاص بك على المشكلات المعقدة — الحالات الشاذة، والتصعيدات، والعملاء الغاضبين الذين يحتاجون إلى لمسة إنسانية — بينما يتعامل الوكيل مع الحجم المتكرر الذي يشكل 70-80٪ من التذاكر خلال موسم الذروة.

تجدر الإشارة إلى البعد متعدد اللغات لأن البنية متعددة المتاجر في Magento تستخدم بشكل شائع لعروض المتجر القائمة على اللغة. قد يكون لدى التاجر الذي يخدم الولايات المتحدة وألمانيا وفرنسا ثلاثة عروض للمتجر بمحتوى مترجم إلى كل لغة. يتعامل وكيل الذكاء الاصطناعي مع هذا بشكل طبيعي. عند الزحف إلى عرض المتجر الألماني، فإنه يتعلم أوصاف المنتجات الألمانية وصفحات السياسات الألمانية ومحتوى CMS الألماني. عندما يسأل عميل في عرض المتجر هذا سؤالاً بالألمانية، يرد الوكيل بالألمانية — بالاعتماد على المحتوى الألماني الذي قام بالزحف إليه. تتم ترجمة استجابات الأدوات المخصصة من واجهة برمجة تطبيقات Magento (التي تُرجع البيانات عادةً بأسماء الحقول والقيم الافتراضية لواجهة برمجة التطبيقات) في الوقت الفعلي بواسطة الذكاء الاصطناعي إلى لغة العميل. يحصل العميل الألماني على إجابات ألمانية، حتى عندما تُرجع واجهة برمجة التطبيقات الأساسية أسماء حقول وقيم حالة باللغة الإنجليزية. لا يوجد عمل إضافي للتعريب على جانب Magento. يتولى الذكاء الاصطناعي طبقة الترجمة تلقائيًا.

توفر البيانات من سجلات استدعاء الأدوات المخصصة ذكاءً تشغيليًا يتجاوز تحليلات روبوت الدردشة الأساسية. عندما ترى أن 300 عميل هذا الشهر استدعوا أداة حالة الطلب، وأن 40٪ منهم كانوا في غضون 24 ساعة من تقديم طلبهم، فأنت تعلم أن رسائل تأكيد الطلب الخاصة بك لا تمنح العملاء ما يكفي من الثقة في إتمام عملية الشراء. عندما تزداد مكالمات فحص المخزون لرمز SKU محدد مدرج على أنه "متوفر في المخزون" على صفحة المنتج ولكنه يعود باستمرار بصفر كمية من واجهة برمجة التطبيقات، فقد وجدت مشكلة في المزامنة بين مصدر المخزون الخاص بك وفهرس Magento الخاص بك. عندما تتجمع طلبات الإرجاع حول فئة منتج معينة، فقد اكتشفت مشكلة في المزامنة بين المخزون وواجهة برمجة التطبيقات الخاصة بك. تصبح سجلات استدعاء الأدوات الخاصة بوكيل الذكاء الاصطناعي طبقة تشخيص في الوقت الفعلي لعملية Magento الخاصة بك — تكشف ليس فقط عما يسأله العملاء، ولكن ما يحاولون القيام به وأين يفشل متجرك في تلبية توقعاتهم.

يحصل تجار Magento الذين استثمروا بالفعل في واجهة برمجة تطبيقات REST الخاصة بهم — بناء نقاط نهاية لتطبيقات الهاتف المحمول، أو واجهات أمامية بدون رأس، أو تكاملات ERP، أو موصلات أسواق الطرف الثالث — على قيمة كبيرة من الأدوات المخصصة لأن نقاط النهاية هذه موجودة بالفعل. إنهم لا يبنون أي شيء جديد. إنهم يوجهون وكيل الذكاء الاصطناعي إلى نفس نقطة نهاية حالة الطلب التي يستخدمها تطبيق الهاتف المحمول الخاص بهم، ونفس نقطة نهاية المخزون التي يتحقق منها نظام نقاط البيع الخاص بهم، ونفس نقطة نهاية العميل التي تتم مزامنتها مع نظام إدارة علاقات العملاء (CRM) الخاص بهم. يصبح وكيل الذكاء الاصطناعي مستهلكًا آخر لنفس البنية التحتية لواجهة برمجة التطبيقات — وهو مستهلك يتمتع بواجهة محادثة ويخدم العميل مباشرة. الاستثمار الذي قاموا به في واجهة برمجة التطبيقات الخاصة بهم يحقق عائدًا لم يخططوا له: دعم مدعوم بالذكاء الاصطناعي يحل التذاكر باستخدام نفس مصادر البيانات التي تشغل بقية عملياتهم.

الواقع التنافسي لتجار Magento هو أن توقعات العملاء لا تتكيف مع تعقيد المنصة. يتوقع العميل الذي يتسوق في متجر Magento يحتوي على 50,000 منتج قابل للتكوين ومخزون متعدد المستودعات نفس تجربة الدعم الفورية والدقيقة التي يحصل عليها من متجر Shopify يحتوي على 50 منتجًا. يتوقعون أن يسألوا عن طلبهم ويحصلوا على رقم تتبع. يتوقعون أن يسألوا عن توفر المنتج ويحصلوا على إجابة حقيقية. يتوقعون طلب إرجاع ومعالجته دون إرسال ثلاثة رسائل بريد إلكتروني. تعقيد المنصة هو مشكلة التاجر، وليس مشكلة العميل. وكيل الذكاء الاصطناعي الذي يفهم هياكل كتالوج Magento ويتصل بواجهة برمجة تطبيقات REST الخاصة به يسد فجوة التوقعات هذه — حيث يقدم تجربة الدعم الفورية والقائمة على البيانات التي يطلبها العملاء، بغض النظر عن التعقيد الهيكلي وراء الكواليس.

مسار الانتقال من التثبيت إلى وكيل ذكاء اصطناعي يعمل بكامل طاقته على متجر Magento يتبع عادةً تقدمًا واضحًا. الأسبوع الأول: أضف المقتطف، ودع الوكيل يزحف إلى الكتالوج والمحتوى، وقم بتمكينه لأسئلة المنتج والسياسة الأساسية. يتعامل الوكيل على الفور مع "ما هي سياسة الإرجاع الخاصة بك؟" و "هل تشحنون إلى كندا؟" و "أخبرني عن جاكيت Alpine Performance" — تعمل طبقة قاعدة المعارف من اليوم الأول. الأسبوع الثاني: قم بتوصيل واجهة برمجة تطبيقات حالة الطلب ونقاط نهاية فحص المخزون. الآن يتعامل الوكيل مع "أين طلبي؟" و "هل هذا متوفر في المخزون؟" — وهما أعلى سؤالين دعم في التجارة الإلكترونية. الأسبوع الثالث: أضف معالجة المرتجعات، والبحث عن حساب العميل، وأي نقاط نهاية متخصصة يحتاجها متجرك. بحلول نهاية الشهر، سيتعامل وكيل الذكاء الاصطناعي مع غالبية حجم الدعم الخاص بك بشكل مستقل، وسيركز وكلاء الدعم البشريون لديك على المشكلات المعقدة التي تحتاج حقًا إلى شخص، وستبدو قائمة انتظار الدعم الخاصة بك مختلفة بشكل أساسي عما كانت عليه قبل ثلاثين يومًا. ليس لأنك نشرت منصة ذكاء اصطناعي للمؤسسات. لأنك أضفت علامة برنامج نصي وأشرت إلى بعض الأدوات لواجهة برمجة التطبيقات إلى نقاط نهاية كانت موجودة بالفعل.