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

نظرات کاربران
در حال حاضر امکان ثبت دیدگاه در این بخش فعال نیست.