نیاز و دامنه
جریان تماس، افراد مجاز و معیار نتیجه را مشخص کنید.
داشبورد زنده مرکز تماس؛ از چه چیزی شروع کنیم؟
داشبورد زنده باید به مسئول کمک کند وضعیت خدمت را بفهمد و اقدام مناسب انجام دهد. رنگ‌های متحرک و عددهای بزرگ به‌تنهایی کافی نیستند. تعریف شاخص، تازگی داده و دامنهٔ دسترسی تعیین می‌کنند آیا تصویر نمایش‌داده‌شده قابل اتکاست یا فقط نمایی جذاب از اطلاعات ناقص است.
طراحی سناریو
مسیر عادی و حالت خطا را با مسئول خدمت هماهنگ کنید.
پایلوت محدود
رفتار واقعی تماس و حفاظت اطلاعات را آزموده کنید.
تحویل و نگهداری
شاهد، محدودیت و مسئول پیگیری را ثبت کنید.
شاخص متناسب با تصمیم
ورودی صف، انتظار، آمادگی اعضا و ظرفیت خطوط را با نقش بیننده انتخاب کنید. شاخصی که اقدام مشخص ندارد ممکن است فقط شلوغی ایجاد کند. پاسخ خودکار را با پاسخ انسان یکی نگیرید. تعریف هر عدد و بازهٔ زمانی آن باید نزدیک داشبورد یا در راهنمای قابل دسترس نوشته شود.
وضعیت اولیه و تغییرات زنده
QueueStatus در AMI نمونهٔ دریافت وضعیت یک یا چند صف است. داشبورد کامل به جمعآوری وضعیت و تطبیق تغییرات نیاز دارد. اتصال دوباره پس از قطع باید داده را همگام کند؛ اتکا به رخدادهای از دست‌رفته میتواند تصویر قدیمی را زنده نشان دهد.
تازگی، قطع منبع و مقدار صفر
زمان آخرین دریافت را نشان دهید و برای دادهٔ قدیمی هشدار واضح داشته باشید. قطع اتصال را با صف خالی یا اپراتور صفر نمایش ندهید. وضعیت نامعلوم باید نامعلوم بماند. آمار تاریخی ممکن است تأخیر داشته باشد؛ آن را بدون توضیح کنار شاخص واقعاً لحظه‌ای قرار ندهید.
رابط واسط و نقش حداقلی
مستند AMI عمل‌ها، رخدادها و مجوزهای رابط را توضیح می‌دهد. نمایش آمار نباید به مرورگر حساب مدیریتی کامل بدهد. سرویس واسط، مجوز حداقلی و محدودیت شبکه را طراحی کنید؛ اطلاعات شماره‌ها در صفحهٔ عمومی یا نمایشگر مشترک آشکار نشود.
هشدار دارای مالک و معیار
برای انتظار طولانی یا خطای منبع، مسئول اقدام و روش بررسی مشخص کنید. هشدار تکراری بدون پیگیری اعتماد را کاهش می‌دهد. آستانه را با ظرفیت و ساعات کاری تنظیم کنید؛ عدد عمومی برای همهٔ سازمان‌ها مناسب نیست. بازهٔ تأخیر قابل قبول را هم متناسب با تصمیم عملیاتی تعیین کنید.
آزمون صحت و تجربهٔ کاربر
تماس نمونه، ورود و خروج عضو، انتقال، قطع جمعآوری و برگشت اتصال را بررسی کنید. در موبایل و نمایشگر تیم، متن و وضعیت باید خوانا باشند و تنها به رنگ تکیه نکنند. تحویل شامل تعریف شاخص، محدودیت پوشش، نقش‌ها و نتیجهٔ آزمون دادهٔ قدیمی است، نه صرفاً تصویر نمودار.
داشبورد مدیریتی و مانیتورینگ گرافیکی زنده در ویوان نت
سامانهٔ فعلی، نیاز کاری و محدودیت‌های اجرا را مشخص کنید تا دامنه، روش و معیار تحویل قابل تعریف شوند. تعداد کاربران و هدف بررسی را در بخش پشتیبانی ویوان نت توضیح دهید؛ رمز، کلید یا تنظیمات محرمانه را در درخواست معمولی نفرستید.
سناریوی آموزشی: داشبورد زنده مرکز تماس
نمایشگر صف پس از قطعی منبع داده همچنان عدد قبلی را نشان می‌دهد. در طراحی اصلاح‌شده، زمان دریافت و وضعیت نامعلوم دیده می‌شوند و هشدار به مسئول می‌رسد. پس از اتصال دوباره، وضعیت اولیه بازخوانی و با تغییرات تطبیق داده می‌شود. تصمیم ظرفیت دیگر بر پایهٔ تصویری کهنه گرفته نمی‌شود.
این مثال آموزشی است، نه پروژهٔ واقعی یا نتیجهٔ عددی ویوان نت؛ روش اجرا و آزمون باید با بستر و اختیار سازمان هماهنگ شوند.
این راهنما از مجموعهٔ تلفن تحت شبکه و ارتباطات صوتی ویوان نت است. برای شناخت مجموعه، معرفی ویوان نت را ببینید.
پرسش‌های متداول دربارهٔ داشبورد مدیریتی و مانیتورینگ گرافیکی زنده
زنده یعنی بدون هیچ تأخیر؟
خیر؛ دامنهٔ تأخیر و روش جمعآوری باید متناسب با نیاز مشخص و آزموده شوند.
قطع منبع را با صفر نشان دهیم؟
نه؛ نبود داده با مقدار صفر فرق دارد و باید واضح نمایش داده شود.
مرورگر حساب کامل AMI داشته باشد؟
خیر؛ رابط واسط و مجوز حداقلی برای نیاز نمایش طراحی کنید.
گزارش تاریخی با داشبورد یکی است؟
نه؛ بازهٔ زمانی، تازگی و تعریف شاخص آنها میتواند متفاوت باشد.
هر هشدار چه چیزی لازم دارد؟
مالک اقدام، معیار روشن، روش بررسی و رفتار تکرار قابل کنترل.
تست مهم بعد از قطع اتصال چیست؟
تازگی داده و همگام شدن دوبارهٔ وضعیت، بدون زنده نشان دادن تصویر قدیمی.
منابع فنی و مطالعهٔ بیشتر
منابع برای مبانی و نمونهٔ روش‌ها هستند؛ انتخاب محصول، ظرفیت و تنظیمات واقعی باید در زمان اجرا و بستر سازمان بررسی شوند.