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