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