برای ساخت پایگاه دانش پشتیبانی، جست‌وجوی راه‌حل موجود را بخشی از رسیدگی به تیکت کنید؛ اگر پاسخ کافی نیست، همان‌جا آن را اصلاح کنید یا راهنمای تازه‌ای با شرایط کاربرد روشن بسازید. خروجی مطلوب، متنی است که کارشناس بعدی بتواند با آن مسئله را تشخیص دهد، اقدام مناسب را انتخاب کند و نتیجه را بسنجد. انبارکردن متن مکالمه‌ها به‌تنهایی این قابلیت را نمی‌سازد.
این راهنما یک گردش پیشنهادی برای تیم‌های پشتیبانی فناوری اطلاعات و خدمات سازمانی ارائه می‌کند: از ثبت نشانه و تشخیص هم‌پوشانی تا بازبینی فنی، تعیین مخاطب و استفادهٔ دوباره. نقش‌ها و چک‌لیست‌های آن پیشنهاد اجرایی‌اند و باید با حساسیت خدمت و اختیار تیم شما سازگار شوند.
۱. واحد دانش را از پروندهٔ مشتری جدا کنید
تیکت، سابقهٔ یک درخواست مشخص است؛ مقالهٔ دانش باید پاسخ قابل استفاده برای مسئله‌ای با شرایط معلوم باشد. شمارهٔ قرارداد، نام افراد و رفت‌وبرگشت هماهنگی ممکن است در پرونده لازم باشد، اما معمولاً به خوانندهٔ راهنما کمک نمی‌کند. در مقابل، نسخهٔ محصول، نشانهٔ خطا و محدودیت راه‌حل برای انتخاب پاسخ اهمیت دارند. پیوند داخلی میان پرونده و مقاله را نگه دارید تا پشتوانهٔ پاسخ گم نشود.
برای مثال، «مشکل مشتری برطرف شد» دانش قابل انتقالی ندارد. عبارت «در این نسخه، پیوست برای این نقش کاربری باز نمی‌شود؛ دسترسی سند بررسی شد و پس از اصلاح، همان کاربر فایل را باز کرد» نقطهٔ شروع بهتری است. هنوز باید روشن شود کدام شرایط عمومی‌اند و کدام جزئیات فقط به همان پرونده تعلق دارند. یک نشانهٔ مشابه نیز الزاماً علت یکسان ندارد.
این نگاه با KCS® هم‌راستاست. کنسرسیوم نوآوری خدمات در توضیح رسمی تحول KCS در ۲۰۲۶ نام Knowledge-Centered Success و تقدم استفادهٔ دوباره را معرفی کرده است. منابع قدیمی‌تر نام Knowledge-Centered Service دارند. گردش این مقاله یک پیشنهاد مستقل است و ادعای استقرار یا گواهی KCS برای نرم‌افزار یا سازمان خاصی ندارد.
۲. پیش از نوشتن، مسئله و محیط را جست‌وجو کنید
راهنمای رسمی جست‌وجوی زودهنگام و مکرر توصیه می‌کند کشف دانش موجود از ابتدای رسیدگی آغاز شود و با اطلاعات تازه ادامه یابد. ابتدا عبارت کاربر را ثبت کنید؛ سپس نام محصول، نسخه و شرایط رخداد را اضافه کنید. جست‌وجو فقط با عنوان داخلی پروژه، پاسخ‌هایی را که با زبان کاربر نوشته شده‌اند پنهان می‌کند.
برای هر نتیجه، شرایط کاربرد و نتیجهٔ مورد انتظار را بخوانید. اگر هر دو منطبق‌اند، از همان راهنما استفاده کنید و ارتباطش با تیکت را ثبت کنید. اگر پاسخ مفید است اما یک مرحلهٔ مبهم دارد، اصلاح همان مقاله را دنبال کنید. اگر نشانه یکسان ولی محیط یا راه‌حل متفاوت است، تفاوت را صریح بنویسید تا مقالهٔ تازه ارزش مستقلی داشته باشد.
پیشنهاد عملی: پیش از ایجاد عنوان جدید، یک یادداشت کوتاه بنویسید که «چه جست‌وجو شد، کدام پاسخ نزدیک بود و چرا کافی نبود». این یادداشت برای بازبین مفیدتر از برچسب مبهم «تکراری نیست» است. راهنماهای در حال تهیه را هم در جست‌وجوی داخلی ببینید تا دو کارشناس هم‌زمان پاسخ یک مسئله را جدا ننویسند.
۳. قالب کوتاه اما قابل تصمیم بسازید
راهنمای قالب ساده میان مسئله، محیط، راه‌حل، علت و متادیتا تمایز می‌گذارد؛ علت می‌تواند اختیاری باشد. جدول زیر اقتباس لفظی از آن نیست و چند کنترل اجرایی پیشنهادی برای تیم پشتیبانی اضافه می‌کند.
| بخش | پرسش لازم برای نویسنده |
|---|---|
| عنوان و نشانه | کاربر چه کاری می‌خواهد انجام دهد و چه چیزی رخ می‌دهد؟ |
| شرایط کاربرد | پاسخ برای کدام محصول، نسخه، نقش و وضعیت معتبر است؟ |
| تشخیص | چه شاهدی این مسیر را از مسئله‌های مشابه جدا می‌کند؟ |
| اقدام | چه کسی مجاز است، پیش‌نیاز چیست و چگونه برمی‌گردیم؟ |
| تأیید نتیجه | پس از اقدام، کدام رفتار با همان شرایط بررسی می‌شود؟ |
| سابقه و مخاطب | منبع، بازبین، تاریخ بررسی و سطح دسترسی چیست؟ |
«علت تأییدنشده» را با تشخیص قطعی جایگزین نکنید. اگر فقط یک راه‌حل موقت دارید، محدودیت و شرط ارجاع به کارشناس را مشخص کنید. راهنمایی که خواننده را برای ادامهٔ امن متوقف می‌کند، از فرمانی با پیش‌نیاز نامعلوم کاربردی‌تر است.
۴. بازبینی فنی و تعیین مخاطب را دو تصمیم مستقل بدانید
در راهنمای وضعیت مقاله، اطمینان به محتوا، مخاطب و اختیار ایجاد یا ویرایش از هم جدا هستند. بنابراین درست‌بودن پاسخ مجوز انتشار عمومی نیست. ممکن است راه‌حل کاملاً تأیید شده باشد، اما شامل عملیات داخلی یا جزئیاتی باشد که فقط تیم مجاز باید ببیند.
پیشنهاد برای شروع: نویسنده شواهد و شرایط را ثبت کند؛ بازبین فنی، منطق اقدام و آزمون نتیجه را بررسی کند؛ مسئول محتوا دربارهٔ نسخهٔ داخلی یا عمومی تصمیم بگیرد. یک نفر می‌تواند بیش از یک نقش داشته باشد، ولی تصمیم‌ها و مسئول نهایی باید معلوم بمانند. برای اقدام‌های حساس، بازبینی مستقل را در سیاست تیم تعریف کنید.
پیش از انتشار بیرونی، نمونه‌ها را از اطلاعات واقعی پاک کنید: نام و شماره تماس، شناسهٔ قرارداد، توکن، تصویر نشست و جزئیات اتصال لازم نیست در پاسخ عمومی باشند. حذف نام از متن کافی نیست؛ عنوان تصویر، فایل پیوست و نشانی پیوند را هم بررسی کنید. اگر راهنما تغییر تنظیم می‌خواهد، پیش‌نیاز، پشتیبان، روش بازگشت و مرز اختیار خواننده را کنار همان اقدام بیاورید.
۵. مثال آموزشی: از «پیوست باز نمی‌شود» تا پاسخ قابل استفاده
سناریوی زیر فرضی است و نتیجهٔ واقعی مشتری نیست. تیکتی می‌گوید یک کاربر پرتال پیوست سند را نمی‌بیند، اما کاربر داخلی آن را باز می‌کند. کارشناس ابتدا محصول و نسخه، سند موردنظر و نقش آزمایش‌کننده را ثبت می‌کند. راهنمای نزدیک دربارهٔ محدودیت حجم فایل است؛ چون مسئلهٔ حاضر تفاوت دسترسی دو نقش است، استفادهٔ مستقیم از آن توجیه ندارد.
پیش از اصلاح، کارشناس باید علت را با شواهد همان سامانه مشخص کند؛ این مقاله دستور تغییر مجوز پیشنهاد نمی‌کند. پس از راه‌حل مجاز، آزمون با همان کاربر و سند انجام می‌شود و دسترسی کاربری که نباید فایل را ببیند نیز بررسی می‌شود. پاسخ عمومی می‌تواند مسیر گزارش نشانه و اطلاعات لازم برای پشتیبانی را توضیح دهد؛ جزئیات اصلاح دسترسی در راهنمای داخلی باقی می‌ماند.
عنوان پیشنهادی داخلی «بررسی تفاوت دسترسی پرتال و کاربر داخلی به پیوست سند» از عنوان «رفع مشکل فایل» دقیق‌تر است. متن باید شرایط اعتبار و مرز ارجاع را داشته باشد. اگر حل مسئله به توسعه یا افزایش تعهد پروژه منجر شد، پرونده را به فرایند ارزیابی درخواست تغییر وصل کنید؛ مقالهٔ دانش جای تصمیم قراردادی را نمی‌گیرد.
۶. در Odoo 19 چه امکاناتی در اختیار تیم است؟
طبق مستندات Help Center در Odoo 19، Helpdesk با Knowledge، انجمن و آموزش الکترونیکی یکپارچه می‌شود. جست‌وجوی مقاله از تیکت و استفاده از clipboard box برای بازاستفادهٔ متن پاسخ پشتیبانی می‌شود؛ گزینه‌های مرتبط با تیکت هنگام ورود از Helpdesk دیده می‌شوند.
انتخاب مقالهٔ ریشه برای تیم، همهٔ زیرمقاله‌ها را خودکار عمومی نمی‌کند؛ مقالهٔ موردنظر مشتری باید جداگانه منتشر شود. فعال‌کردن قابلیت‌های Help Center ممکن است برنامه‌های وابسته را نصب کند. پیش از تغییر، نسخه، برنامه‌های موجود، مجوز و هزینهٔ سرویس را در محیط خود بررسی کنید. این امکانات را نباید بدون بررسی به همهٔ نصب‌های Community نسبت داد.
پیشنهاد اجرایی ما این است که ابتدا یک مجموعهٔ داخلی کوچک بسازید و دسترسی‌ها را با نقش واقعی خواننده آزمایش کنید. برای نسخهٔ عمومی، پالایش و تأیید جدا داشته باشید. وجود دکمهٔ اشتراک‌گذاری به‌تنهایی گردش کنترل کیفیت تیم را تعریف نمی‌کند.
۷. استفادهٔ دوباره را به بازخورد قابل رسیدگی وصل کنید
اصل بازبینی هنگام استفاده بر اصلاح دانش در زمان مواجهه با مسئله تأکید دارد. برای اجرای آن، گزارش «این پاسخ کار نکرد» باید به یک مسئول برسد و شامل نسخه، مرحلهٔ مبهم و نتیجهٔ مشاهده‌شده باشد. اگر کارشناس اختیار اصلاح ندارد، مسیر اعلام نقص را کوتاه و روشن کنید.
پایلوت پیشنهادی را با یک خانوادهٔ مسئله آغاز کنید. در نشست بازبینی، چند تیکت را از ابتدا دنبال کنید: آیا پاسخ پیدا شد، محیطش منطبق بود، مرحله‌ای جا افتاد و اصلاح به مسئول رسید؟ شمار مقاله به‌تنهایی کیفیت را نشان نمی‌دهد. از شکست جست‌وجو و پاسخ نامفهوم برای انتخاب کار بعدی استفاده کنید؛ هدف‌گذاری تعداد اجباری می‌تواند مقاله‌های کم‌ارزش تولید کند.
اگر پیش‌نیازهای خدمت از ابتدا مبهم تحویل شده‌اند، ریشهٔ بخشی از پرسش‌ها را در بستهٔ تحویل سفارش به اجرا بررسی کنید. پایگاه دانش باید به اصلاح فرایند خوراک بدهد، وگرنه تیم فقط توضیح مشکل تکرارشونده را بهتر می‌نویسد.
اقدام بعدی: یک تیکت حل‌شده را انتخاب کنید، پاسخ نزدیک را بیابید و راهنمای آن را با شرایط کاربرد، آزمون نتیجه و مخاطب روشن بازبینی کنید. برای طراحی این گردش در کنار ERP و پشتیبانی سازمانی می‌توانید از آسیاپرداز مشاوره بگیرید.
منابع KCS در پیوندهای متن، از جمله راهنمایی با عنوان ۲۰۲۷ که هنگام پژوهش در دسترس بود، با تاریخ بررسی ۱۲ نوامبر ۲۰۲۶ خوانده شدند. KCS® نشان خدمات Consortium for Service Innovation™ است. این متن ترجمهٔ راهنمای رسمی نیست؛ مثال و چک‌لیست‌ها پیشنهاد تحریریه‌اند و ادعای آمار یا نتیجهٔ استقرار ندارند.