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