تیم های هوش مصنوعی با شکایت مشتریان چه کنند؟

مشتری می گوید دستیار جواب اشتباه داده؛ کارشناس می گوید برای اصلاح پاسخ خودکار وقت بیشتری می گذارد؛ مدیر محصول هم می گوید کاربران زیادی از قابلیت استفاده می کنند. هر سه ممکن است درست بگویند. اگر فقط به تعداد استفاده نگاه کنیم، بخش مهمی از تجربه مشتری را نمی بینیم.

شکایت نه دستور محصول است و نه سروصدایی که باید خاموشش کرد. سرنخی است درباره فاصله میان آنچه سامانه وعده داده و آنچه در کار واقعی انجام می دهد. کار تیم این است که سرنخ را بررسی کند و در صورت لزوم آن را به اصلاح محصول، داده یا فرایند تبدیل کند.

از گلایه کلی به مورد قابل بررسی

«چت بات بد است» هنوز برای مهندس یا مدیر محصول کاری تعریف نمی کند. اما اگر بدانیم در سه گفت وگو دستیار برای پرسش بازپرداخت به صفحه قدیمی راهنما ارجاع داده و مشتری بعد از پاسخ با کارشناس تماس گرفته، می توانیم بررسی را شروع کنیم. فرض کنید این مورد ها به همین شکل ثبت شده اند؛ شاید منبع کهنه در سامانه مانده باشد، شاید پاسخ منبع را نشان نمی دهد یا دستیار در نبود اطلاعات کافی هم جواب می سازد.

از هر شکایت چند پرسش بیرون بکشید: چه اتفاقی افتاد؟ چه کسی آسیب دید یا کارش دشوار شد؟ کاربر انتظار چه پاسخی داشت؟ چه مدرکی برای بازسازی مورد داریم؟ چه کسی پیگیری را بر عهده می گیرد؟ این پرسش ها احساس مشتری را بی اهمیت نمی کنند؛ آن را به اطلاعاتی تبدیل می کنند که تیم می تواند با آن کاری انجام دهد.

همین روش درباره داده و نرم افزار هم کاربرد دارد. «داشبورد اشتباه است» را به سنجه، بازه زمانی، منبع داده و تصمیمی که بر آن اثر گذاشته وصل کنید. «عامل از کار افتاد» را با ردگیری فراخوانی ابزار و وضعیتی که خرابی در آن رخ داد بررسی کنید.

گزارش روند های تجربه مشتری زندسک به انتظار برای پاسخ سریع، پشتیبانی در کانال های مختلف و شفافیت درباره تصمیم های هوش مصنوعی می پردازد. وقتی تجربه مشتری به سرعت تغییر می کند، گزارش های او کمک می کنند بفهمیم خودکارسازی و فرایند پشتیبانی هنوز با هم جور هستند یا نه.

لحن را از نشانه جدا کنید

کسی که خرابی را تجربه کرده، معمولا با واژگان مهندسی توضیحش نمی دهد. «دیگر به این ابزار اعتماد ندارم» شاید یعنی پاسخ دلیل و منبع ندارد. «وقتم را گرفت» شاید یعنی راه ساده ای برای رسیدن به کارشناس نیست. «همه چیز را دوباره گفتم» می تواند به گسست میان کانال های پشتیبانی اشاره کند.

این به معنی پذیرفتن توهین یا اجرای هر خواسته ای نیست. تیم باید مرز های گفت وگو را نگه دارد، اما نباید چون شکایت احساسی است اصل مشکل را نادیده بگیرد. مشتری معمولا نمی داند نقص از بازیابی، مجوز، سند قدیمی یا پاسخ مدل بوده؛ می داند که مسئله اش حل نشده است.

پاسخ خوب فقط عذرخواهی نیست. اگر خطا تکرار می شود، باید مسئول اصلاح مشخص باشد و نتیجه به کسانی که گزارش داده اند برگردد. گاهی پاسخ درست این است که هنوز علت قطعی نیست؛ راه موقت را بگویید و زمان خبر بعدی را مشخص کنید. وعده اصلاحی که در اختیار تیم نیست، مشکل دوم و لطمه به اعتماد می سازد.

راه رسیدن به انسان را طراحی کنید

لازم نیست هر پاسخ مدل را فردی بررسی کند. اما وقتی پرسش پیچیده، مبهم یا پراثر است، سامانه باید بداند چه زمانی سؤال روشن کننده بپرسد، منبع نشان دهد، از پاسخ دادن خودداری کند یا پرونده را به کارشناس بسپارد. ارجاع خوب زمینه گفت وگو را همراه مشتری می فرستد؛ مشتری را وادار نمی کند ماجرا را از ابتدا تعریف کند.

این بخشی از طراحی خدمت است، نه وصله ای برای بعد. چارچوب مدیریت ریسک هوش مصنوعی NIST سازمان ها را به مدیریت ریسک در سراسر چرخه عمر سامانه دعوت می کند. در محصول رو به مشتری، مسیر انسانی یکی از راه های عملی مدیریت ریسک است.

شکایت را وارد چرخه یادگیری کنید

پرونده پشتیبانی را می توان بست، بی آن که سامانه اصلاح شده باشد. برای جلوگیری از این فاصله، شکایت های تکراری باید به محل های درست برسند: مورد آزمون، تغییر سند مرجع، اصلاح مسیر ارجاع، راهنمای پشتیبانی، پایش یا تصمیم محصول.

گزارش وضعیت مهندسی عامل های LangChain بر مشاهده پذیری، ردگیری، ارزیابی و بازبینی انسانی در ساخت عامل ها تاکید دارد. گزارش وضعیت مهندسی هوش مصنوعی Datadog نیز به قابلیت اطمینان و پایش در محیط عملیاتی می پردازد. بازخورد مشتری باید بخشی از همین تصویر باشد: یک سنجه کلی ممکن است خوب باشد، در حالی که مشتری در مورد های دشوار گرفتار می شود.

برای هر مورد تکرارشونده، تصمیم بگیرید چه تغییری لازم است و چه کسی آن را پیگیری می کند. اگر اقدامی نمی کنید، دلیلش را هم ثبت کنید. همه شکایت ها به قابلیت تازه نمی رسند؛ بعضی نشان می دهند باید مرز محصول را بهتر توضیح داد یا کاربردی را اصلا خودکار نکرد.

در مقاله آشکار کردن کار هوش مصنوعی پیش از آسیب دیدن اعتماد درباره اهمیت دیدن خرابی، هزینه و مسئولیت نوشته ام. شکایت یکی از جاهایی است که سامانه پنهان خودش را نشان می دهد. دفعه بعد که مشتری می گوید «این پاسخ کمکی نکرد»، پیش از بستن پرونده بپرسید: آیا می توانیم مورد را بازسازی کنیم، چه چیزی را یاد گرفتیم و چه کسی تغییر لازم را انجام می دهد؟

مهدی لطفی نژاد متخصص داده و هوش مصنوعی، مشاور و مدرس رسمی با نزدیک به ۲۰ سال تجربه صنعتی است. او به صدها متخصص در خاورمیانه و جنوب شرق آسیا آموزش داده و در DATATWEETS می نویسد تا این تجربه عملی را رایگان و خودآموز در اختیار همه بگذارد.