بناء قاعدة معرفة لخدمة العملاء بالذكاء الاصطناعي : من الأسئلة المتكررة إلى إجابات معتمدة

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

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

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

1. اختر الأسئلة ومصادر الإجابة معًا

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

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

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

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

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

2. حوّل السؤال إلى سجل معرفي محدد النطاق

سؤالنا التطبيقي هو : ( كيف أطلب تغيير موعد زيارة الصيانة ؟ ) . في المثال ، حدد مسؤول العمليات الإجراء ( مواعيد الزيارات ، الإصدار الثالث ) مصدرًا ساريًا ، وألغى تعليمات سابقة كانت تصف التغيير بأنه فوري .

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

أ. افصل بيانات الإدارة عن النص الموجه للعميل

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

في سجلنا التعليمي ، المعرّف هو KB-021 ، والنطاق حجوزات الزيارات المنزلية عبر الحساب الإلكتروني . لا نمدد الإجابة تلقائيًا إلى عقود الشركات أو الحجوزات الهاتفية التي لم يغطها المصدر .

ب. اكتب إجابة تنتهي بخطوة واضحة

يمكن أن يكون النص الموجه للعميل في هذا المثال :

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

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

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

3. اجعل دور الذكاء الاصطناعي صياغة المعرفة وكشف نقصها

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

استخدم هذا الأمر بعد إرفاق الوثيقة المسموح بمشاركتها :

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

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

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

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

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

4. اربط المحتوى بالمساعد مع ضبط ما يستطيع الوصول إليه

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

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

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

لفهم الجانب التقني ، يمكن الرجوع إلى شرح الاسترجاع المعزز بالتوليد RAG . لكن وجود هذه التقنية لا يعفيك من التحقق من النسخة المسترجعة ومدى انطباقها على السؤال .

إذا لم يوجد مصدر ساري يغطي الحالة ، فليوضح المساعد ما ينقص ويحوّلها للمراجعة . وإذا كان السؤال ( هل قُبل طلبي ؟ ) ، فلا يستنتج القبول من وجود تعليمات تشرح كيفية تقديمه . المعرفة العامة وحالة المعاملة مصدران مختلفان .

5. اختبر الإجابة ثم حافظ على صلاحيتها

أ. اختبر حدود المقال لا السؤال المطابق لعنوانه فقط

جرّب السؤال بصياغة أخرى، وحالة استثنائية يغطيها المصدر ، وسؤالًا لا يغطيه ، وطلبًا يتطلب الاطلاع على سجل خاص . ضع النتيجة المتوقعة قبل الاختبار حتى لا تعتبر أي إجابة مقنعة نجاحًا .

في مثالنا ، سؤال ( أرسلت طلب التعديل ، هل أعتبره تم ؟ ) يجب أن يحافظ على شرط انتظار التأكيد . وسؤال ( هل التعديل مجاني ؟ ) لا يجيز اختراع إعفاء أو رسم ، لأن الوثيقة لا تجيب عنه .

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

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

ب. حدّث الإجابة عند تغير الإجراء

حدّد مسؤولًا يراجع المقال عند تعديل السياسة أو الواجهة أو ورود بلاغ عن خطأ ، مع موعد مراجعة دوري يناسب سرعة تغير الموضوع . الموعد الدوري لا يؤجل تصحيح معلومة ثبت خطؤها اليوم .

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

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

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

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

6. الخلاصة

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

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

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