مولّد مقالات مركز المساعدة: الأقسام السبعة التي تمنع بالفعل تكرار تذاكر الدعم

تصلك للتو تذكرة دعم. تقول:

“لقد اتبعت مقالة المساعدة. لكنها لم تنجح.”

تفتح المقالة. تبدو جديدة. وودودة. حتى أنها تحتوي على جملة افتتاحية لطيفة تبدو وكأن بشراً كتبها.

ومع ذلك، لا تزال تفشل في المهمة الوحيدة لمقالة المساعدة: إيصال المستخدم إلى خط النهاية دون تخمين.

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

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

ما الذي يجب أن يفعله مولد مقالات مركز المساعدة#

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

وثائق الدعم التي تقلل من تذاكر الدعم تبدأ بنجاح المهمة#

عبارة "مكتوب آلياً" غير ذات صلة.

السؤال الوحيد الذي يهم هو: هل يمكن للمستخدم إكمال المهمة بسرعة، بمفرده، دون فتح تذكرة؟

إذا كنت تريد قياس "التميز"، استخدم مقاييس ترتبط بالواقع:

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

أيضاً، العملاء يريدون ذلك. ذكرت Zendesk أن 91% من العملاء سيستخدمون قاعدة المعرفة إذا كانت تلبي احتياجاتهم. كلمة "إذا" هذه تقوم بالكثير من العمل.

لذا عندما تحكم على مولد، لا تسأل "هل يبدو بشرياً؟"
اسأل "هل يزيل الغموض؟"

الخدمة الذاتية للعملاء تتعطل عندما تكون المتطلبات الأساسية غامضة#

معظم المقالات المكتوبة آلياً تفشل قبل الخطوة 1.

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

يحتاج المولد إلى التعامل مع المتطلبات الأساسية كما يتعامل المهندس مع التبعيات:

• الأذونات والأدوار (غالباً ما تختلف مسارات المسؤول عن العضو)
• مستوى الخطة والاستحقاقات (لا تخمن هذا أبداً)
• أعلام الميزات وحالات النسخة التجريبية
• حالة البدء ("يجب أن يكون لديك X مُنشأ بالفعل")
• متطلبات البيانات (بيانات نموذجية، مفاتيح API، نطاق تم التحقق منه، إلخ)
• المنصة (اختلافات الويب مقابل الجوال مقابل سطح المكتب)

توجيهات أسلوب Microsoft بشأن الإجراءات واضحة حول كتابة تعليمات يمكن للناس اتباعها، وليس أجواء يمكن للناس الاستمتاع بها.

قاعدتي: المتطلبات الأساسية العامة أسوأ من عدم وجودها لأنها تخلق ثقة زائفة. "تأكد من أن لديك صلاحية الوصول" هي المعادل التوثيقي لقول "كن أطول قامة".

يجب أن يفرض المولد الجيد التحديد، بما في ذلك "أين تتحقق" من الوصول (صفحة الإعدادات، وحدة تحكم المسؤول، صفحة الفواتير). إذا لم يتمكن من التحقق، فيجب أن يخرج خطوة تحقق، وليس كذبة واثقة.

تشريح مقالة تم إنشاؤها بشكل رائع#

إليك الهيكل الذي سأطلبه في كل مرة. لا استثناءات.

الهدف#

ما يبدو عليه الأمر الجيد:

• يذكر الحالة النهائية بمصطلحات قابلة للاختبار: "سيكون لديك X مفعلاً ومرئياً في Y."
• يذكر من ينطبق عليه (الأدوار، الخطط، المنصات).
• يذكر متى لا يجب استخدامه. تؤكد Intercom على الوضوح بشأن الهدف ومطابقة نوع المقالة بالمهمة.

هدف سيء: "تعلم كيفية استخدام لوحات التحكم."
هدف جيد: "بحلول النهاية، ستنشئ لوحة تحكم وتشاركها مع فريقك."

المتطلبات الأساسية#

ما يبدو عليه الأمر الجيد:

• الدور، الخطة، أعلام الميزات
• المدخلات المطلوبة (مفتاح API، ملف CSV، نطاق)
• حالة البدء (ما يجب أن يكون موجوداً بالفعل)
• "أين تتحقق" من الوصول

