المحتوى عن 'قاعدة المعرفة'.



مزيد من الخيارات

  • ابحث بالكلمات المفتاحية

    أضف وسومًا وافصل بينها بفواصل ","
  • ابحث باسم الكاتب

نوع المُحتوى


التصنيفات

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

التصنيفات

  • PHP
    • Laravel
    • ووردبريس
  • جافاسكريبت
    • Node.js
    • jQuery
    • AngularJS
    • Cordova
    • React
    • Vue.js
  • HTML
    • HTML5
  • CSS
  • SQL
  • لغة C#‎
  • لغة C++‎
  • لغة C
  • بايثون
    • Flask
    • Django
  • لغة روبي
    • Sass
    • إطار عمل Bootstrap
    • إطار العمل Ruby on Rails
  • لغة Go
  • لغة جافا
  • لغة Kotlin
  • برمجة أندرويد
  • لغة Swift
  • لغة R
  • لغة TypeScript
  • ‎.NET
    • ASP.NET
  • الذكاء الاصطناعي
  • صناعة الألعاب
    • Unity3D
    • منصة Xamarin
  • سير العمل
    • Git
  • سهولة الوصول
  • مقالات برمجة عامة

التصنيفات

  • تجربة المستخدم
  • الرسوميات
    • إنكسكيب
    • أدوبي إليستريتور
    • كوريل درو
  • التصميم الجرافيكي
    • أدوبي فوتوشوب
    • أدوبي إن ديزاين
    • جيمب
  • التصميم ثلاثي الأبعاد
    • 3Ds Max
    • Blender
  • نصائح وإرشادات
  • مقالات تصميم عامة

التصنيفات

  • خوادم
    • الويب HTTP
    • قواعد البيانات
    • البريد الإلكتروني
    • DNS
    • Samba
  • الحوسبة السّحابية
    • Docker
  • إدارة الإعدادات والنّشر
    • Chef
    • Puppet
    • Ansible
  • لينكس
  • FreeBSD
  • حماية
    • الجدران النارية
    • VPN
    • SSH
  • مقالات DevOps عامة

التصنيفات

  • التسويق بالأداء
    • أدوات تحليل الزوار
  • تهيئة محركات البحث SEO
  • الشبكات الاجتماعية
  • التسويق بالبريد الالكتروني
  • التسويق الضمني
  • التسويق بالرسائل النصية القصيرة
  • استسراع النمو
  • المبيعات
  • تجارب ونصائح
  • مبادئ علم التسويق

التصنيفات

  • إدارة مالية
  • الإنتاجية
  • تجارب
  • مشاريع جانبية
  • التعامل مع العملاء
  • الحفاظ على الصحة
  • التسويق الذاتي
  • مقالات عمل حر عامة

التصنيفات

  • الإنتاجية وسير العمل
    • مايكروسوفت أوفيس
    • ليبر أوفيس
    • جوجل درايف
    • شيربوينت
    • Evernote
    • Trello
  • تطبيقات الويب
    • ووردبريس
    • ماجنتو
  • أندرويد
  • iOS
  • macOS
  • ويندوز

التصنيفات

  • شهادات سيسكو
    • CCNA
  • شهادات مايكروسوفت
  • شهادات Amazon Web Services
  • شهادات ريدهات
    • RHCSA
  • شهادات CompTIA
  • مقالات عامة

أسئلة وأجوبة

  • الأقسام
    • أسئلة ريادة الأعمال
    • أسئلة العمل الحر
    • أسئلة التسويق والمبيعات
    • أسئلة البرمجة
    • أسئلة التصميم
    • أسئلة DevOps
    • أسئلة البرامج والتطبيقات
    • أسئلة الشهادات المتخصصة

التصنيفات

  • ريادة الأعمال
  • العمل الحر
  • التسويق والمبيعات
  • البرمجة
  • التصميم
  • DevOps

