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