AWS تختصر إنتاج الصفحات التسويقية من ساعات إلى دقائق بفضل الذكاء الاصطناعي الوكيلي

روت AWS كيف نقلت فرقتها التسويقية الداخلية عملية بناء صفحات المحتوى إلى نمط شبه آلي يعتمد على الذكاء الاصطناعي الوكيلي. فقد اختصر الحل المبني على Amazon Bedrock، والذي طُوّر بالتعاون مع Gradial، إعداد صفحة ويب واحدة من نحو أربع ساعات إلى عشر دقائق تقريبًا، دون التخلي عن فحوص الجودة.

أين كانت العملية تتعثر

تصف AWS السيناريو المعتاد للمسوّق على النحو التالي: موجز الحملة، ثم اجتماع مع الفريق الرقمي، ثم إدراج المهمة في قائمة الأعمال المتراكمة (backlog)، وبعدها البناء اليدوي للصفحة في نظام إدارة المحتوى (CMS). وحتى عندما تكون المهمة نفسها بسيطة، يلتهم الوقتَ ضبطُ إعدادات الكتل وتوزيع المحتوى والموافقات وتكرار التعديلات. وتبرز المشكلة بوضوح خاصة في بيئة الشركات الكبرى، إذ يجب أن تلتزم الصفحة الواحدة في الوقت نفسه بقواعد العلامة التجارية ومتطلبات SEO وإمكانية الوصول وإجراءات النشر الداخلية قبل إطلاقها في بيئة الإنتاج على المنصات الرقمية العالمية.

• بناء الكتل والتخطيطات يدويًا في CMS
• تأخيرات بسبب مراجعة النصوص والروابط والمواد الإبداعية
• الاعتماد على المهندسين عندما لا تكفي المكوّنات الجاهزة
• التحقق المتأخر من SEO وإمكانية الوصول ومعايير العلامة التجارية

وخلاصة AWS الأساسية أن الأمر ليس مجموعة مشكلات صغيرة منفصلة، بل خلل منهجي واحد في العملية. فقد كانت الجودة تُراقَب في وقت متأخر جدًا، وكان معظم الوقت يذهب في البناء الآلي للصفحات بدلًا من الاستراتيجية التسويقية. ونتيجة لذلك أمضى المسوّقون ساعات في عمليات يمكن تقنينها: اختيار المكوّنات المناسبة، وبناء الهيكل، وتشغيل الفحوص، وتسليم الصفحة للنشر دون سلسلة طويلة من الإجراءات اليدوية.

كيف يعمل الحل

يقوم النظام الجديد على Amazon Bedrock ونماذج Anthropic Claude وAmazon Nova. يصف المسوّق مهمته بلغة عادية: ما الصفحة المطلوب بناؤها، وما الكتل التي تحتاجها، وما المخرجات المرجوة. بعد ذلك يفسّر وكيل Gradial الطلب، ويحدد بنية الصفحة، ويختار المكوّنات، ويُنشئ التهيئة التي كانت تتطلب سابقًا معرفة بالمنطق الداخلي لنظام CMS. وبذلك تتحول واجهة المؤلف من مجموعة نماذج معقدة إلى حوار يفكك فيه النظام المهمة إلى خطوات بنفسه.

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

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

ما الذي تغيّر بعد ذلك

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

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

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

ماذا يعني ذلك

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