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