فراتر از بن‌بست چت‌بات‌ها: طراحی پشتیبانی رو به جلو

یک گفتگوی پشتیبانی به چیزی فراتر از تولید زبان بستگی دارد. یک پاسخ ممکن است به این دلیل با شکست مواجه شود که درخواست مبهم است، خط‌مشی لازم وجود ندارد، یکپارچه‌سازی در دسترس نیست، مدل مرتکب خطا می‌شود، یا جریان کاری مشتری را به مسیر اشتباهی هدایت می‌کند.

هر علت نیازمند پاسخ مناسبی است. درخواست از کسی برای تغییر بیانِ جمله، سرویس رزرو از دسترس خارج‌شده را بازیابی نخواهد کرد. تغییر مدل نیز سیاست مرجوعی کالا را که کسب‌وکار شما هرگز ارائه نکرده است، به‌روزرسانی نخواهد کرد.

راهنمای منتشرشده‌ی Google برای طراحی گفتگو، بین عدم موفقیت در تفسیر ورودی و خطاها در سیستم‌های متصل تمایز قائل می‌شود. این راهنما توصیه می‌کند که مشکل توضیح داده شود و گام‌های بعدیِ مفید در همان بستر ارائه گردد. این تمایز، نقطه شروع خوبی برای بررسی مسیرهای پشتیبانی خودتان است. Google: طراحی گفتگو — خطاها

چت‌بات‌ها از سیستم‌های اولیه تطبیق الگو مانند ELIZA به سیستم‌هایی تکامل یافته‌اند که مدل‌های زبانی، اطلاعات تجاری و ابزارها را با هم ترکیب می‌کنند. این تاریخچه مفید است، اما یک گفتگوی متقاعدکننده همچنان باید به یک نتیجه کاربردی منجر شود. بنیاد طراحی تعامل: چت‌بات‌ها

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

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

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

برای مثال: «من دستیار AI این کسب‌وکار هستم. می‌توانم خدماتمان را توضیح دهم، در زمینه درخواست‌های رزرو به شما کمک کنم و شما را به تیم پشتیبانی‌مان متصل کنم.»

فقط وظایفی را تبلیغ کنید که پیکربندی و آزمایش کرده‌اید. اگر یک گردش کار، درخواست‌های رزرو را جمع‌آوری می‌کند اما نمی‌تواند جایگاهی را رزرو کند، آن را «استعلام رزرو» بنامید. دستیار را به عنوان AI معرفی کنید و مسیر دسترسی به یک انسان را به‌راحتی قابل‌یافتن نگه دارید.

برای عامل PrimeDev خود، کار را با مجموعه کوچکی از وظایف پشتیبانی‌شده آغاز کنید. برای هر وظیفه یک مسئول، یک منبع اطلاعاتی قابل‌اعتماد و یک نتیجه مشخص تعیین کنید. بازدیدکننده باید بتواند تشخیص دهد که آیا پاسخی دریافت کرده، درخواستی ثبت کرده یا اقدامی را به پایان رسانده است.

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

جزئیاتی را که از قلم افتاده و اقدام بعدی شما را تغییر می‌دهد، جویا شوید. اگر مشتری بگوید «سفارش من مشکلی دارد»، یک پیگیری مفید می‌تواند مشکل تحویل را از مشکل کالا متمایز کند.

در صورتی که ارائه چند گزینه مرتبط پاسخ دادن به سؤال را آسان‌تر می‌کند، آن‌ها را پیشنهاد دهید. از درخواست اطلاعاتی که مشتری قبلاً ارائه کرده است خودداری کنید و فضایی را برای درخواست‌هایی که در گزینه‌های شما نمی‌گنجند، باقی بگذارید.

گزینه‌های هدایت‌شده زمانی مفید هستند که گام بعدی یک عملیات شناخته‌شده باشد. یک کسب‌وکار خدماتی ممکن است گزینه‌های «بررسی خدمات»، «درخواست نوبت» و «تماس با پشتیبانی» را ارائه دهد. هر گزینه باید به یک مسیر فعال و درست هدایت شود.

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

وقتی شفاف‌سازی دیگر کمکی نمی‌کند، مسیر را تغییر دهید. یک سیاست اولیه مفید این است که پس از دو تلاش ناموفق برای شفاف‌سازی، مسیر متفاوتی را پیشنهاد دهید. این آستانه را با توجه به نیازهای مشتریان خود بسنجید؛ این یک تصمیم طراحی است، نه تضمینی برای اینکه هرگونه سوءتفاهمی شناسایی خواهد شد.

راهنمای Google نیز به همین ترتیب توصیه می‌کند که در صورت تکرار خطاها، پاسخ تغییر یابد و تعداد تلاش‌های مجدد محدود شود. برای پشتیبانی کسب‌وکار، یک گام بعدی مناسب می‌تواند ارجاع به یک اپراتور، ثبت تیکت پشتیبانی یا یک روش تماس جایگزین و واضح باشد. Google: طراحی گفتگو — خطاها

