قد تبدأ رحلة الخروج إلى فعالية من سؤال بسيط مثل: «ماذا نفعل الليلة؟».
لكن هذا النوع من الطلبات لا يناسب دائماً البحث التقليدي القائم على اسم حدث أو تاريخ أو موقع محدد، ولذلك تتجه منصات الحجز إلى استخدام الذكاء الاصطناعي لفهم النية أولاً، ثم تحويلها إلى خيارات متاحة فعلياً للحجز.
يقول نديم بخش، الرئيس التنفيذي والشريك المؤسس لمنصة «webook.com»، إن تطوير وكيل الحجز القائم على الذكاء الاصطناعي لم يكن نتيجة قصور في أدوات البحث الحالية، بل محاولة لإضافة طبقة جديدة للاكتشاف عندما تكون رغبة المستخدم غير مكتملة أو غير محددة منذ البداية. ويفيد خلال لقاء خاص مع «الشرق الأوسط» بأن البحث والفلاتر يظلان مناسبين عندما يعرف المستخدم ما الذي يريده، بينما تتطلب الأسئلة المفتوحة فهماً للسياق قبل الوصول إلى الخيار المناسب.
من الكلمات المفتاحية إلى فهم النية
يعتمد الوكيل في نسخته الأولى على معالجة اللغة الطبيعية بالعربية والإنجليزية، مع القدرة على التعامل مع طلبات غير رسمية تتضمن الموقع أو التفضيلات أو نوع المجموعة أو معايير الحجز. ولا يحتاج المستخدم، حسب بخش، إلى صياغة مصطلحات بحث رسمية أو معرفة اسم الحدث مسبقاً، بل يمكنه طرح طلب طبيعي مثل نشاط عائلي أو تجربة قريبة أو فعالية متاحة في المساء.
ويقوم النظام بعد ذلك بتفسير النية، وتحديد المعلومات ذات الصلة، ثم ربطها بالخيارات الموجودة في الكتالوج الحي للمنصة. وإذا كانت بعض المعلومات الأساسية ناقصة، فالتصميم يفترض أن يطلب الوكيل توضيحها بدلاً من إرجاع قائمة عامة لا تعكس حاجة المستخدم. لكن هذا النوع من التفاعل يضع الدقة في قلب التجربة. فكلما تحولت رحلة الاكتشاف من البحث الصريح إلى المحادثة، ارتفع احتمال إساءة فهم السؤال أو تفسيره بصورة غير دقيقة.
عندما يخطئ الوكيل
يقر بخش بأن الخطأ جزء من استخدام أنظمة الذكاء الاصطناعي، ويقول إن الوكيل «يجب ألا يتظاهر بالمعرفة». فإذا كان الطلب غير واضح أو ناقصاً، يفترض أن يطلب مزيداً من المعلومات بدلاً من فرض توصية غير موثوقة.
وتظل صفحة الحجز الرسمية المرجع النهائي بالنسبة إلى التوافر والأسعار والرسوم وشروط الفعالية. فإذا تغيرت المعلومات أو نفدت التذاكر قبل إتمام عملية الشراء، فإن البيانات التي تظهر في مسار الحجز الرسمي هي التي تعتمد، لا ما ورد في المحادثة السابقة.
ويضيف بخش أن الوكيل يجب أن يحيل المستخدم إلى تفاصيل الحدث الرسمية أو إلى الدعم البشري عندما لا يستطيع التحقق من معلومة. كما يرى أن التصحيح اللاحق من المستخدم يمكن أن يساعد النظام على تحسين الإجابة التالية، لكنه لا يقدم ذلك باعتباره ضماناً لعدم تكرار الأخطاء.
التوصية والإعلان… أين يبدأ الفصل؟
تتحول مسألة الثقة أيضاً إلى سؤال تجاري عندما يصبح الوكيل مسؤولاً عن ترتيب الفعاليات واقتراحها على المستخدم. يرى بخش أن وظيفة النظام هي مطابقة نية المستخدم مع الخيارات المتاحة فعلياً للحجز، وليس تقديم الإعلانات المدفوعة على أنها نصيحة شخصية. وتستند التوصيات، حسب إجابته، إلى معايير يقدمها العميل مثل الموقع والتوقيت ونوع المجموعة وتفضيل النشاط، إضافة إلى التوافر الحي.
ويشدد على أن أي موضع مدفوع أو برعاية يجب أن يكون محدداً بوضوح، بحيث يتمكن المستخدم من التمييز بين التوصية العضوية والمحتوى التجاري، مضيفاً أن «الثقة تعتمد على وضوح هذا الفصل».
رحلة موزعة بين القنوات
تزداد تعقيدات التجربة عندما تبدأ المحادثة خارج تطبيق الحجز نفسه، عبر منصات مثل «X» أو «إنستغرام» أو «واتساب». يوضح بخش أن الوكيل يستخدم المعلومات التي يختار المستخدم تقديمها، مثل الموقع والتوقيت ونوع المجموعة والاهتمامات ومعايير الحجز، بهدف تقديم خيارات أكثر ملاءمة. أما التفاعلات العامة، فتبقى محصورة في مرحلة الاكتشاف، وعندما تتطلب الرحلة مستوى أعلى من الخصوصية تنتقل إلى قناة خاصة، ثم إلى بيئة الحجز الآمنة التابعة لـ«webook.com».
ويؤكد أن بيانات البطاقات والمعلومات الشخصية الحساسة لا ينبغي طلبها عبر منشور عام أو تعليق أو رسالة مباشرة على وسائل التواصل الاجتماعي، فيما تخضع البيانات الشخصية لسياسة الخصوصية ومتطلبات الاحتفاظ القانونية والتنظيمية. كما يشير إلى أن البيانات لا تُعامل باعتبارها قابلة للانتقال الحر بين القنوات، وأن أي تخصيص يعتمد على الأذونات التي يمنحها المستخدم والغرض الذي جُمعت البيانات من أجله.
ما الذي تطوره المنصة وما الذي يأتي من الخارج؟
لا يعتمد الوكيل بالكامل على تقنيات مطورة داخلياً. فبحسب بخش، تتولى «webook.com» تطوير وتشغيل طبقة المنتج الأساسية وآلية التنسيق، بما يشمل فهم نية الحجز، وربطها بالكتالوج، وتطبيق منطق المنتج، وإنشاء التوصيات، وتوجيه المستخدم نحو مسار الحجز الآمن.
وفي المقابل، تستخدم المنصة بنية خارجية عند الحاجة لمعالجة النماذج اللغوية، والخدمات السحابية، والوصول إلى قنوات مثل «X» و«إنستغرام» و«واتساب».
ويقول بخش إن مزودي هذه الخدمات يقدمون البنية أو قنوات التوزيع، لكنهم لا يملكون مخزون الفعاليات أو منطق الحجز أو رحلة العميل. كما لا تكشف الشركة تفاصيل البنية الخاصة بالموردين أو معلومات التنفيذ الحساسة أمنياً. ويؤكد في الوقت نفسه أن الوكيل لا يزال في المرحلة التجريبية «Beta»، وقد يرتكب أخطاء، ولذلك ينبغي للمستخدم التحقق من تفاصيل الحدث ومعلومات الحجز النهائية عبر الصفحة الرسمية قبل إتمام أي معاملة.
فصل الاكتشاف عن المعاملة
يشكل الفصل بين المحادثة وعملية الدفع أحد أهم عناصر الحماية في التصميم الموصوف. فقد يرد الوكيل على طلب عام في مساحة مفتوحة، لكنه ينقل التفاعل إلى قناة خاصة عندما تصبح الخصوصية ضرورية، ثم يوجه المستخدم إلى مسار رسمي مرتبط بالهوية لإتمام الحجز. ولا يطلب بيانات بطاقات أو معلومات حساسة عبر المنشورات أو التعليقات أو الرسائل المباشرة في وسائل التواصل.
ويصرح بخش بأن هذه البنية تساعد على الحد من آثار محاولات التلاعب بالمطالبات وانتحال الهوية والحسابات الاحتيالية وروابط الحجز المزيفة. ويتابع أن طبقة المحادثة يمكنها المساعدة على اكتشاف الفعالية، لكنها لا تتجاوز ضوابط المخزون أو الحساب أو السعر أو الدفع الموجودة على المنصة الرسمية.
السعر والشروط لا يحددها الوكيل
عندما ينتقل المستخدم من مرحلة الاكتشاف إلى الشراء، تتوقف صلاحية الوكيل عند حدود واضحة. فالخيارات تأتي من الكتالوج الحي، لكن صفحة الحجز الرسمية تبقى سطح المعاملة المعتمد. وقبل التأكيد، يرى المستخدم التوافر الحالي، والسعر النهائي، ورسوم الحجز، والشروط الخاصة بالفعالية، بما فيها الإلغاء والاسترداد.
ولا يستطيع الوكيل تغيير هذه الشروط أو ضمان استمرار التذكرة متاحة أثناء انتظار المستخدم. كما تُعرض قيود العمر ومتطلبات إمكانية الوصول فقط عندما تكون مدرجة في التفاصيل الرسمية، وإذا لم تكن المعلومة واضحة فلا يفترض بالنظام أن يخمنها. وبهذا، يغير الذكاء الاصطناعي طريقة الوصول إلى الخيار، لكنه لا يغير الشروط التعاقدية أو الضوابط التي تحكم عملية الشراء.
يربط بخش الوكيل أيضاً بإطار أوسع يحمل اسم «TruFan»، لكنه يميز بين وظيفتيهما. فالوكيل يعمل في بداية الرحلة، عبر تحويل الطلبات الطبيعية إلى خيارات قابلة للحجز، بينما يرتبط «TruFan» بمرحلة مختلفة تتعلق بالنزاهة والوصول إلى الفعاليات ذات الطلب المرتفع من خلال المساعدة على تحديد المشجعين الحقيقيين والمتحقق منهم وإعطائهم الأولوية.
