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