المشكلة

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

دوري في المشروع

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

البنية المعمارية

• مساعد وكيل لا روبوت محادثة بنصوص جاهزة: يتولى حالة الطلبات والمساعدة في الدفع ودعم العملاء مباشرة على واجهة المتجر، فينفّذ الخطوات التي كان موظف الدعم سيقوم بها بدل تحويل العميل إليه.
• تنسيق تدفقات النماذج اللغوية عبر واجهات OpenAI و Anthropic Claude و Google Gemini — دون ارتباط بمزوّد واحد، مع توجيه كل خطوة إلى النموذج الأنسب لها.
• طبقة الأتمتة هي ما يجعل الفكرة قابلة للتطبيق: خطافات ويب وطوابير وعقود واجهات برمجية صريحة تربط المساعد بالطلبات والمدفوعات والإشعارات. والطوابير هنا أهم مما تبدو؛ فالمحادثة يجب ألّا تتوقف بانتظار نظام بطيء، والإجراء الفاشل يجب أن يكون قابلًا لإعادة المحاولة لا أن يضيع داخل سجل محادثة.
• تحمل منصتا n8n و Zapier أتمتة المبيعات والتشغيل، فتبقى هذه المسارات قابلة للتعديل من جانب فريق العمل بدل حبسها داخل كود يحتاج إلى مطوّر عند كل تغيير.
• تسلسلات آلية لالتقاط العملاء المحتملين ومتابعتهم في جانب المبيعات، لتنتهي المحادثة التي ليست طلب دعم إلى نتيجة مفيدة كذلك.

التقنيات

واجهات OpenAI و Anthropic Claude و Google Gemini، ومنصتا n8n و Zapier، وخطافات الويب والتكامل القائم على الطوابير.

النتيجة

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