مشتری را مجبور نکنید که صرفاً برای دسترسی به کمک انسانی، همان تعامل ناموفق را دوباره تکرار کند.

جملهٔ «همکاری به شما کمک خواهد کرد» نوعی انتظار ایجاد می‌کند. پیش از ارسال این پیام، سیستم به یک درخواست ثبت‌شده یا یک انتقال واقعی نیاز دارد تا تیم بتواند بر اساس آن اقدام کند.

PrimeDev از قابلیت در دست گرفتن گفتگو توسط اپراتور، حالت اپراتوری که پاسخ‌های AI را متوقف می‌کند، و تیکت‌های مشتری مرتبط با گفتگوها پشتیبانی می‌کند. فرآیند ایجاد تیکت می‌تواند شامل زمینهٔ گفتگوی اخیر باشد تا تیم نقطهٔ شروعی برای پیگیری داشته باشد.

جزئیات عملیاتی مربوط به آن قابلیت‌ها را پیکربندی کنید:

چه کسی بر گفتگوها و تیکت‌های ورودی نظارت می‌کند؟

اپراتورها چه زمانی در دسترس هستند؟

نفر بعدی به چه اطلاعاتی نیاز دارد؟

دریافت درخواست‌های خارج از ساعات کاری چگونه تایید می‌شود؟

مشتری چگونه از حل شدن مشکل مطلع خواهد شد؟

دسترسی به گفت‌وگوی مربوطه را حفظ کنید و بررسی کنید چه مواردی به تیکت منتقل می‌شود. گزیده‌ای از پیام‌های اخیر ممکن است شامل جزئیاتی که بسیار قبل‌تر مطرح شده‌اند نباشد، بنابراین فرض نکنید که هر انتقال به طور خودکار تمام زمینه‌های لازم را شامل می‌شود.

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

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

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

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

سهم گفتگوهایی که در بخش اتوماسیون باقی می‌مانند اغلب «نرخ مهار» (containment) نامیده می‌شود. این شاخص می‌تواند مفید باشد، اما به شما نمی‌گوید که آیا مشتری کمکی دریافت کرده است یا خیر. کسی که پس از دریافت سه پاسخ بی‌ربط گفتگو را ترک می‌کند، ممکن است هرگز به اپراتور وصل نشود.

اتوماسیون را در کنار نتایج ارزیابی کنید:

حل مسئله: آیا مشتری پاسخ یا اقدام نهایی مورد نیاز خود را دریافت کرد؟

تلاش مشتری: آن‌ها چند بار اطلاعات را تکرار کردند یا دستیار را اصلاح نمودند؟

بازیابی: آیا یک پاسخ ناموفق به یک گام بعدی مفید منجر شد؟

کیفیت انتقال: آیا تیم زمینه کافی برای ادامه کار دریافت کرد؟

پیگیری: آیا به درخواست رسیدگی شد و مشتری از نتیجه مطلع گردید؟

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

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

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

فردی را برای بررسی موارد ناموفق و به‌روزرسانی دانش یا جریان کاری اختصاص دهید. پژوهش‌های حوزه تعامل انسان و هوش مصنوعی (Human-AI)، این تجربه‌ها را به عنوان یک مسئله طراحی مداوم در نظر می‌گیرند؛ پروژه HAX مایکروسافت چارچوب گسترده‌تری برای برنامه‌ریزی و ارزیابی آن‌ها ارائه می‌دهد. Microsoft Research: دستورالعمل‌های تعامل انسان و هوش مصنوعی (Human-AI)

با کار مورد نظر شروع کنید. یک فرم، جدول مقایسه، صفحه راهنما یا مسیر واضح‌تر محصول ممکن است مسئله را به شکل مستقیم‌تری حل کند. چت را در جایی اضافه کنید که گفتگو به مشتری کمک می‌کند تا مشکلی را توضیح دهد یا گام بعدی را انتخاب کند.

بله. برای کارهای شناخته‌شده از گزینه‌های راهنمایی‌شده و برای پرسش‌هایی که از زبان منعطف بهره می‌برند، از یک عامل هوش مصنوعی استفاده کنید. برای هر دو مسیر، راه واضحی به پشتیبانی انسانی در نظر بگیرید.

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

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

PrimeDev پاسخ‌های AI، جریان‌های هدایت‌شده، کنترل اپراتور و تیکت‌های مشتریان را در یک گردش کار پشتیبانی واحد جمع‌آوری می‌کند. از این قابلیت‌ها برای ساختن مسیری استفاده کنید که تیم شما بتواند آن را مدیریت کند و مشتریانتان بتوانند آن را درک کنند.

با یک سوال شروع کنید: وقتی این پاسخ کمکی نمی‌کند، چه اتفاقی باید بیفتد؟

برای طراحی یک گردش کار پشتیبانی AI با مسیری مشخص برای دسترسی به پشتیبانی انسانی، PrimeDev را بررسی کنید.