إذا لم يتمكن المولد من تأكيد بوابة الخطة، فيجب أن يكتب:
"تحقق من أن خطتك تتضمن X: انتقل إلى الإعدادات ← الفواتير ← تفاصيل الخطة."

تلك الجملة توفر تذاكر دعم.

الخطوات#

يجب أن تكون الخطوات بمستوى المشغل: غير غامضة، قابلة للمسح الضوئي، ومرنة.

تضغط توجيهات كتابة واجهة المستخدم من Microsoft من أجل تعليمات محايدة للمدخلات وأفعال متسقة.

ما يبدو عليه الأمر الجيد:

• إجراء مرقم مع عناوين فرعية قائمة على المهام
• تبدأ كل خطوة بـ الموقع، ثم الإجراء
• تتضمن كل خطوة نقطة تحقق للنتيجة المتوقعة

نمط المثال (هذا هو الأهم):

1. في الإعدادات ← الإشعارات، حدد تنبيهات البريد الإلكتروني.
   النتيجة المتوقعة: تظهر تنبيهات البريد الإلكتروني كـ "تشغيل".

سطر "النتيجة المتوقعة" هذا ليس حشواً. إنه فحص ذاتي مدمج يمنع الفشل الصامت ويقلل من تذاكر "لقد فعلت ذلك ولكن لم يحدث شيء".

ملاحظات وحالات استثنائية#

الملاحظات موجودة لإيقاف التذاكر، وليس لاستعراض المعرفة.

ما يبدو عليه الأمر الجيد:

• اختلافات المنصة (ويب مقابل جوال)
• اختلافات الأدوار (أزرار خاصة بالمسؤول فقط)
• تباينات واجهة المستخدم حسب علم الميزة
• الحدود القصوى (حدود المعدل، أحجام الملفات القصوى)

اجعلها مختصرة. إذا كانت الملاحظة لا تمنع الارتباك أو الفشل، فاحذفها.

استكشاف الأخطاء وإصلاحها#

هذا هو المكان الذي تفشل فيه مسودات الذكاء الاصطناعي عادةً.

تتلخص توجيهات NN/g بشأن رسائل الخطأ في: اجعل الأخطاء مرئية وواضحة وبناءة. تنطبق هذه العقلية مباشرة على أقسام استكشاف الأخطاء وإصلاحها.

ما يبدو عليه الأمر الجيد:

• العرض ← السبب المحتمل ← الإصلاح ← كيفية التأكيد
• نص الخطأ الدقيق إن أمكن
• أفضل 3 أنماط فشل بناءً على التذاكر، السجلات، أو الماكرو (وليس الخيال)

مثال:

العرض: "ليس لديك إذن لتنفيذ هذا الإجراء."
السبب المحتمل: أنت عضو، ولست مسؤولاً.
الإصلاح: اطلب من المسؤول منح إذن "إدارة التكاملات" في الإعدادات ← الفريق ← الأدوار.
التأكيد: قم بتحديث الصفحة وتحقق من ظهور قائمة التكاملات.

هذا هو مستوى الدعم. أي شيء آخر هو مجرد تجاهل.

الأسئلة الشائعة#

يجب أن تقلل الأسئلة الشائعة من التفرع، لا أن تكون مكباً للبقايا.

تفصل Intercom الأسئلة الشائعة عن كيفية القيام بالأشياء واستكشاف الأخطاء وإصلاحها لسبب ما. وظائف مختلفة، أشكال مختلفة.

الأسئلة الشائعة الجيدة هي أسئلة عالية التكرار لا تتناسب بشكل جيد مع التدفق، مثل "هل يعمل هذا على الجوال؟" أو "هل يمكنني التراجع عن هذا؟"

مقياس من 60 ثانية لمراجعة مقالات المساعدة التي تم إنشاؤها#

إذا لم يتمكن فريقك من تقييم مسودة الذكاء الاصطناعي بسرعة، فلن تنشر أبداً بشكل متسق.

إليك مقياس استخدمته للحفاظ على المراجعات سريعة وصارمة:

