كيف أضفنا مساعدًا ذكيًا إلى منصة SaaS — دون أن نُعطبها

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

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

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

الوضع: مشكلتان ترتديان زيًّا واحدًا

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

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

الزيّ نفسه، ومشكلتان. وقد كانتا تشدّان في اتجاهين متعاكسين. بوت الدعم يريد أن يصرف الأسئلة وينزوي جانبًا. أما مساعد التفعيل فيريد أن يبدأ المحادثات ويدفع الناس نحو أشياء لم يسألوا عنها. لو بنينا «شات بوت ذكي» دون الفصل بين هذين، لكنّا بنينا شيئًا يؤدّي المهمتين بشكل رديء.

تضييق النطاق إلى شيء نستطيع إنهاءه

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

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

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

النموذج الأولي الأول الذي بنيناه — وحذفناه

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

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

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

ما بنيناه فعلًا

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

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

الارتكاز قبل الذكاء

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

تسليم رشيق

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

واعٍ بمن يسأل

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

1. 1
   تنظيف قاعدة المعرفة وهيكلتها

   دقّقنا كل مستند مساعدة، وأزلنا المتقادم منها، ووسمنا الباقي حسب الباقة والميزة. كان هذا الأسبوع الأول، وكان الأهم.
2. 2
   بناء طبقة الاسترجاع

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

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

   بنينا مسار «لست متأكدًا — إليك شخصًا» كميزة من الدرجة الأولى، مع تسليم سياق المحادثة كاملًا إلى فريق الدعم.
5. 5
   الإطلاق لـ10% من المستخدمين خلف مفتاح تبديل

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

النتائج — وتلك التي فاجأتنا

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

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

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

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

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

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

أسئلة شائعة