تصمیم میان پشتیبانی از راه دور و مراجعه حضوری را بر امکان بررسی، اختیار و محدودیت واقعی بنا کنید. هر تماس را خودکار به اعزام تبدیل نکنید و برای کاهش اعزام هم مشتری را به کار فنی نامطمئن وادار نکنید. هدف این جدول، انتخاب مسیر خدمت توسط نقش مجاز است؛ نه تشخیص قطعی خرابی از طریق چند سؤال تلفنی.
در شروع، هدف مرحله اول را مشخص کنید
ممکن است فقط شرح مسئله، آموزش استفاده مجاز یا بازبینی یک پیام خطا لازم باشد. این‌ها با تعمیر تخصصی تفاوت دارند. پذیرش باید بداند چه پاسخ‌هایی از پایگاه دانش معتبر مجازند و چه نشانه‌هایی ارجاع می‌خواهند. اگر اطلاعات کافی نیست، مرحله «نیازمند بررسی» انتخاب شود. نبود تصویر یا اتصال، مشتری را مقصر نمی‌کند؛ محدودیت کانال را به عنوان داده تصمیم ثبت کنید.
برای مسیر از راه دور شرط و حد توقف داشته باشید
دسترسی به اطلاعات لازم، امکان توضیح قابل فهم و رضایت به روش ارتباطی از شرط‌های قابل بررسی‌اند. رمز حساب یا کد ورود را در تماس عمومی نگیرید. راهنمای تخصصی و اقدام روی تجهیز فقط طبق دستورالعمل و صلاحیت مربوط انجام شود. اگر وضعیت از دامنه مجاز خارج شد، تماس متوقف یا به نقش مناسب ارجاع شود. ادامه‌دادن صرفاً برای ثبت حل در تماس اول، معیار کیفیت قابل قبولی نیست.
نمونه ساختگی: ابهام با یک سؤال حل می‌شود
در تمرین، مشتری تصور می‌کند دستگاه خراب است اما فقط معنای پیام روی صفحه را نمی‌داند. پرسش محدود درباره متن پیام، مسیر آموزش معتبر را مشخص می‌کند؛ در این مثال نتیجه واقعی مشتری ادعا نمی‌شود. در حالت دیگر، شرحی مطرح می‌شود که بررسی از راه دور در دامنه تیم نیست. تصمیم درست در هر دو حالت یکسان نیست: اولی به پاسخ مجاز و دومی به بررسی نقش مربوط می‌رود، بدون وعده تعمیر قطعی.
تغییر مسیر را همراه با اطلاعات قبلی تحویل دهید
وقتی بازدید لازم شد، شرح دریافت‌شده، اقدام‌های مجاز قبلی و علت انتخاب مراجعه به دستور کار منتقل شوند. مشتری نباید همه چیز را برای نفر بعد از ابتدا بگوید. اگر از مراجعه به مسیر دیگر برگشتید، رزرو و پیام قبلی را اصلاح کنید تا دو اقدام موازی شکل نگیرد. در گزارش، انتخاب اولیه کانال، علت تغییر و نتیجه واقعی را جدا ببینید؛ تعداد اعزام کمتر بدون مشاهده کیفیت، موفقیت قطعی نیست.
درخت تصمیم ارجاع از تماس به بازدید
ردیف‌های زیر کاملاً آموزشی و ساختگی‌اند؛ شناسه‌ها، نقش‌ها و تصمیم‌ها نمونه هستند و اطلاعات مشتری واقعی ندارند. در نسخه کاری، مسئول هر تصمیم و مرجع تأیید را از فرایند واقعی مجموعه وارد کنید.
| حالت آموزشی | شرط قابل بررسی | مسیر پیشنهادی | حد توقف |
|---|---|---|---|
| پرسش استفاده | پاسخ معتبر در دسترس | راهنمای مجاز از راه دور | خروج از دامنه دانش |
| شرح ناقص | داده لازم نامعلوم | تکمیل توسط نقش مناسب | تشخیص حدسی ممنوع |
| نیاز به مشاهده حضوری | طبق تصمیم مسئول مجاز | بررسی امکان بازدید | زمان اعزام بدون تأیید نه |
دانلود درخت تصمیم ارجاع از تماس به بازدید با فرمت CSV سازگار با اکسل. فایل آموزشی را ابتدا با یک پرونده ساختگی تکمیل کنید؛ ستون مبهم را اصلاح کنید و فقط اطلاعات ضروری عملیات را در نسخه اجرایی نگه دارید.
Microsoft Learn نقش پذیرش، هماهنگ‌کننده و کارشناس میدانی را از هم متمایز می‌کند. Microsoft Learn: Overview of Dynamics 365 Field Service صرفاً نمونه مستند یک سامانه است؛ این مقاله آموزش استفاده از آن سامانه یا بیان قانون ایران نیست. الگوی عملیاتی بالا را با سیاست معتبر مجموعه خود تطبیق دهید.
این روال را به پاسخ‌گویی تیم وصل کنید
در ارزیابی پاسخ‌گویی تلفنی، تصمیم درست برای ارجاع را هم موفقیت ببینید. حل‌کردن اجباری هر مسئله در تماس، جای رعایت اختیار و محدودیت خدمت را نمی‌گیرد. برای تکمیل جزئیات، پیش از ارجاع به پشتیبان فنی چه اطلاعاتی از مشتری بگیریم؟، فرم ثبت درخواست خدمات تلفنی؛ چه اطلاعاتی لازم است؟ را بخوانید. برای بررسی تناسب پاسخ‌گویی تلفنی با این فرایند، بسته‌های ابری اپراگپ و مسیر درخواست بررسی توسط تیم فروش را ببینید؛ اتصال به سامانه داخلی، اختیار تصمیم و شرایط اجرا باید جداگانه بررسی شوند.
راهنماهای مرتبط با این مسئله
جدول مهارت کارشناس برای ارجاع خدمات؛ صرفاً نزدیک‌ترین نیرو را نفرستیم و وقتی انجام خدمت را نمی‌پذیریم؛ متن محترمانه و ثبت دلیل می‌توانند گام بعدی بررسی تیم شما باشند.