مشكلة الثقة بالوكلاء أصبحت مشكلة استهلاكية.

على مدار العامين الماضيين، كان العمل المثير في تصميم الوكلاء يجري داخل المؤسسات، بهدوء. كيف تسمح لوكيل بقراءة حقل واحد في Salesforce دون أن يتمكّن من قراءة قاعدة البيانات كاملة. وكيف تسمح له بإرسال رسالة WhatsApp بالنيابة عن عميل دون أن يُغرقه بالرسائل. وكيف تُخبر المستخدم، في اللحظة نفسها، بما يوشك الوكيل على فعله — قبل أن يفعله.

بقي ذلك العمل غير مرئي لأن المؤسسات لا تنشر مواصفات تصميمها. وكان بطيئاً لأن الجماهير صغيرة ودورات المراجعة طويلة.

غيّر Meta Muse ذلك في أسبوع واحد.

مليار مستهلك يتعلّمون في الوقت نفسه ما هو الوكيل

لا يضيف Muse نافذة محادثة إلى Instagram فحسب، بل يمنح كل حساب في Meta وكيلاً شخصياً قادراً على التنفيذ — الحجز والتصفّح والتذكّر والعمل بين التطبيقات. يُقاس الانتشار بمئات الملايين من المستخدمين، لا بالآلاف. وكل واحد منهم يوشك أن يتعلّم، بالطريقة الصعبة عادةً، أن السماح لوكيل بالتصرّف بالنيابة عنك علاقة مختلفة جوهرياً عن محادثة روبوت دردشة.

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

بعض ذلك خطأ في النموذج. لكن أكثره مشكلة في تجربة الموافقة.

مشكلة تجربة الموافقة، باختصار

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

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

ما الذي يتغيّر الآن

ثلاثة أمور.

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

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

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

أين كنا نُطبّق هذا

في الوكلاء الصوتيين على WhatsApp لدى GWC، سطح الموافقة مقصود بتصميمه. يقول العميل ما يريد. ويؤكّد الوكيل ما يوشك على فعله، في قناة الصوت نفسها، قبل أن يفعله. وإن كانت الثقة منخفضة سأل. وإن كان الإجراء غير قابل للتراجع سأل مرّتين. النمط بسيط وهو ناجح — لكن فقط لأننا صمّمنا الوكيل حوله من البداية، لا لأننا أضفناه لاحقاً بعد عرض تجريبي.

هذا هو الجزء الذي تجاوزه Muse. وهو الجزء الذي على كل منتج وكيل جدّي أن يفكّر فيه الآن، شاء أم لم يشأ.

ما ينبغي فعله هذا الأسبوع

• ›إن كنت تُطلق وكيلاً استهلاكياً: اجمع ثلاثة من مستخدميك في غرفة وراقبهم يستخدمونه. كل لحظة تردّد هي فجوة موافقة.
• ›إن كنت تُطلق وكيلاً مؤسسياً: حصل مسؤول أمن المعلومات لديك على ذريعة جديدة. استبق الحديث قبل أن يطرحه هو.
• ›إن كنت قائد منتج تُراقب من بعيد: الأدوار التصميمية التي ستحتاجها بعد ستة أشهر غير موجودة بعد. ابدأ البحث الآن.

الوكلاء قادمون إلى كل منتج. والثقة ليست تلقائية. والفرق التي تحلّ مشكلة تجربة الموافقة هي التي تكسب العقد القادم.