سألني صاحب متجر في الكويت: «كم يكلّف روبوت يرد على عملائي؟» رددت بسؤال آخر: ومن سيكتب الردود؟ صمت طويل. هنا تتعثّر معظم مشاريع المحادثة الآلية التي رأيتها — لا في اختيار النموذج، بل في اللحظة التي يتضح فيها أن لا أحد يملك الإجابات مكتوبة أصلاً.
قبل أن تطلب عرض سعر، افصل بين ثلاثة أشياء يخلطها الجميع تحت اسم واحد: قوائم أزرار جاهزة، روبوت محادثة بالذكاء الاصطناعي مبني على قاعدة معرفة، ووكيل ينفّذ إجراءات داخل أنظمتك. الثلاثة تُباع بالكلمة نفسها، وتكلفتها ومخاطرها ليست متقاربة إطلاقاً.
ما الذي يفعله روبوت محادثة بالذكاء الاصطناعي فعلياً؟
روبوت محادثة بالذكاء الاصطناعي برنامج يقرأ سؤال العميل بلغته الطبيعية، يبحث عن الجواب في محتوى تملكه أنت، ثم يصوغ رداً. هو ليس عقلاً يعرف شركتك، ولا موظفاً يتعلّم بالخبرة. جودته محكومة بجودة ما أطعمته إياه: صفحات المنتجات، سياسة الإرجاع، أسعار الشحن، وقائمة ما لا يجوز له قوله.
الفرق بينه وبين القوائم القديمة أنه لا يحتاج أن يضغط العميل زراً. يكتب «طلبي متأخر ليش؟» فيفهم النية. لكن الفهم شيء والمعرفة شيء آخر: إن لم تكن سياسة التأخير مكتوبة عندك في مكان يقرأه الروبوت، فسيؤلّف جواباً معقول الشكل، خاطئ المضمون.
خذ مثالاً واقعياً من متجر إلكتروني: عميل يسأل «يوصل جليب الشيوخ اليوم؟». الجواب يحتاج ثلاث معلومات: هل المنتج متوفر، ما مناطق التوصيل في اليوم نفسه، وما وقت إغلاق الطلبات. لو كانت هذه الثلاث مكتوبة ومحدّثة، فأي بناء تقني معقول يجيب. ولو كانت في رأس مدير المستودع وحده، فلا نموذج في العالم سيخرجها منه.
وهذه أخطر نقطة في المشروع كله. جواب مؤلَّف بثقة أسوأ من «لا أعرف».
قوائم جاهزة، قاعدة معرفة، أو وكيل: أي نوع يناسب مشكلتك؟
اختر نوع روبوت المحادثة حسب السؤال الذي يصلك أكثر من غيره. القوائم الجاهزة تكفي إن كانت أسئلة عملائك محدودة ومتكررة: مواعيد العمل، مواقع الفروع، حالة الطلب. روبوت قاعدة المعرفة يلزم حين تتنوع الصياغات وتتشعّب التفاصيل. أما الوكيل المتصل بالأنظمة فيُبرَّر فقط حين يكون المطلوب تنفيذ إجراء، لا شرحه.
| النوع | يصلح لـ | الجهد المعتاد في تجربتي | أكبر خطر |
|---|---|---|---|
| قوائم أزرار جاهزة | أسئلة متكررة قليلة العدد وثابتة الصياغة | أيام: رسم شجرة الخيارات وصياغة نصوصها | العميل يخرج عن الشجرة فيصل إلى طريق مسدود |
| روبوت مبني على قاعدة معرفة | أسئلة متنوعة الصياغة حول منتجات وسياسات وشروط | أسابيع: تحرير المحتوى المصدر وتنظيفه أطول من البرمجة | محتوى قديم أو متناقض ينتج إجابات واثقة وخاطئة |
| وكيل متصل بالأنظمة | تنفيذ إجراء: إلغاء، تعديل موعد، تحديث عنوان شحن | أشهر: صلاحيات واختبارات ومسار تراجع لكل إجراء | إجراء يُنفَّذ على بيانات حقيقية بلا إذن واضح |
لاحظ أن العمود الثالث لا يتحدث عن البرمجة. في المشاريع التي أدرتها، الجزء البرمجي في روبوت قاعدة المعرفة هو الأقصر؛ تحرير المحتوى وتوحيد المصطلحات هو الذي يلتهم الجدول الزمني. رأيي بصراحة: إن لم تكن مستعداً لتفريغ شخص من فريقك للمحتوى، ابدأ بالقوائم الجاهزة ولا تدفع في الذكاء الاصطناعي بعد.
من يكتب قاعدة المعرفة ومن يحدّثها؟
قاعدة المعرفة هي المحتوى المكتوب الذي يستمد منه الروبوت إجاباته: سياسات وأسعار وشروط وخطوات. يجب أن يملكها شخص باسمه داخل شركتك، لا الوكالة ولا المطوّر. المطوّر يبني القناة، أما صحة الجواب فمسؤولية من يعرف العمل. وبلا مالك معروف، تتقادم القاعدة خلال أشهر ويبدأ الروبوت في الكذب بحسن نية.
ابدأ من مكان غير متوقع: سجل محادثات خدمة العملاء لديك في آخر ثلاثة أشهر. اقرأ مئة محادثة حقيقية بعينك، لا بعين تقرير مختصر. ستكتشف أن الأسئلة تتكرر في عائلات قليلة، وأن كل عائلة تُصاغ بعشر طرق مختلفة. اكتب لكل عائلة جواباً واحداً نهائياً، ووقّع عليه من يملك القرار في القسم المعني. هذه الوثيقة، لا النموذج، هي المنتج الفعلي. والروبوت مجرد واجهة لها. وإن تغيّرت سياسة الإرجاع غداً، فالتعديل يجري في الوثيقة أولاً ثم ينعكس على كل قناة تخاطب العميل.
أما التحديث فيحتاج عادة منتظمة لا مشروعاً جديداً: مراجعة شهرية قصيرة للأسئلة التي عجز عنها الروبوت، وللإجابات التي رفضها العميل فطلب موظفاً بعدها مباشرة.
وهنا التحفّظ الذي أقوله لكل عميل قبل التوقيع: إن كانت سياساتك غير مستقرة — أسعار تتغير أسبوعياً، عروض ترويجية بلا توثيق، قرارات تُتخذ في مجموعة واتساب داخلية — فالروبوت سيضاعف الفوضى بدل أن يخفيها، وسيفعل ذلك أمام عملائك مباشرة. رتّب البيت أولاً، ثم تحدث عن الأتمتة.
ما أطلبه قبل كتابة سطر برمجي واحد
أطلب من العميل ملفاً واحداً فيه أكثر ثلاثين سؤالاً تكراراً وجوابها النهائي المعتمد. من يسلّمني هذا الملف خلال أسبوع، فالإشارة جيدة. ومن يتأخر شهراً، المشكلة ليست في جدوله بل في أن الإجابات نفسها غير متفق عليها داخلياً — وهذه مشكلة إدارية لا يحلّها أي نموذج لغوي مهما كان.
لماذا تتعثّر الروبوتات في اللهجة الخليجية؟
اللهجة الخليجية تكسر الروبوتات لأسباب لغوية محددة لا علاقة لها بذكاء النموذج. العميل يكتب «وين طلبي؟» لا «أين طلبي؟»، وقد يكتبها بحروف لاتينية «wain talabi». يخلط الأرقام العربية والهندية، ويكتب اسمه بصيغ متعددة. وأي روبوت يُختبر على العربية الفصحى وحدها سيبدو ممتازاً في العرض التقديمي وضعيفاً في يومه الأول.
- الكتابة بحروف لاتينية: «meta yousal» و«مته يوصل» سؤال واحد. اجمع أمثلة حقيقية من محادثاتك واختبر عليها قبل الإطلاق.
- الأرقام: رقم الطلب قد يصل بصيغة ٢٤٥ أو 245 أو مقطّعاً بمسافات. وحّد القراءة قبل أن تبحث في النظام.
- الأسماء: «محمد» و«محمّد» و«Mohammed» شخص واحد في ذهن العميل، لا في قاعدة بياناتك.
- الاختصارات المحلية: أسماء الفروع والمناطق كما ينطقها الناس، لا كما هي مسجلة في السجل التجاري.
- حد التحويل: عرّف متى ينسحب الروبوت — شكوى، طلب استرداد، تكرار السؤال مرتين، أو أي ذكر لكلمة «موظف».
قاعدتي البسيطة: التحويل إلى إنسان ليس فشلاً، بل ميزة تُقاس وتُحتفى بها. اجعل الروبوت يمرّر نص المحادثة كاملاً للموظف حتى لا يعيد العميل قصته من البداية. لا شيء يستفز عميلاً خليجياً أكثر من أن يشرح مشكلته مرتين في دقيقتين.
ماذا يعني عملياً ربط الروبوت بواتساب ونظام إدارة العملاء؟
الربط بواتساب وبنظام إدارة العملاء يعني أن الروبوت يقرأ بيانات العميل الحقيقية ويكتب فيها، لا أن يتحدث في فراغ. عملياً: يتعرّف على رقم المرسل، يجلب آخر طلب من نظامك، يخبره بحالته، ثم يسجّل المحادثة في ملف العميل. القيمة كلها في هذا الجسر، وهو أصعب جزء تقنياً وأكثره حساسية أمنياً.
وواتساب تحديداً يفرض قواعد لا يذكرها معظم من يبيعك روبوتاً: هناك نافذة زمنية للرد الحر بعد رسالة العميل، وبعدها لا تستطيع مراسلته إلا برسائل قوالب معتمدة مسبقاً. هذا يغيّر تصميم التجربة كلها، لا نص الرد فقط. اقرأ الشروط من مصدرها في وثائق واجهة واتساب السحابية للأعمال قبل أن تبني خطة متابعة تعتمد على رسائل مبادِرة.
وهناك تفصيلة يتجاهلها كثيرون: هوية المتحدث. رقم الواتساب ليس دائماً الرقم المسجّل في نظامك؛ الزوجة تراسل عن حساب زوجها، والموظف عن حساب الشركة. قبل أن تسمح للروبوت بعرض تفاصيل طلب، قرر كيف تتحقق من أن المتحدث صاحب الطلب فعلاً، ولو بسؤال تأكيدي بسيط.
من ناحية الأنظمة، القراءة أسهل من الكتابة بكثير. أن يعرض الروبوت حالة طلب أمر منخفض المخاطر؛ أما أن يعدّل عنوان شحن أو يلغي حجزاً فهذا وكيل ينفّذ، ويحتاج صلاحيات مقيدة وسجل تدقيق ومسار تراجع. وإن لم يوفّر نظامك واجهة برمجية نظيفة، فالمشروع الحقيقي هو تطوير البرمجيات المخصصة التي تفتح تلك الواجهة، والروبوت مجرد طبقة فوقها. الأمر نفسه ينطبق على بيانات العملاء: من دون crm-مخصص-الكويت/">تطوير أنظمة CRM مخصصة تحفظ سجلاً موحّداً لكل عميل، لن يجد الروبوت ما يقرأه أساساً. ولهذا ينتهي بنا الأمر غالباً إلى تطوير تطبيقات الويب المخصصة تجمع الطلبات والمحادثات في مكان واحد.
اختبار أجريه دائماً قبل الإطلاق
أفصل الاتصال بالنظام الخلفي عمداً وأرى ماذا يقول الروبوت. الروبوت السيئ يخترع حالة طلب. والروبوت المقبول يعتذر ويحوّل إلى موظف. هذا الاختبار يكشف في دقيقتين ما إذا كان البناء يميّز بين «لا أعرف» و«أظن»، وهو الفارق الذي يحدد إن كنت ستضعه أمام عملائك أم لا.
ماذا تفعل حين يخطئ الروبوت أمام عميل؟
الروبوت سيخطئ، والسؤال متى لا هل، فخطط له كما تخطط لأي عطل تشغيلي. تحتاج ثلاثة أشياء جاهزة قبل الإطلاق: سجل كامل لكل محادثة يمكن استرجاعه، ومفتاح إيقاف يعطّل الروبوت فوراً دون نشر تحديث برمجي، وسياسة معلنة تخبر العميل أنه يحادث نظاماً آلياً وكيف يصل إلى موظف بشري.
- الإفصاح: أخبر العميل من الرسالة الأولى أنه يتحدث إلى مساعد آلي. الإخفاء يكسر الثقة حين ينكشف، وينكشف دائماً.
- حدود البيانات: قرر ما الذي يُسمح للروبوت برؤيته. رقم الطلب وحالته نعم؛ بيانات الدفع الكاملة لا.
- الاحتفاظ: حدد مدة تخزين المحادثات ومن يطّلع عليها، واكتبها في سياسة الخصوصية قبل أول رسالة تُرسل.
- التصعيد: مسار واضح إلى موظف، وزمن استجابة معلن، وتنبيه داخلي حين يفشل الروبوت مرتين مع العميل نفسه.
والأهم: من يملك مفتاح الإيقاف؟ اكتب اسمه ورقمه في مكان يراه الجميع.
ولا تُهمل الجانب القانوني المحلي. حين يعِد الروبوت بشيء نيابة عنك — سعر، موعد تسليم، استثناء من سياسة — فالعميل يقرأه التزاماً من الشركة لا رأياً من برنامج. هذا وحده سبب كافٍ لتقييد ما يستطيع الروبوت قوله عن الأسعار والاستثناءات، وترك تلك المواضيع للبشر.
القرار الذي أمامك الآن
القرار ليس «هل أبني روبوت محادثة بالذكاء الاصطناعي» بل «ما الشيء الواحد الذي أريد أتمتته أولاً». اختر سؤالاً واحداً يتكرر كل يوم، اكتب جوابه النهائي واعتمده، ثم ابنِ عليه وحده. النطاق الضيق الذي يعمل بإتقان يهزم مشروعاً شاملاً يُطلق بعد ستة أشهر ولا يثق به أحد داخلياً.
ابدأ أسبوعك بجمع مئة محادثة حقيقية وتصنيفها. إن خرجت منها بثلاثين سؤالاً وجواباً معتمداً، فأنت جاهز لطلب عرض سعر جادّ؛ وإن لم تخرج، فأنت على وشك شراء واجهة أنيقة لفوضى قائمة. ولمعرفة الترتيب المالي للبناء المحيط بالروبوت — التطبيق أو نظام إدارة العملاء الذي سيقرأ منه — راجع صفحة الأسعار واطلب تقديراً على نطاقك أنت، لا على نطاق عام.