برای تشخیص انسان از پیام‌گیر، وضعیت «وصل شد» کافی نیست. ممکن است پیام‌گیر تماس را پاسخ داده باشد یا صدای موجود برای تصمیم‌گیری کافی نباشد. در بررسی دستی، برچسب اولیه را از شاهد جدا کنید و برای نتیجه نامطمئن، جای مشخص داشته باشید.
این راهنما برای مدیر عملیات تماس و مسئول کنترل کیفیت است. خروجی آن یک برگه بررسی با سه نتیجه «انسان»، «پیام‌گیر» و «نامشخص» است؛ همراه با قاعده شمارش و چند سناریوی ساختگی. هیچ تماس واقعی انجام نشده و مثال‌ها نتیجه آزمون یک محصول نیستند.
اول مشخص کنید چه چیزی را بررسی می‌کنید
سؤال این برگه این است: «در بخش پاسخِ این تماس، چه کسی یا چه چیزی پاسخ داد؟» انسان‌بودن پاسخ‌دهنده، اثبات هویت مشتری یا انجام‌شدن کار او نیست. شماره‌گیری بی‌پاسخ نیز با اتصال به پیام‌گیر فرق دارد. برای هر نمونه، شناسه، مرحله مورد بررسی و شاهد در دسترس را بنویسید.
اگر فایل کوتاه یا ناقص است، از وضعیت فنی تماس نتیجه انسانی نسازید. شاهد ناکافی می‌تواند علت «نامشخص» باشد؛ این نتیجه را به «بی‌پاسخ» تبدیل نکنید. اگر موضوع اصلی شما تعریف انتظار صف است، راهنمای نرخ رهاشدگی تماس تفاوت رویدادهای آن مرحله را توضیح می‌دهد.
سه برچسب را با معیار قابل بررسی تعریف کنید
| برچسب | مبنای تصمیم در این برگه | چیزی که کافی نیست |
|---|---|---|
| انسان | در سناریوی آموزشی، نقش انسان از پیش معلوم است؛ در بررسی مجاز واقعی، شواهد و معیار مصوب تیم از این تشخیص پشتیبانی کند. | فقط شنیدن «الو»، طول تماس یا برچسب اولیه سامانه |
| پیام‌گیر | شاهد روشنِ پیام خوشامد ضبط‌شده و مسیر گذاشتن پیام، مطابق معیار تعریف‌شده | هر صدای ضبط‌شده، هر بوق یا هر پاسخ خودکار |
| نامشخص | شاهد کافی نیست یا بازبینان با معیار موجود به نتیجه مشترک نمی‌رسند. | حدس برای خالی‌نماندن ستون گزارش |
فکس یا منوی تلفنیِ مشخص را به زور پیام‌گیر ننامید. این برگه برای مقایسه انسان و پیام‌گیر است؛ موارد مشخص خارج از دامنه را با علت جدا ثبت کنید و تعدادشان را کنار گزارش بیاورید. اگر نوع پاسخ روشن نیست، همان نامشخص بماند. شنیدن صدای طبیعی نیز به‌تنهایی تضمین نمی‌کند که گوینده انسان است.
خروجی تشخیص خودکار را با مرجع یکی نگیرید
برای آشنایی با اصطلاحات، مستند رسمی تشخیص پیام‌گیر Twilio در حالت مشخصی خروجی‌هایی مانند human، machine_start، fax و unknown دارد. در همین مستند، تشخیص پیام‌گیر با منتظرماندن تا پایان پیام خوشامد دو رفتار متفاوت‌اند. این‌ها اصطلاحات همان خدمت‌اند، نه نام فیلدهای برگه پیشنهادی ما.
راهنمای پرسش‌های متداول Twilio نیز دو خطای جدا را شرح می‌دهد: انسان ماشین تشخیص داده شود، یا ماشین انسان. بنابراین «برچسب سامانه» را در ستونی مستقل از «برچسب مرجع» نگه دارید. این مستندها زمینه فنی‌اند؛ قابلیت یا دقت سامانه مورد استفاده شما را ثابت نمی‌کنند.
برگه بررسی را چگونه تکمیل کنیم؟
- دامنه را ثابت کنید. بازه، نوع تماس و مرحله پاسخ را پیش از بررسی بنویسید؛ موارد خارج از دامنه دلیل داشته باشند.
- برچسب اولیه را حفظ کنید. مقدار سامانه یا کارشناس قبلی را بازنویسی نکنید؛ نبود مقدار را نیز صریح ثبت کنید.
- مرجع را مستقل بسازید. برای تمرین، سناریوی معلوم داشته باشید. برای داده واقعی، فقط از شواهد مجاز و قابل دسترس به بازبین استفاده کنید.
- شاهد کوتاه بنویسید. محل شاهد در فایل مجاز یا شناسه سناریو را ثبت کنید؛ مشخصات و محتوای خصوصی مشتری را به فایل آموزشی منتقل نکنید.
- اختلاف را حل یا باز نگه دارید. بازبین دوم بدون دیدن حدس اول بررسی کند. دلیل تغییر ثبت شود؛ اگر شاهد کافی نیست، خروجی نهایی نامشخص است.
برای دانلود، از قالب CSV بررسی انسان و پیام‌گیر، سازگار با اکسل استفاده کنید. ستون‌های برچسب اولیه و تصمیم نهایی عمداً خالی‌اند تا تمرین را خودتان انجام دهید. متن سناریوها ساختگی است؛ فایل صوتی یا نتیجه اجرای آزمون به قالب پیوست نشده است.
سناریوهای مرزی را در تمرین نگه دارید
| سناریوی ساختگی | مرجع تمرین | نکته بررسی |
|---|---|---|
| بازیگرِ نقش انسان به پرسش بعدی پاسخ مرتبط می‌دهد. | انسان | منبع نقش معلوم است؛ فقط به طبیعی‌بودن صدا تکیه نکنید. |
| پیام ضبط‌شده درخواست می‌کند پس از بوق پیام بگذارید. | پیام‌گیر | شاهد مربوط به مسیر گذاشتن پیام را ثبت کنید. |
| فقط «الو» شنیده می‌شود و ادامه نمونه موجود نیست. | نامشخص | یک واژه برای تعیین نوع پاسخ کافی نیست. |
| انسانِ نقش‌آفرین با معرفی طولانی سازمان شروع می‌کند و سپس پاسخ مرتبط می‌دهد. | انسان | طول معرفی را معیار قطعی ماشین‌بودن نگیرید. |
| بوقی شنیده می‌شود که منشأ آن در سناریو معلوم نیست. | نامشخص | هر بوق را پایان خوشامد پیام‌گیر حساب نکنید. |
| اتصال ثبت شده اما شاهد صوتی قابل بررسی در دسترس نیست. | نامشخص | نبود شاهد را به پاسخ انسانی یا بی‌پاسخی تبدیل نکنید. |
مخرج گزارش را پیش از دیدن نتیجه بنویسید
در این تمرین، مخرج «تمام نمونه‌های متصلِ داخل دامنه بررسی» است؛ نامشخص‌ها داخل آن می‌مانند. در کنار تعداد انسان و پیام‌گیر، تعداد نامشخص و موارد خارج از دامنه را نشان دهید. حذف نامشخص‌ها از جدول، کیفیت طبقه‌بندی را بهتر نمی‌کند.
مثال صرفاً ساختگی: شش ردیف داخل دامنه جدول بالا شامل دو انسان، یک پیام‌گیر و سه نامشخص‌اند. سهم انسان در این چیدمان ۲ از ۶ و سهم نامشخص ۳ از ۶ است. ردیف هفتم CSV یک فکسِ مشخص و خارج از دامنه است؛ جدا گزارش می‌شود. این کسرها نرخ تماس شرکت یا دقت هیچ ابزاری نیستند.
اگر توافق با مرجع را فقط روی نمونه‌های دارای مرجع قطعی می‌سنجید، همان مخرج محدود را کنار نتیجه بنویسید و تعداد نامشخص‌ها را نیز بیاورید. فایلی که شواهدش ناقص است نباید پنهانی از گزارش ناپدید شود. این برگه جای گزارش همه تلاش‌های تماس یا شمارش مشتری یکتا را نمی‌گیرد.
از اختلاف برچسب به تصمیم عملی برسید
دو نوع خطا را جدا مرور کنید: اگر پیام‌گیر به‌اشتباه «انسان» ثبت شود، تعداد پاسخ‌های انسانی بیش‌ازحد گزارش می‌شود. اگر انسان به‌اشتباه «پیام‌گیر» ثبت شود، ممکن است یک پاسخ انسانی از رسیدگی جا بماند. برای هر اختلاف، شاهد، علت احتمالی و مسئول بررسی را ثبت کنید؛ بدون شاهد تنظیمات را تغییر ندهید.
پیش از تکرار تماس، ترجیح کانال و زمان تماس مشتری را رعایت کنید؛ نامشخص مجوز تماس دوباره نیست. اگر می‌خواهید این معیار را در انتخاب راهکار به کار ببرید، در صفحه بسته‌های اپرا درخواست بررسی یا دمو را با تیم فروش مطرح کنید و نیاز به تفکیک انسان و پیام‌گیر را صریح بنویسید تا امکان اجرا و معیار پذیرش بررسی شود.