تماس موفق و پیگیری کامل را جدا تعریف کنید
ابتدا دو خروجی بنویسید: مشتری به اپراتور درست رسیده و نتیجه مکالمه در مسیر پیگیری ثبت شده است. اولی به ارتباطات و دومی به پرونده مشتری مربوط است. در دامنه این سایت، VoIP مستقل زیرساخت تماس را پوشش می‌دهد و CRM مجهز به VoIP ارتباط تماس با سابقه و اقدام بعدی را تعریف می‌کند. در یک پروژه مشترک، هر دو خروجی باید معیار پذیرش روشن و مسئول تأیید داشته باشند.
- اپراتور پیش از پاسخ چه زمینه‌ای باید ببیند؟
- پس از تماس، چه نتیجه‌ای ثبت و به چه کسی ارجاع می‌شود؟
- کدام خروجی در CRM و کدام در زیرساخت تماس آزموده می‌شود؟
رکورد تماس را با اطلاعات مشتری یکی نگیرید
در نمونه مستند Microsoft Dataverse، فعالیت تماس دارای شناسه، مالک و ارتباط با رکورد مرتبط است. پیشنهاد این راهنما آن است که شماره تماس، رویداد مکالمه و پرونده مشتری در نگاشت داده جدا مشخص شوند. برای نمونه فرضی، تغییر شماره مشتری نباید معنای یک تماس قبلی را نامشخص کند. از تیم بخواهید برای یک تماس، شناسه رویداد و پرونده مرتبط را در محیط آزمون نشان دهد.
- شناسه تماس و مرجع پرونده مشتری را ثبت کنید.
- مالک رکورد و فرد مسئول پیگیری را روشن کنید.
- معنای جهت، زمان و نتیجه تماس را در نگاشت بنویسید.
منبع فنی این بخش: Microsoft Learn [۱]
شماره ناشناخته و مشترک را پیش از اتصال بررسی کنید
برای تطبیق شماره، تنها مسیر ساده را در نظر نگیرید. در چک‌لیست پیشنهادی، شماره ناشناخته، شماره مشترک چند پرونده و تغییر شماره مشتری سناریوهای مستقل هستند. با مالک فرایند مشخص کنید چه زمانی اپراتور باید تطبیق را بررسی کند و چه زمانی می‌توان نتیجه را ثبت کرد. هدف پذیرش این است که ابهام به‌صورت قابل مشاهده باقی بماند و تماس به اشتباه به مشتری دیگری نسبت داده نشود.
- یک شماره بدون پرونده را وارد آزمون کنید.
- دو پرونده با شماره مشترک را بررسی کنید.
- مسئول اصلاح اطلاعات تماس را از پیش تعیین کنید.
پس از مکالمه، مسئول و اقدام بعدی مشخص باشد
یک نمونه ساختگی از تماس مشتری را تا پاسخ نهایی درخواست دنبال کنید. ثبت جمله‌ای مانند «تماس انجام شد» برای تعریف پیگیری کافی نیست؛ پیشنهاد ما ثبت نتیجه، مسئول اقدام بعدی و زمان یا وضعیت مورد توافق است. اگر مسئول پرونده عوض شود، مسیر ارجاع باید با تیم مرور شود. این قواعد پیش از ساخت فرم و گزارش تعریف شوند تا ابزار با روش واقعی کار تیم هماهنگ باشد.
- اپراتور چه نتیجه‌ای از تماس ثبت می‌کند؟
- اگر نیاز به پاسخ واحد دیگری باشد، مالک پیگیری کیست؟
- چگونه تیم متوجه درخواست بدون مسئول می‌شود؟
گزارش را با رویداد قابل ردیابی بسنجید
پیش از طراحی نمودار، یک پرسش مدیریتی و تعریف داده آن را ثبت کنید. برای نمونه فرضی، مدیر می‌خواهد تماس‌های دارای پیگیری باز را ببیند؛ پس رویداد تماس و وضعیت پیگیری هر دو باید قابل مراجعه باشند. در آزمون پیشنهادی، یک رویداد تکراری و قطع اتصال هم بررسی شوند و روش تشخیص و اصلاح مشخص باشد. وجود گزارش تنها زمانی مفید است که تیم معنای شاخص و منشأ داده را یکسان بفهمد.
پایلوت را با سه تماس و یک ارجاع ببندید
برای نسخه اول، یک واحد و مجموعه‌ای محدود از پرونده‌های مجاز را انتخاب کنید. تماس شناخته‌شده، ناشناخته و مشترک را با اپراتور آزمون و نتیجه هر کدام را به مسئول پیگیری وصل کنید. یک ارجاع بین دو نفر را نیز تا پایان دنبال کنید. یافته‌ها را با مالک، اقدام اصلاحی و معیار پذیرش ثبت کنید؛ درباره گسترش پس از مشاهده کار واقعی تیم تصمیم بگیرید.