تمّ العثور على 2 نتائج

  1. تبدأ عملية تطوير البرنامج في اللحظة التي يصل فيها إلى يد العملاء، حيث يمكنك - بدءًا من تلك اللحظة - أن تتعرف على مواطن الخلل في المنتج، إضافة إلى أن إطلاق المنتج في وقت مبكر يساعد بشكل أكبر على تحسينه، إذ يمكن إطلاق المنتج حتى قبل اكتماله ما دامت هناك رغبة مستمرة في تطويره وتحسينه. بناءً على ما سبق، فإن من المفترض أن تكون عملية إطلاق محتوى الدعم الفني مشابهة في تفاصيلها لعملية تطوير البرامج. فبعد أن يتعاون عدد من الأشخاص في كتابة هذا المحتوى ثم إطلاقه إلى العالم، يمكن للعملاء حينئذٍ أن يبدوا آرائهم فيما إذا كان المحتوى داعمًا لهم أم لا، وبالاعتماد على هذه الآراء، يمكن تحسين المحتوى وتجويده مرة بعد أخرى. ومع ذلك، فمن النادر أن ترى أحدًا يطبق المبادئ المتبعة في تطوير المنتج على عملية كتابة المحتوى المساعد (مُحتوى الدّعم الفنّي)، على الرغم من عدم كونه محكومًا بموعد تسليم أو مقيّدًا بالقيود التي تفرضها عملية الطباعة. وسواء أكنا واعين أم لا، فإننا نرغب دائمًا في أن يكون المحتوى ممتازًا منذ البداية. ويمكن أن نلخّص في النقاط التالية ما لاحظناه من خلال ما قمنا بكتابته بأنفسنا ومن خلال إنشاء تطبيقات لإنشاء المحتوى: لا يكتب الناس محتوى الدعم الفني إلا عندما يقترب موعد اكتمال المنتج. بعد ذلك يحتفظون بالمحتوى المكتوب ليحاولوا نشره دفعة واحدة. هذا يعني أن الحصول على تغذية راجعة من أشخاص حقيقيين يتطلب وقتًا أطول. وبعد نشر المحتوى، تصبح التعديلات والتحديثات عليه نادرة جدًّا. ولكن كيف يمكن الخروج من هذه الدائرة مع الأخذ بنظر الاعتبار طبيعتنا الباحثة عن الكمال، والتأخير الذي لا مفرّ منه؟ إن كان الكمال عدوًا لإنجاز الأعمال (إن أجزنا لأنفسنا أن نقتبس من فولتير مع بعض التصرف) فإنّ أول ما نحتاج إلى تعريفه هو معنى (الإنجاز)، فكيف تعرف أن العمل قد أصبح منجزًا؟ في الماضي، كانت البرامج توزع في أغلفة كرتونية وكان المحتوى المساعد يقدّم داخل الغلاف الكرتوني أو على الأقراص الليزرية، وكان إجراء التعديلات على المحتوى بعد إطلاق المنتج أمرًا صعبًا، وكانت الأخطاء مكلفة للغاية. وهذا هو السبب الذي جعل البحث عن الكمال إحدى الصفات المميزة للكاتب أو المحرّر، حيث يكون قادرًا بالفطرة على التقاط الأخطاء الطباعية وغيرها من الأخطاء في الصياغة وأسلوب الكتابة. ولكن لا وجود في الواقع لأي نص كامل على الإطلاق، فعندما يقرر الكاتب أنّه قد انتهى من كتابة النص، فهذا يعني وبكل بساطة أنّه قد أعلن استعداده التام للاستماع إلى انتقادات الناس حول مضمون النص الذي قام بكتابته. إنشاء محتوى مساعد ممتاز بمثابة تحدٍّ في التصميم يتم بناء البرمجيات وتصميمها من قبل فرق تضم أشخاصًا يتمتعون بمهارات مختلفة ومتنوعة، وخلال عملية التصميم، يتلقى أعضاء الفريق التغذية الراجعة من بعضهم البعض، متوخين في ذلك نجاح المنتج وانتشاره بعد طرحه للجمهور. (دليل المستخدم لنظام ماكنتوش، 1984) ولو قارنا هذه العملية بالكتابة، فإن أول ما يتبادر إلى الذهن عند سماع كلمة "كاتب" هو أنّه عمل يقوم به شخص منعزل عن الناس في غرفة باردة. يمكن للعمل بشكل منفرد أن يزيد من ارتباط صانع المحتوى بنتائج عمله، ولا أَدَلّ على ذلك من حرص الكاتب في أغلب الأحيان على أن يختم ما يكتبه بذكر اسمه الكامل. كل ذلك يساهم وبشكل كبير في زيادة مخاوف الكاتب وشعوره بعدم الرضا حيال ما يكتب. وإن كنت تشعر بالخوف أو القلق أثناء كتابة محتوى الدعم الفني، فإليك بعض الطرق التي يمكن لها أن تساعدك على تجاوز هذه المخاوف: ابدأ التخطيط في وقت مبكر: من المُرجّح أن يساعد المنتج الجديد أو الخاصية الجديدة في حلّ مشاكل حقيقية لمستخدمي المنتج، لذا ابدأ بكتابة مقالات حول تلك المشاكل. تحدث مع عملائك: حاول أن تبني أفكارًا وتصورات حول الأجوبة التي يبحث عنها عملاؤك والتي يحتاجون إليها بالفعل، وركّز عليها. أجب عن شيء واحد في كل مرة: عندما يزور الناس مركز الدعم الخاص بك بحثًا عن الأجوبة، فإنّهم يبحثون عن شيء محدّد، ولا يمكن لمقالة واحدة أن تجيب عن جميع الأسئلة المحتملة حول موضوع معين. اطلب الدعم والمراجعة من زملائك: تعاون مع أعضاء فريقك كما تتعاونون في حل أي مشكلة في التصميم. فوق كل ما سبق ذكره، عليك أن تنسى تمامًا فكرة أن المحتوى الذي ستكتبه سيكون مثاليًا، أو أنّه يجب أن يصل إلى الكمال. ما الذي سيحدث بعد إطلاق المنتج؟ ستبدأ بتلقي التغذية الراجعة من أشخاص حقيقيين بعد إطلاق المنتج، وسيشعرك ذلك ببعض الإرباك والحيرة، ولكن باستخدام بعض تطبيقات "مركز المعرفة" knowledge base مثل تطبيق Educate يمكنك تجاوز هذا الأمر، حيث يتيح لك التطبيق التحكم بالتغذية الراجعة التي ترد إليك والاستفادة منها كذلك، ولا يقتصر عمل هذا التطبيق على تقديم معلومات إحصائية وحسب، بل يتجاوز ذلك إلى ربط كل مقال بمحادثة حقيقية، الأمر الذي يعني: أنك قادر على التواصل مع قرائك وحل مشاكلهم إن لم يكن المحتوى الذي تقدّمه إليهم كافيًا لحلّ المشكلة، وعليك في هذه الحالة أن تسأل القراء عن أجزاء المقالة التي يرون أنّها غير مفيدة بالنسبة إليهم. أنك قادر على تتبع المحادثات التي تنشأ مع كل مقالة، لتطّلع على طبيعة الأسئلة التي يتم طرحها ضمن المحادثة. أنّك قادر على مشاهدة المقالات التي يبحث الناس عنها والتي لم تقم بإضافتها إلى قاعدة المعرفة، وهذا سيمكنك من سدّ الفراغات فيها. يزوّدك كل ما سبق بتغذية راجعة تمتاز بكونها حقيقية ومخصصة ومفيدة وقابل للتوسع، وبعد ذلك يصبح من السهل الاستفادة من هذه التغذية الراجعة لتحسين المحتوى الذي تقدّمه إلى جمهورك. ترجمة - وبتصرّف - للمقال What content can learn from product development لصاحبته Elizabeth McGuane. حقوق الصورة البارزة محفوظة لـ Freepik
  2. أفضل ما يمكنك فعله في بعض الأحيان -فيما يتعلّق بخدمة الدّعم- أن تتنحّى عن طريق عميلك. قاعدة المعرفة Knowledge base يمكنها أن تكون صديق عميلك الصّدوق فيما يتعلّق بالخدمة الذاتيّة. لكن بالرّغم من ذلك تقول Kathy Sierra في كتابها Making Users Awesome غالبًا ما تفشل الشّركات في خدمات ما بعد البيع، مع أنّ محتوى المُساعدة في معظم الأحيان يكون أوّل الأشياء التي يُقيِّم العميل المنتج من خلالها. سنقدّم لك في هذا المقال ما تحتاجه لتُعيد اللمسة الجماليّة إلى توثيقك documentation لكن ضع في الحسبان أنّ ترتيب وتنظيم محتوى المساعدة لا يمكن أن يُحقّقا بلمسةٍ سحريّة، يحتاجُ ذلك لمجهودٍ واعٍ. يجب أن تكون معلومات المساعدة التي تقدّمها مفيدة، جذّابة، وواضحةً بشكلٍ لا يدفع إلى طرح أية تساؤلات. ويجب أن تكون واعيًا بكيفيّة وسبب بحث العميل عن المساعدة في المقام الأول. وإليك عدّة نصائح بهذا الشّأن: لا تضع أي افتراضات مسبقة بمعرفة العميليتصفّح عملاؤك محتوى المساعدة ليحلّوا المشاكل التي تواجههم، هدفُك الأساسي المهم هو أن تمحو أي احتمال لعدم الفهم. انسَ مبدأ "اللّبيبُ بالإشارةِ يفهمُ". يجب أن تكتب محتوى الدّعم على افتراض أنّ المستهلك مبتدئٌ فيما يتعلّق بمنتجك. تجنّب المصطلحات المتقدّمة واللغة الاصطلاحيّة بشكلٍ عام. واحذر من ذكر التعليمات فقط بشكلٍ عابر؛ لأنّ العملاء غالبًا ما تواجههم العوائق بهذا الشّأن، من الأفضل أن تفترض أنّ العملاء يحتاجون الإرشاد في كلّ خطوة. مثلًا، إذا كان عميلك يبحث عن طريقة نقل موقعه إلى استضافةٍ أخرى، أيّ العبارتين التّاليتين أقل عُرضة للخطأ: قبل المتابعة، تأكّد أنّك قمت بتغيير عنوان IP الخاص بك.قبل المتابعة، تأكّد أنّك قمت بتغيير عنوان IP الخاص بك عن طريق الذهاب إلى: إعداداتي > إدارة أسماء النّطاقات > عنوان IP.الطريقة الثانية أفضل، أليس كذلك؟ لا تجعل العملاء يزيدون الأمور سوءًا عن طريق افتراض أنّهم لا يحتاجون إلا إلى تعليماتٍ بسيطة. من الأفضل أن تُسرف في شرح الخطوات بالتفصيل. اجعل المحتوى سهل التصفحلا تهوّل الأمر على العميل بصفحةٍ مليئةٍ بالكلام إذا واجه العملاء صعوبةً في الوصول لحلول مشاكلهم عن طريق قاعدة المعرفة، التواصل مع فريق الدّعم سيكون الخطوة التالية لهم، وهذا يُعَدُّ فشلًا في تقديم محتوى دعمٍ جيّد وفي التواصل مع المستهلك. الُمصمّم Rafal Tomal يُظهر أدناه كيف يمكن استخدام العناوين الفرعية والمسافات المناسبة بين السّطور للحصول على مستندٍ واضحٍ يختصرُ الطريق على العميل للوصول إلى المعلومات التي يريدها بسهولة. استخدم فقاعات الحوار (callouts)، النقاط الفرعيّة، والصور لتسليط الضوء على المعلومات الهامّة وجعل كافّة التعليمات واضحة بمجرّد الاطّلاع على الصفحة. إليك مثالًا يوظّف معظم هذه العناصر: صمّم محتوى الدّعم خصيصًا لأولئك الذين تهدف إلى مساعدتهم: العملاء الذين تختلط عليهم الأمور ويريدون التقاط المعلومة التي تساعدهم لحل مشكلتهم. اجعل المحتوى سهل القراءةمن أفضل المصادر على الويب لتحسين طريقة كتابتك لمحتوى الدعم هو خدمة Voice and Tone التي يقدّمها موقع MailChimp. وإليك بعض الاقتراحات الأخرى في هذا المجال: الكتابة ليست مختلفةً تمامًا عن الحديث، لكنهما ليسا متطابقين أيضًا. اكتب كما لو أنّك تتكلم مع صديقٍ لكن رتّب أفكارك لتكون متّسقةً أكثر.خذ هدف القارئ بعين الاعتبار: هل هو الفضول لمعرفة المزيد عن منتجك وكيفية الاستفادة منه؟ أم إصلاح خلل أو مشكلة؟ اجعل أسلوب الكتابة متماشيًا ومتناسبًا هدف العميل.لا بأس بقليلٍ من روح الدّعابة في المقالات التي لا تتعلّق بإصلاح الأعطال والمشاكل، لكن لا تُكثر منها لئلا ينزعج العميل.تجنّب اللهجة العاميّة أو أن تتخطى الحدود. رأيتُ كتّابًا وقعوا في مشاكل بسبب استخدام كلمات فهمها بعض القراء أنّها إهانة.كُن مباشرًا. لا شيء يهبِط بمستوى محتوى الدّعم الذي تقدّمه أكثر من تقديم معلوماتك في كلماتٍ أكثر من اللازم.يجب أن يكون أسلوب كتابة المحتوى جذّابًا ليستمر العملاء في قراءته. لكن لا تدع المعلومات المهمّة والحلول تتوه في الكلام المنمّق أو النِكات الخارجة عن صلب الموضوع. رتب المحتوى ترتيبا منطقياالوثائق الجيّدة تصبح ممتازة عندما تُصمّم متوافقةً مع تدفّق أفكار القارئ. مهمٌّ جدًّا أن يكون ترتيب الأفكار والتعليمات منطقيًّا، إلا إذا كنت تريد العملاء أن يتخبطوا كسمكةٍ أخرجت خارج الماء ثم طُلب منها القيام بعملية مُعقّدة. وإليك بعض المبادئ بهذا الصدد: 1- التسلسل الزمنييجب أن ترتب خطوات حلّ كل مشكلة بحسب التّسلسل الزّمني. أوّل ما يجب على العميل فعله يجب أن يكون في الخطوة الأولى! 2- الترتيب بحسب الصعوبةإذا كان محتوى الدّعم يحتوي على العديد من الخطوات التي لا يهمّ فيها التّرتيب، اجعل عملاءَك يفعلون الأشياء الأسهل أولًا. إيجادهم لعائق في البداية يقلّل احتماليّة إكمالهم لقراءة محتوى المساعدة أو حتّى اتّباع نصائحك. لذا ابدأ بالأشياء التّي من المرجّح أنّهم لن يعجزوا عن فعلها. 3- تنبه لعدم قطع حبل أفكار العميلندرك جميعًا أنّك إذا وضعت رابطًا لفيديو في منتصف فقرات المحتوى فإنّك ستزيد من احتماليّة تشتّت العميل. صمّم المحتوى بطريقةٍ لا تقطع حبل أفكار العميل ولا تشتّته. تجنب مقاطعة خطوات حلّ المشكلة في المنتصف. البنية أعلاه ممتازة لمقالات "النظرة العامّة". على غرار بناء رسالة بريد إلكتروني ممتازة في مجال الدّعم الفني، ضعِ الروابط في مكانٍ استراتيجيّ بحيث ينقر العملاء عليها فقط عندما يكونون جاهزين لذلك. عندما يكون المقال طويلًا، صمّم جدولًا سريعًا للمحتويات في البداية؛ يتطلّب هذا منك مجهودًا ضئيلًا لكنّه يساعد العميل جدًّا. حتّى للمقالات متوسّطة الطول، العملاء سيقدّرون أنّهم يستطيعون الانتقال للقسم الذي يريدونه من المقال بسهولة. ماذا عن ختم محتوى المساعدة؟ ضع نفسك في مكان العميل وفكّر في الحوار الذي قد يدور بينه وبين نفسه:"حسنًا. أنا جاهزٌ لعمل هذا. لكن ماذا عن......" إذا كنت تستطيع التفكير في أيّ أسئلة مرتبطة بالمشكلة يمكن أن تدور في ذهن العميل بعد قراءته للمقال، أضِف الأجوبة عليها في صلب المحتوى. تستطيع أيضًا إنهاء المحتوى بأكثر الأسئلة شيوعًا حول ذلك الموضوع. مع البناء الجيّد للمحتوى، سيكون لديك المزيد من العملاء الذين يقرؤون المحتوى للنّهاية وستقلّل من احتماليّة إصابتهم بالإحباط، الاستسلام، ومن ثمّ التّواصل مع الدّعم الفنّي في نهاية المطاف. استعمل العناوين البسيطة والمباشرة دائمايجب أن تكون العناوين مباشرةً قدر الاستطاعة. لا داعي للعناوين الأدبيّة، اكبح جماح إبداعِك في سبيل الوضوح، عندما تحتار في اختيار العنوان المناسب، فكّر ما الذي يمكن أن يبحث عنه العميل؟ تذكّر أن الناس يبحثون بواسطة عبارات مركّبة بطريقةٍ عجيبة: " كيف تنقل مدوّنتك على ووردبريس إلى استضافة أخرى" تتحوّل إلى: "نقل مدوّنة ووردبريس". استخدم العبارات شائعة الاستخدام في عناوينِك. عندما يبحث العميل عن كلمة "forwarding" مثلًا عبر موقع Help scout يظهر له العديد من الاقتراحات من قاعدة المعرفة: عناوين عاديّة، لكنّها واضحة. تمامًا كما ينبغي أن تكون. اعتمِد على الصيغ التّالية في كتابة العناوين: * كيف ( )* استعمال ( )* إعداد ( )أو استخدم عباراتٍ من محدّدة، مثلًا: "رفع الفيديو الأول" أو " تثبيت المكّون الإضافي" ...الخ استخدم الصور لتوفير الوقت والجهد"أرِني، لا تخبِرني" هي الطريقة التي تعتمد عليها قاعدة المعرفة الجيّدة. مثالٌ آخر من موقع Help Scout، افرِض أنّ العميل يريد معرفة المزيد حول قوالب سير العمل. هذا ما سيجده: العناوين الفرعيّة والصور تكفي. لماذا إضاعة الوقت بالاسهاب في الشّرح عندما يمكنك أن "تُري" العميل بالضبط ما الذي يجب أن يفعله؟! وفيما يتعلّق بهذا الأمر، إليك بعض الأدوات المفيدة لالتقاط الشاشة: Ember : يعمل على أجهزة ماك فقط، وهو يملك أداةَ رسمٍ ذكيّة تستطيع استشعار الدوائر، الأسهم، والمستطيلات والتقاطها فقط من الشّاشة.Skitch تطبيق مقدّم من Evernote يسمح لك بتذييل صورك بالرسوم التوضيحيّة والأشكال.SnagIt تطبيق لإضافة الأشكال التوضيحيّة على الصّور. سعره معقول، وله الكثير من المزايا، متوفّر لأجهزة ماك واجهزة الكمبيوتر الشخصي الأخرى.أضِف العناصر الرسوميّة مثل الأسهم لتسليط الضّوء على المناطق المهمّة في الأماكن المزدحمة في المحتوى. وضع الصور التوضيحيّة مباشرةً بعد التعليمات، لأنّ العملاء سيبحثون بالتأكيد عن ما أشرت إليه في المحتوى. إذا قلت "توجّه إلى إعداداتي" أتبِع هذا بصورةٍ تسلّط الضوء على المكان الذي يجب عليهم أن يتوجّهوا إليه وينقروا عليه بالضبط. كيف تستعمل محتوى المساعدة لتطوير خدماتكستكتب وثائقَ حول التغذية الراجعة التي ستحصل عليها من العملاء، لكنّ الكثير من الشركات تنسى أنّ العمليّة عبارة عن دائرة متكاملة- التغذية الرّاجعة التي تحصل عليها يمكن أن يكون مصدرًا لنظرةٍ أعمق حول منتجك وعمليّة التّسويق. في مقالةٍ له Garret Dimon حول التّحسينات التي أدخلها إلى تطبيق Sifter وحول كيف ساعدته المعلومات التي يحصل عليها من استخدام العملاء لمحتوى المساعدة (الموضحّة في التقرير أدناه) في معرفة أكثر المشاكل التي تواجه المستخدمين، يقول Garret Dimon: تذكر أيضًا أن محتوى المساعدة يمكن أن يخدمك في معرفة منظور العملاء. إذا كان مقالك حول التّسعير يستقبل العديد من الزّيارات، اكتشِف السّبب! – هل التّسعير غير واضحٍ للعملاء في الموقع أمّ ماذا؟ اتّبع التّوجيهات والإرشادات المذكورة في هذا المقال وسوف تضعُك على الطّريق الصّحيح لخلق محتوى مساعدةٍ فعّالٍ ومترابط وواضح، هذا الذي يعود بفائدةٍ كبيرةٍ عليك وعلى العميل على حدّ سواْء. ترجمة –وبتصرّف- للمقال: How to Write a Killer Knowledge Base Article لصاحبه: Gregory Ciotti. حقوق الصورة البارزة: Designed by Freepik.