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