با حوصله بخوان، مثالها را تحلیل کن و تمرینها را انجام بده؛ هدف حفظ کردن تعریفها نیست
First Response Time سرعت پاسخ است
زمان پاسخ اولیه فاصله ثبت Ticket تا اولین پاسخ معنیدار تیم است؛ پاسخ خودکار بهتنهایی کیفیت پشتیبانی را نشان نمیدهد نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست برای اینکه این مفهوم در محیط واقعی قابل استفاده شود، میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
Resolution Time زمان حل است
زمان حل از شروع تا بازگرداندن سرویس یا تکمیل درخواست را میسنجد و باید با اولویت و ساعت خدمت تفسیر شود نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
Backlog تعداد Ticket باز است
Backlog فقط تعداد Ticket باز نیست؛ Age، اولویت و علت ماندن آنها هم مهم است. Backlog قدیمی میتواند نشانه کمبود ظرفیت یا فرایند ضعیف باشد پایش مؤثر فقط جمع کردن عدد و Log نیست؛ باید وضعیت عادی سرویس شناخته شود، Metricهای معنادار انتخاب شوند و Alert زمانی ایجاد شود که نیاز به اقدام دارد؛ Syslog چارچوبی برای انتقال پیامهای رویداد ارائه میدهد و SNMP برای مشاهده و مدیریت بسیاری از تجهیزات شبکه استفاده میشود؛ همگام بودن زمان سیستمها برای ارتباط دادن رویدادهای چند دستگاه ضروری است و Log باید در کنار وضعیت سرویس و تغییرات همان بازه تحلیل شود در مدیریت خدمت، Incident با هدف بازگرداندن سرویس عادی پیگیری میشود و Service Request معمولاً درخواست از پیش تعریفشده برای یک خدمت یا دسترسی است؛ اولویت باید از اثر رخداد و فوریت آن نتیجه شود و SLA چارچوب زمانی توافقشده برای سطح خدمت را مشخص میکند؛ Ticket خوب باید زمان، کاربر یا سرویس درگیر، نشانه، دامنه اثر، اقدامات انجامشده و نتیجه را طوری ثبت کند که نفر بعدی بتواند مسیر بررسی را ادامه دهد
First Contact Resolution معیار مفیدی است
حل در اولین تماس نشان میدهد چه درصدی از درخواستها بدون رفتوبرگشت یا ارجاع اضافه حل شدهاند؛ بالا بردن مصنوعی آن نباید کیفیت را کم کند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند اگر بخواهی این بخش را از حالت تعریف به مهارت عملی تبدیل کنی، اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست برای کامل شدن تصویر این موضوع، این درس بخشی از مدل کاری یک کارشناس پشتیبانی است و هدف آن فقط شناخت یک اصطلاح نیست؛ باید بتوانی موضوع را در یک شرکت واقعی تشخیص بدهی، اثر آن را روی کاربر و سرویس بفهمی، شواهد درست جمع کنی و بدون تغییرهای عجولانه تصمیم بگیری؛ هنگام مطالعه تلاش کن هر مفهوم را به یک مثال از محیط کار، یک نشانه قابل مشاهده و یک روش بررسی امن وصل کنی
KPI نباید باعث بستن بیکیفیت شود
KPI نباید باعث بستن بیکیفیت شود؛ اینجا یک رابطه علت و معلولی داریم؛ یعنی دیدن نشانه بهتنهایی علت را ثابت نمیکند، اما این عامل باید در فهرست فرضیهها قرار بگیرد و با یک تست مناسب تأیید یا رد شود اگر KPI فقط تعداد بستن Ticket باشد افراد ممکن است کیفیت را قربانی عدد کنند؛ معیار را با Reopen، رضایت، زمان و حل واقعی متعادل کن در یک شبکه یا سیستم واقعی، این موضوع زمانی روشن میشود که میز خدمت نقطه تماس کاربر با تیم فناوری است و کیفیت ثبت درخواست مستقیماً روی سرعت حل اثر دارد؛ Ticket باید مسئله، اثر، فوریت، سرویس درگیر، کاربر، زمان و شواهد اولیه را ثبت کند؛ اگر درخواست به تیم دیگری ارجاع میشود، نفر بعدی نباید مجبور باشد همه پرسشهای اولیه را از ابتدا تکرار کند نکتهای که هنگام پشتیبانی نباید از آن عبور کنی این است که اولویت با صدای بلندتر کاربر تعیین نمیشود؛ اثر بر کسبوکار و فوریت باید معیار باشند؛ Incident Management هدفش بازگرداندن سرویس عادی است و بعد از بازگشت ممکن است Problem Management برای علت ریشهای ادامه پیدا کند؛ ارتباط وضعیت با کاربر نیز باید منظم و قابل فهم باشد حتی وقتی حل نهایی هنوز آماده نیست
فرض کن در میز خدمت و سامانه درخواستها مشکلی گزارش شده و احتمال میدهی به KPI و گزارشهای پشتیبانی مربوط باشد. قبل از تغییر، وضعیت فعلی را با سامانه Ticketing، Queue، SLA و تاریخچه درخواست بررسی میکنی و نتیجه را با یک حالت سالم یا مستند معتبر مقایسه میکنی. اگر شواهد فرضیه را تأیید کردند، فقط همان بخش مرتبط را تغییر میدهی و بعد همان تست را دوباره اجرا میکنی تا مطمئن شوی مشکل واقعاً برطرف شده است
این اشتباهها را تکرار نکن
- حل در اولین تماس نشان میدهد چه درصدی از درخواستها بدون رفتوبرگشت یا ارجاع اضافه حل شدهاند؛ بالا بردن مصنوعی آن نباید کیفیت را کم کند
- KPI نباید باعث بستن بیکیفیت شود؛ اینجا یک رابطه علت و معلولی داریم؛ یعنی دیدن نشانه بهتنهایی علت را ثابت نمیکند، اما این عامل باید در فهرست فرضیهها قرار بگیرد و با یک تست مناسب تأیید یا رد شود
- تغییر دادن تنظیمات مرتبط با KPI و گزارشهای پشتیبانی قبل از اینکه مطمئن شوی مشکل واقعاً به همین بخش مربوط است
حالا خودت انجام بده
- در یک نمونه آزمایشی مرتبط با KPI و گزارشهای پشتیبانی، فقط وضعیت فعلی را مشاهده کن و سه نکتهای را که برای تشخیص حالت سالم مهماند یادداشت کن
- با سامانه Ticketing، Queue، SLA و تاریخچه درخواست وضعیت مرتبط با KPI و گزارشهای پشتیبانی را بدون تغییر بررسی کن، سه داده واقعی جمع کن و توضیح بده هرکدام چه چیزی به تو میگویند
- یک خطای فرضی مرتبط با KPI و گزارشهای پشتیبانی بنویس و مشخص کن اولین تست کمخطر تو چیست و چه نتیجهای فرضیهات را رد میکند
نکتههایی که باید با خودت ببری
- First Response Time سرعت پاسخ است
- Resolution Time زمان حل است
- Backlog تعداد Ticket باز است
- First Contact Resolution معیار مفیدی است
- KPI نباید باعث بستن بیکیفیت شود
- رمز و اطلاعات محرمانه را داخل Ticket عمومی ثبت نکن
قبل از رفتن به درس بعد، جواب را برای خودت توضیح بده
این نکته را با یک مثال توضیح بده: First Response Time سرعت پاسخ است. بعد بگو در عمل چطور آن را بررسی میکنی.
زمان پاسخ اولیه فاصله ثبت Ticket تا اولین پاسخ معنیدار تیم است؛ پاسخ خودکار بهتنهایی کیفیت پشتیبانی را نشان نمیدهد
این نکته را با یک مثال توضیح بده: Resolution Time زمان حل است. بعد بگو در عمل چطور آن را بررسی میکنی.
زمان حل از شروع تا بازگرداندن سرویس یا تکمیل درخواست را میسنجد و باید با اولویت و ساعت خدمت تفسیر شود
این نکته را با یک مثال توضیح بده: Backlog تعداد Ticket باز است. بعد بگو در عمل چطور آن را بررسی میکنی.
Backlog فقط تعداد Ticket باز نیست؛ Age، اولویت و علت ماندن آنها هم مهم است. Backlog قدیمی میتواند نشانه کمبود ظرفیت یا فرایند ضعیف باشد
برای ذخیره پیشرفت، دوره را رسمی شروع کن
با ثبتنام، تکمیل درسها و نمره آزمون روی حساب ذخیره میشود