سجل كل نقطة من 0 إلى 2. انشر فقط إذا كان المجموع ≥ 8/10.

1. وضوح النتيجة

• 0: هدف غامض
• 1: هدف موجود ولكنه غير قابل للاختبار
• 2: حالة نهائية محددة + حدود النطاق

1. اكتمال الشروط المسبقة

• 0: متطلبات أساسية مفقودة
• 1: جزئية (دور أو خطة أو حالة بدء)
• 2: دور + خطة + حالة بدء + مكان التحقق

1. جودة الخطوات

• 0: خطوات غامضة ("اذهب إلى"، "انقر على الشيء")
• 1: واضحة في الغالب، تفتقر إلى نقاط تحقق
• 2: موقع ← إجراء ← نتيجة متوقعة بشكل متسق

1. جودة الاسترداد

• 0: لا يوجد استكشاف أخطاء وإصلاحها
• 1: استكشاف أخطاء وإصلاحها عام
• 2: عرض ← سبب ← إصلاح ← تأكيد، مرتبط بإخفاقات حقيقية

1. إشارات الثقة

• 0: لا توجد مؤشرات حداثة
• 1: التاريخ فقط
• 2: "آخر تحقق" + ملاحظات النطاق (منصة/دور) + المجهولات المعروفة

ما يجب أن يستنتجه المولد وما يجب أن يرفض تخمينه#

يجب أن يستنتج مولد مقالات مركز المساعدة ما يمكنه من إشارات حقيقية:

• نية المستخدم وحدود المهمة
• عناصر واجهة المستخدم المستقرة
• الأذونات المطلوبة عند إمكانية ملاحظتها
• انتقالات الحالة ("بعد الحفظ، سترى X")

لكن يجب ألا يخمن:

• بوابة الخطة
• الآثار الأمنية
• الإجراءات التي لا رجعة فيها
• أي شيء لا يمكنه تأكيده في واقع المنتج

النمط المفضل لدي هنا هو ما أسميه كتلة المعروف-غير المعروف (known-unknowns block):

"إذا لم ترَ X، تحقق من Y. إذا كانت Y صحيحة ولم يظهر X، تواصل مع الدعم وأرفق لقطة الشاشة Z."

إنه أسلوب متواضع، لكنه مفيد. ويمنع المولد من الهلوسة.

واقع الإنتاج: الاتساق يتفوق على براعة الكتابة#

أنت لا تقوم بصيانة الوثائق، بل تقوم بصيانة خريطة حية لمنتج لا يتوقف عن التغير.

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

لذا اجعل القابلية للصيانة مطلباً أساسياً:

• افصل بين القصد الأساسي وتسميات واجهة المستخدم الهشة عندما تستطيع
• أضف سير عمل للتحديث: "آخر تحقق في YYYY-MM-DD"
• تتبع "مخاطر تغيير واجهة المستخدم" لكل مقالة (الصفحات عالية المخاطر تتم مراجعتها مع كل إصدار)

هذا هو أيضاً سبب بنائنا لـ Clevera لتبدأ من أصعب شيء يمكن تزييفه: سير العمل الحقيقي. تحول Clevera تسجيل الشاشة إلى مقالة خطوة بخطوة مع لقطات شاشة ذات صلة، ثم تتيح لك تحريرها في محرر يشبه Notion والتصدير إلى منصات مثل Help Scout أو Notion أو Confluence.

إذا كان منتجك يُطرح بسرعة، فإن حلقة "سجل مرة واحدة، ولد، حرر، صدر" تهم أكثر من النثر المثالي.

دعوة لاتخاذ إجراء (CTA) سياقية: إذا كنت تريد أن يخرج المولد هيكلاً متسقاً في كل مرة، ابدأ بـ سير عمل وثائق Clevera (/features/docs) واقرنه بـ نسخة فيديو تعليمي مطابقة في أعلى المقالة (/features/video-tutorials).

بوابات ضمان الجودة (QA) قبل النشر (حتى لا يقوم العملاء بضمان الجودة بدلاً منك)#

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

إليك البوابات التي سأفرضها:

