وقتی بازدیدکننده در چت می‌نویسد «قبلاً توضیح دادم»، ابتدا روشن کنید چه سابقه‌ای واقعاً در دسترس است. نبود سابقه را پنهان نکنید و با شباهت نام یا مرورگر، هویت و موضوع قبلی را حدس نزنید. یک خلاصه کوتاه از مشتری بخواهید یا مسیر مجاز یافتن پرونده را توضیح دهید؛ تاریخچه خیالی نسازید.
بازگشت بازدیدکننده با دسترسی به پرونده فرق دارد
دیدن یک پنجره قدیمی یا پیام خوشامد شخصی به معنی دسترسی مجاز به همه سوابق نیست. ممکن است ابزار فقط همین رشته گفتگو را داشته باشد، یا رشته قبلی وجود داشته ولی برای این نشست قابل استفاده نباشد. در طراحی، سه حالت سابقه موجود، سابقه ناموجود و سابقه نیازمند بررسی مجوز را جدا کنید. هر حالت جمله خودش را می‌خواهد تا مشتری بداند چرا داده‌ای دوباره پرسیده می‌شود.
محدودیت را با درخواست کوتاه بیان کنید
نمونه آموزشی: «در این گفت‌وگو جزئیات پیام قبلی را در اختیار ندارم. لطفاً موضوع و آخرین قدمی که انجام دادید را کوتاه بفرمایید تا از همان‌جا ادامه دهیم.» این پاسخ بهتر از ادعای «پرونده‌تان را دیدم» بدون دسترسی است. اگر شناسه درخواست از مسیر مجاز لازم است، همان را بپرسید. دوباره همه فرم طولانی اولیه را تکرار نکنید مگر برای اقدام جدید واقعاً لازم باشد.
اگر بخشی از سابقه هست، مرزش را بگویید
ممکن است متن گفت‌وگوی فعلی دیده شود ولی وضعیت سفارش در سامانه دیگر موجود نباشد. بگویید کدام بخش روشن است و کدام نیاز به بررسی دارد. مثال: «در پیام همین صفحه گفته‌اید ارسال انجام نشده؛ وضعیت واقعی ارسال هنوز برای من قابل مشاهده نیست.» این تفاوت مانع تبدیل ادعای مشتری به وضعیت قطعی سیستم می‌شود. خلاصه قبلی هم اگر قدیمی است باید با آخرین تغییر کنترل شود.
نشست مشترک را در طراحی تمرین کنید
در یک دستگاه مشترک، کاربر بعدی ممکن است پیام‌های مانده از نفر قبلی را ببیند. این مقاله روش احراز هویت یا دستور امنیتی اختصاصی ارائه نمی‌کند؛ نکته آن است که شخص فعلی را با صاحب سابقه یکی نگیرید. از مسئول سامانه بخواهید رفتار خروج، تعویض کاربر و شروع رشته تازه را در محیط آزمایشی نشان دهد. نمایش اطلاعات پیشین باید تابع دسترسی معتبر همان محصول و سازمان باشد.
پایان تمرین را با صداقت زمینه بسنجید
چهار سناریو بسازید: سابقه هست و مرتبط است؛ سابقه نیست؛ موضوع جدید است؛ دستگاه مشترک است. معیار فقط ادامه روان مکالمه نباشد. بررسی کنید آیا دستیار دقیقاً می‌گوید چه چیزی را می‌داند، چه چیزی را نمی‌داند و برای قدم بعد چه داده‌ای لازم است. اگر برای محصولی سابقه بین نشست‌ها تأیید نشده، آن را در بروشور یا پاسخ فروش وعده ندهید. مشتری با توضیح کوتاه و واقعی بهتر می‌تواند مسیر ادامه را انتخاب کند.
جدول دسترسی زمینه؛ نمونه آموزشی
داده‌های جدول زیر ساختگی‌اند و نتیجه اجرای واقعی هیچ محصولی نیستند. آن‌ها را برای تمرین تیم به کار ببرید و قواعد اجرایی را با مسئول همان فرایند تأیید کنید.
| حالت آموزشی | زمینه در دسترس | جمله مناسب | اقدام بعد |
|---|---|---|---|
| همین رشته فعال | پیام‌های جاری | از توضیح همین گفتگو ادامه می‌دهم | تأیید موضوع فعلی |
| رشته قبلی ناموجود | هیچ سابقه مجاز | جزئیات قبلی را ندارم | خلاصه موضوع و آخرین قدم |
| وضعیت سفارش نامعلوم | فقط گفته مشتری | وضعیت واقعی را هنوز نمی‌بینم | بررسی از مسیر مجاز |
| دستگاه مشترک | هویت صاحب سابقه نامعلوم | سابقه به این فرد نسبت داده نشود | شروع مسیر مجاز |
دانلود جدول دسترسی زمینه با قالب CSV سازگار با اکسل. فایل از داده آموزشی تشکیل شده و اطلاعات مشتری واقعی ندارد. پیش از استفاده عملی، عنوان ستون‌ها و مقادیر مجاز را با سامانه خودتان تطبیق دهید.
منبع و ادامه مسیر
مستند Intercom میان شناسه گفت‌وگو و وضعیت آن تمایز می‌گذارد؛ دسترسی محصول دیگر از این منبع اثبات نمی‌شود. Fin Agent API overview. این ارجاع، روش اختصاصی این مقاله یا قابلیت اپرا را گواهی نمی‌کند؛ روش و مثال‌های بالا پیشنهاد تحریریه برای طراحی و آزمون هستند.
برای زمینه مرتبط، اتصال ایجنت صوتی به CRM؛ چه اطلاعاتی قبل و بعد از تماس ثبت می‌شود؟ و شماره‌های تکراری مشتری در CRM؛ چک‌لیست پاک‌سازی بدون حذف سابقه را بخوانید. اگر دنبال راهکار اجرایی هستید، بسته‌ها و مسیر درخواست پیشنهاد اپرا را بررسی کنید؛ امکان اجرای سناریوی خود را با تیم فروش مشخص کنید. انتخاب بسته به معنی ثبت خودکار درخواست، صدور فاکتور یا فعال‌شدن فوری خدمت نیست.
راهنماهای مرتبط با این مسئله
تحویل چت به کارشناس؛ خلاصه‌ای که سؤال مشتری گم نشود و پیام خوشامد چت سایت؛ چند گزینه روشن به جای فهرست طولانی می‌توانند گام بعدی بررسی تیم شما باشند.