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