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