پیگیری مرسوله بدون تماس با پشتیبانی - وقتی بخش سخت، اتصال است نه هوش مصنوعی
«مرسوله من کجاست؟» بخش عمده تماسهای پشتیبانی هر شرکت حمل است. و نکته جالب این است که پاسخش کاملاً در داده موجود است - هیچ قضاوت، هیچ استنتاج و هیچ هوشی لازم ندارد. پس چرا هنوز از کانال انسانی رد میشود؟
در این صفحه
پاسخ در داده هست؛ پس مشکل کجاست؟
برخلاف پیشبینی ریزش یا تحلیل سند، اینجا هیچ ابهامی وجود ندارد. وضعیت مرسوله در سامانه ردیابی ثبت شده و پاسخ دقیق است.
مشکل سه چیز است و هیچکدام هوش مصنوعی نیست:
- دسترسی - سامانه ردیابی معمولاً به کانالهایی که مشتری در آنهاست وصل نیست
- کد رهگیری - مشتری معمولاً آن را ندارد یا اشتباه وارد میکند
- زبان - وضعیتهای سیستمی به زبان عملیات نوشته شدهاند، نه به زبان مشتری
اتصال، بخش سختِ واقعی
در بسیاری از شرکتهای حمل، وضعیت مرسوله در چند سامانه است: ردیابی ناوگان، سامانه انبار و گاهی سامانه شرکت طرف قرارداد در مسیر آخر. هیچکدام تصویر کامل نمیدهد.
پس اولین کار پروژه، ساختن یک نمای واحد وضعیت است که از این منابع تغذیه میشود. تا آن نما نباشد، چتبات فقط جلوی همان آشفتگی میایستد و پاسخ ناقص میدهد - که از پاسخ ندادن بدتر است.
و نکته عملی: این اتصال باید خواندنی باشد. چتبات وضعیت مرسوله را تغییر نمیدهد؛ فقط میخواند و ترجمه میکند.
کد رهگیری را کاربر ندارد
طراحی رایج این است که ربات اول کد رهگیری بخواهد. در عمل، بخش بزرگی از کاربران آن را ندارند - پیامکش را پاک کردهاند یا اصلاً دریافت نکردهاند.
راههای جایگزینی که باید پشتیبانی شوند:
- شماره موبایل گیرنده یا فرستنده
- شماره سفارش فروشگاه، اگر مرسوله از فروشگاهی آمده
- ترکیب نام و مقصد، برای موارد خاص و با تأیید بیشتر
هر کدام از اینها یک اتصال جدا لازم دارد - و همین باز هم نشان میدهد که کار اصلی این پروژه یکپارچهسازی است.
چند درصد تماسهای شما فقط «کجاست»؟
در جلسه ارزیابی، ترکیب تماسهای پشتیبانی و امکان اتصال به سامانه ردیابی شما بررسی میشود.
پاسخ صادقانه درباره تأخیر
وقتی مرسوله تأخیر دارد، وسوسه این است که ربات پاسخ مبهم بدهد: «در حال پردازش است». این کار تماس را عقب میاندازد، حذف نمیکند - و وقتی مشتری بالاخره تماس بگیرد، عصبانیتر است.
پس ترجمه وضعیتهای سیستمی به زبان مشتری باید صادقانه باشد، و جایی که علت تأخیر در داده هست، گفته شود. این تصمیم محتوایی است نه فنی، و معمولاً بیشترین اثر را روی کاهش تماس دارد.
گردشکار
۱. تشخیص قصد
پیگیری مرسوله، شکایت، تغییر آدرس یا پرسش عمومی - هرکدام مسیر متفاوتی دارند.
۲. شناسایی مرسوله
با کد رهگیری یا مسیرهای جایگزین.
۳. استعلام از نمای واحد وضعیت
اتصال خواندنی به منابع مختلف، پشت یک واسط.
۴. ترجمه به زبان مشتری
با ذکر زمان تخمینی و - در صورت تأخیر - علت آن.
۵. انتقال موارد استثنا
مرسوله مفقود، آسیبدیده یا خارج از الگوی عادی، مستقیم به کارشناس با تمام تاریخچه.
وقتی باید به انسان منتقل شود
سه دسته که ربات نباید سعی کند خودش حل کند:
- مرسوله مفقود یا آسیبدیده - نیاز به تصمیم و احتمالاً جبران خسارت دارد
- شکایت - پاسخ خودکار به شکایت، شکایت را بزرگتر میکند
- درخواست تغییر - تغییر آدرس یا زمان تحویل، عملیات است نه اطلاعرسانی
و یک قاعده کلی: اگر کاربر دو بار پرسش را تکرار کرد، یعنی پاسخ ربات کافی نبوده - انتقال به انسان بهتر از تلاش سوم است.
سنجش و نقطه شروع
معیار اصلی: سهم تماسهای «کجاست» از کل تماسها، پیش و پس. معیار دوم: نرخ انتقال به اپراتور، که اگر خیلی بالا بماند یعنی اتصال ناقص است نه ربات ضعیف.
پیشنهاد ما شروع با یک کانال و یک نوع سرویس است. و پیش از شروع، ترکیب تماسهای پشتیبانی را به تفکیک نوع پرسش بدانید - این عدد هم توجیه پروژه است و هم معیار سنجشش.
جزئیات پلتفرم در صفحه مانوتل است.
پردازش بارنامه در راهنمای بارنامه و بقیه کاربردها در صفحه راهکارهای لجستیک است.
پرسشهای متداول
چون پاسخ صد در صد در داده موجود است و هیچ استنتاجی لازم ندارد. سه مشکل واقعی این است که سامانه ردیابی به کانال مشتری وصل نیست، مشتری کد رهگیری ندارد، و وضعیتها به زبان عملیات نوشته شدهاند. هر سه مسئله یکپارچهسازی و محتوا هستند، نه مدل.
باید مسیرهای جایگزین پشتیبانی شوند: شماره موبایل گیرنده یا فرستنده، شماره سفارش فروشگاه، و در موارد خاص ترکیب نام و مقصد با تأیید بیشتر. طراحیای که فقط کد رهگیری بپذیرد، بخش بزرگی از کاربران را همان اول از دست میدهد.
این معمولاً بزرگترین بخش کار است. اول باید یک نمای واحد وضعیت ساخته شود که از منابع مختلف تغذیه میکند. بدون آن، چتبات فقط جلوی همان آشفتگی میایستد و پاسخ ناقص میدهد - که از پاسخ ندادن بدتر است.
حقیقت را، با علت اگر در داده هست. پاسخ مبهم مثل «در حال پردازش است» تماس را حذف نمیکند، فقط به فردا موکول میکند و مشتری عصبانیتر تماس میگیرد. این تصمیم محتوایی معمولاً بیشترین اثر را روی کاهش تماس دارد.
در طراحی پیشنهادی ما نه. تغییر آدرس یا زمان تحویل عملیات است نه اطلاعرسانی، و به کارشناس منتقل میشود. اتصال چتبات به سامانه ردیابی خواندنی است.
مرسوله مفقود یا آسیبدیده، شکایت، و هر درخواست تغییر. و یک قاعده کلی: اگر کاربر دو بار پرسشش را تکرار کرد، انتقال به انسان بهتر از تلاش سوم است.
با سهم تماسهای «کجاست» از کل تماسها پیش و پس. معیار دوم نرخ انتقال به اپراتور است - اگر خیلی بالا بماند، معمولاً یعنی اتصال ناقص است نه اینکه ربات ضعیف باشد.
