موافقة متأخرة، ومهلة انتهت، و«من وافق؟»: الأسئلة الصعبة عن وكلاء الذكاء الاصطناعي الذين ينفّذون عمليات

طرحنا سؤالاً بسيطاً في مجتمع لمن يبنون ويشغّلون وكلاء الذكاء الاصطناعي: حين ينفّذ الوكيل عمليات حقيقية لزبون (إلغاء طلب، أو بدء إرجاع، أو نقل حجز)، ما أصعب جزء؟

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

1. ماذا يحدث حين تصل موافقة الزبون متأخرة؟

الموافقة المتأخرة قد تكون أسوأ من عدم الرد: ربما تغيّر الموعد، أو شُحن الطلب، أو تغيّر السعر.

في Allowfy، لكل عرض شروط دقيقة ورقم نسخة ووقت انتهاء:

• موافقة الزبون مرتبطة بنسخة واحدة من الشروط. إذا تغيّرت الشروط، تُرفض الموافقة على النسخة القديمة (terms_changed)، ويلزم موافقة جديدة.
• بعد انتهاء العرض، لا يمكن تأكيده إطلاقاً، ولا يحدث شيء.
• قبل التنفيذ، يقرأ Allowfy الحالة الحالية من جديد: يجب أن يكون الطلب موجوداً، ولنفس الزبون، وما زال قابلاً للإلغاء أو الإرجاع. إذا تغيّر الوضع، تتوقف العملية وتقول السبب.

2. حين تنتهي مهلة الموافقة، هل تُرفض العملية أم تمر؟

تُرفض. العرض الذي لم يؤكده أحد ينتهي، ولا يتغيّر شيء. أنت تختار مدة بقاء العروض مفتوحة (دقائق للحجز، وأطول للإرجاع)، ويعرف الوكيل وقت الانتهاء بالضبط حين يقترح.

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

3. أُرسل الأمر وانتهت مهلة الاتصال. هل حدث أم لا؟

هذه الحالة لا تحسبها أغلب الأنظمة. تعيد المحاولة، فيصبح هناك إرجاعان.

Allowfy يعامل «لا نعرف» كحالة حقيقية:

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

4. «200 OK» ليست دليلاً. كيف تعرف أن العملية حدثت فعلاً؟

قد يقبل المتجر الطلب ولا ينفّذه: كتابة في طابور ضاعت، أو مهمة لم تعمل.

لذلك بعد أي تغيير، يقرأ Allowfy الطلب من جديد من المتجر. إذا لم يظهر التغيير بعد، تصبح النتيجة غير مؤكدة لا ناجحة، ويسري نفس المسار: إعادة محاولة ثم شخص. والنص الذي يوافق عليه الزبون يقول ما سيحدث فعلاً: مثلاً، الإلغاء لا يَعِد بإعادة المبلغ إلا في المنصات التي يطلب فيها الإلغاء استرداداً فعلاً؛ وفي غيرها يقول إن الاسترداد يعود للمتجر.

5. حين تذهب عملية للمراجعة، كيف تصل لشخص، وماذا يحدث وهي تنتظر؟

طابور مراجعة لا ينظر إليه أحد هو مجرد طريقة أبطأ لقول «لا».

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

6. هل التحقق من هوية الوكيل يثبت أن الزبون وافق؟

لا، ومن المهم الفصل بين الأمرين:

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

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

7. في النزاع، سجلّ من يُحتسب؟

سجلّ من استلم المال: النشاط التجاري. سجل داخل قاعدة بيانات مزوّد الوكيل لا يفيد التاجر كثيراً.

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

8. أين يجب أن يوافق الإنسان؟

على الخطوات التي لا رجعة فيها: المال، والشحن، وكل ما لا يمكن التراجع عنه. قراءة حالة الطلب لا تحتاج موافقة أحد؛ واسترداد 500 ربما يحتاج موافقتين.

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

9. هل يجب تسجيل ما كان الوكيل يعتقده، لا ما حدث فقط؟

نعم. كثير من حالات «الوكيل أخطأ» تكون في الحقيقة وكيلاً محقاً بناءً على معلومات قديمة.

يسجّل Allowfy الشروط الدقيقة لحظة الاقتراح: الطلب كما كان، والمبلغ، والتاريخ، إضافة إلى القاعدة ونسخة السياسة التي قررت. وحين ينفّذ، يقارن بالطلب كما هو الآن. فتستطيع التمييز بين «الوكيل فهم خطأ» و«الطلب تغيّر في الأثناء».

باختصار

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

تستطيع تجربة كل هذا مجاناً في الوضع التجريبي، حيث تمر العمليات بكل مراحلها ولا يتغيّر شيء في متجرك. واعرف إن كان موقعك جاهزاً لوكلاء الذكاء الاصطناعي بفحص Allowfy Check المجاني.