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