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