البوابة 1: اختبار "التجربة الباردة"#

سلم المسودة لشخص لم يقم ببناء الميزة.

إذا لم يتمكنوا من إكمالها في محاولة واحدة، فالمقالة فاشلة. لا نقاش في ذلك.

البوابة 2: فحص تنسيق الإجراءات#

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

قائمة التحقق:

• خطوات مرقمة للمهام متعددة الخطوات
• إجراء واحد لكل خطوة
• أفعال متسقة
• لا يوجد تفرع خفي داخل الخطوات

البوابة 3: يجب أن يرتبط استكشاف الأخطاء وإصلاحها بالواقع#

يجب أن يرتبط كل عنصر لاستكشاف الأخطاء وإصلاحها بـ:

• فئة تصنيف تذاكر، أو
• ماكرو دعم، أو
• نمط سجل أخطاء

إذا لم تستطع ربطها بالواقع، فاحذفها.

البوابة 4: عناوين بحالة الجملة لسهولة المسح الضوئي#

يبدو هذا صغيراً، لكن الاتساق يقلل من العبء الإدراكي.

حتى دليل أسلوب Google يوصي صراحة بـ استخدام حالة الجملة للعناوين.

البوابة 5: ملصقات الحداثة والنطاق#

أضف:

• تاريخ التحديث
• المنصة
• الدور
• "آخر تحقق" (داخلي يكفي)

أنماط الفشل الشائعة التي أراها في محتوى المساعدة المكتوب آلياً#

إذا كنت تريد منع الألم، انتبه لهذه الأمور:

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

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

أين تتناسب Clevera عندما تهتم حقاً بالجودة#

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

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

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

أسئلة شائعة سريعة (النسخة غير الميتة)#

ما الأقسام التي يجب أن يتضمنها مولد مقالات مركز المساعدة في كل مرة؟\nالهدف، المتطلبات الأساسية، خطوات مرقمة مع النتائج المتوقعة، ملاحظات النطاق، استكشاف الأخطاء وإصلاحها (العرض ← السبب ← الإصلاح ← التأكيد)، وقسم أسئلة شائعة صغير للأسئلة المتفرعة عالية التكرار.

هل يمكن لمولد مقالات مركز المساعدة تقليل تذاكر الدعم حقاً؟\nنعم، إذا كان يحسن من تقليل الغموض ويتضمن استكشاف أخطاء حقيقياً. إذا كان يعيد صياغة النثر فقط، فقد يزيد من التذاكر من خلال خلق ثقة زائفة.

كيف تكتب متطلبات أساسية لأدوار وخطط مختلفة؟\nاذكر الدور والخطة في البداية، أضف فحوصات "أين تتحقق"، وافصل التدفق عندما تختلف شاشات المسؤول عن العضو. لا تدع المولد يخمن قيود الخطة أبداً.

ما هي أسرع طريقة لضمان الجودة لمقالات المساعدة التي يتم إنشاؤها بواسطة الذكاء الاصطناعي؟\nقم بتشغيل معايير التقييم لمدة 60 ثانية، ثم قم بإجراء اختبار "التجربة الباردة" مع شخص غير خبير. إذا ترددوا أو ارتجلوا، أعد الكتابة حتى تصبح الخطوات قابلة للتنفيذ.

هل يجب أن تتضمن المقالات التي يتم إنشاؤها بواسطة الذكاء الاصطناعي لقطات شاشة؟\nنعم، ولكن فقط مع تعليقات توضيحية وفقط حيث تزيل الصور الغموض. لقطات الشاشة لا تعوض عن الخطوات غير الواضحة.

التحدي الخاص بك#

اختر واحداً من أفضل 10 مسببات للتذاكر لديك وقم بتشغيله من خلال معايير التقييم أعلاه.

إذا سجلت المقالة أقل من 8/10، لا تعد كتابة المقدمة. أصلح المتطلبات الأساسية، أضف نقاط تحقق، واكتب استكشاف أخطاء حقيقياً مرتبطاً بإخفاقات حقيقية.

ثم راقب ما يحدث لحجم التذاكر خلال دورة الإصدار التالية.