العملية المكسورة خلف الطلب

«إحنا عايزين Chatbot زي ChatGPT يرد على العملاء بدل الموظفين ويكون شغال 24 ساعة.»

هذا هو الطلب الذي أسمعه أكثر من أي طلب آخر، وبهذه الصياغة أو ما يقاربها.

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

والفكرة تأتي عادةً من موضع بعينه: فيديو Demo مبهر، أو منافس أعلن أنه أضاف AI، أو تجربة ناجحة مع ChatGPT جعلت نقل التجربة نفسها إلى الشركة يبدو خطوة تقنية بسيطة.

الطلب يسمّي واجهة

لا شيء في ذلك غير معقول. غير أنه ليس وصفًا لنظام.

الـChatbot واجهة لا مشروع. هو طريقة للحديث إلى شيء، والعميل يسمّيه لأنه الجزء الذي يستطيع تخيّله من العمل. أمّا كل ما يجعله نافعًا فيقع خلفه، ولا يظهر منه شيء في الطلب.

فأول ما أفعله أن أتوقّف عن مناقشة الواجهة. لا أن أعترض عليها — بل أن أنحّيها جانبًا مدّة تكفي لأسأل: ما العملية المكسورة التي يُطلب منّا إخفاؤها خلفها؟

الرسائل لم تكن عن المحادثة

طلب منّي عميل في قطاع التجزئة Chatbot يردّ على كل استفسارات العملاء.

وقبل أن أبني شيئًا طلبت أن أقرأ الرسائل التي أرسلها العملاء فعلًا. لا ملخّصًا لها، ولا وصفًا للحالات الشائعة. الرسائل نفسها. هذه هي الطريقة كلها، وليس فيها ذكاء.

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

وأي Chatbot يوضع فوق هذه الثلاثة كان سيضطرّ إلى أن يخترع إجاباته في الثلاث جميعًا، وكان سيفعل ذلك بطلاقة.

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

وهذا شيء أقلّ إبهارًا في الـDemo من Bot مفتوح يحاول أي شيء. وهو ما طلبته الرسائل.

تحت الطلب واحدة من ثلاث مشكلات

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

معلومات لا يمكن الوصول إليها. هي موجودة، وفي الشركة من يعرف الإجابة، وليس لدى السائل سبيل إلى أيٍّ منهما.

أو عملية داخلية تقوم على أن ينقل أحدهم الأشياء نفسها بيده من مكان إلى مكان.

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

ومعلومات المنتجات المبعثرة عند ذلك العميل كانت الأولى من الثلاث. والـChatbot يمكن أن يوضع فوق أيٍّ منها. ولا يزيل أيًّا منها.

الاجتماع الأول ستة أسئلة

لا أصل إلى المشكلة الحقيقية بالفطنة. أصل إليها بأن أسأل الأسئلة نفسها، بأي ترتيب تسمح به المحادثة.

ما المهمة التي تريد من المستخدم إنهاءها؟ ما أكثر شيء يتكرّر يوميًا؟ من أين ستأتي الإجابة؟

ماذا يحدث لو كانت الإجابة خاطئة؟ متى يجب أن يتدخّل موظف؟ ومن سيحدّث النظام بعد إطلاقه؟

ولا واحد من هذه الأسئلة عن الـChatbot. وهذا هو المقصود منها.

و«الردّ على كل استفسار» ليس مهمة. أن تعرف أين وصل طلبك مهمة، والمهمة شيء يمكن أن يُقاس عليه النظام حين يكتمل. وإن لم يكن ثمّة شيء يتكرّر، فليس ثمّة شيء يستحقّ أن يُبنى.

للإجابة مصدر، وإلا فهي مخترعة

إن لم يكن هناك مصدر، فسينتج النظام مصدرًا. وهذا ليس عيبًا في الموديل. هذا هو ما طلبتَه منه.

وسؤال «ماذا يحدث لو كانت الإجابة خاطئة؟» هو النصف الآخر من السؤال نفسه، والإجابة عنه هي التي تحدّد ما يُمنح النظام من حرية.

الإجابة الخاطئة الرديئة الصياغة يُتحقَّق منها. والخاطئة الحسنة الصياغة تُصدَّق ويُبنى عليها عمل.

أريد اسمًا

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

بدا أن الحل صار أقلّ ذكاءً

أراد عميل آخر مساعد مبيعات ذكيًا يرشّح المنتجات ويجيب عن الأسعار والتوافر. والبيانات التي تحته لم تكن محدَّثة.

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

وكان شعوره الأول أن الحل أصبح «أقلّ ذكاءً». وهذا شعور له وجهه. أمّا ما أدركه بعد ذلك فهو الجزء الذي يستحقّ أن يبقى: أن الذكاء الحقيقي هو أن يعمل النظام، لا أن يبدو مبهرًا في العرض.

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

عمل أرفضه

هناك طلبان لا آخذهما.

الأول ضمان دقة كاملة من بيانات غير مكتملة. لا دقة أفضل — ضمان. والبيانات لا تحتوي على ما يتطلّبه ذلك.

والثاني نظام يتّخذ قرارات حسّاسة من دون مراجعة بشرية.

وما يخرج من أيٍّ منهما ليس منتج AI، بل طريقة أسرع وأكثر إقناعًا لإنتاج الأخطاء.

ينجح في الـDemo ويفشل أمام المستخدم

وأحيانًا لا يقع شيء من هذا موقعه، ويريد العميل ما جاء من أجله. وهذا قراره هو.

وغالبًا ينجح المشروع في الـDemo، والـDemo يُجرى على أسئلة مرتّبة، يختارها أناس يعرفون سلفًا ما يستطيع النظام فعله. أمّا أمام مستخدم حقيقي فالأسئلة أقلّ ترتيبًا، والبيانات أقدم، والاستثناءات أكثر ممّا سمحت به الخطة. فيضطر الفريق بعد الإطلاق إلى تضييق النطاق، وإضافة القواعد، وبناء التحويل إلى موظف بشري — وهو عمل كان يمكن تحديده من البداية، ويُنجَز الآن على عجل وعلى نظام حيّ.

والعمل يُنجَز في الحالين. وإنجازه أولًا هو النسخة الرخيصة منه.

ما الذي يكون حاضرًا حين ينجح المشروع

حين يسير أحد هذه المشاريع كما ينبغي، لا يكون السبب هو التقنية.

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

وهذا تعريف للنجاح، لكنه ليس التعريف الذي في الطلب الأصلي. فالنجاح ليس أن يردّ الـBot على كل شيء، بل أن يعرف متى يجيب ومتى يتوقّف.

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

عند الإطلاق تبدأ المعلومات في التقادم

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

الـAI لا يصلح الفوضى الموجودة في الشركة. بل يقرأها، ويكرّرها، ويوزّعها على عدد أكبر من الناس.