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