فروش نرمافزار به سازمان چرا طولانی است؟
چون خریدار یک نفر نیست و خرید نرمافزار روش کار سازمان را عوض میکند. واحد کاربر نیاز را میگوید، واحد فناوری اطلاعات سازگاری و امنیت را میسنجد، مالی بودجه را میخواهد و مدیر امضا میکند. هر قدم جلسه و بررسی خودش را دارد و کار معمولاً چند هفته یا چند ماه طول میکشد.
برای همین فروش نرمافزار به سازمانها با فروش کالای آماده فرق دارد. خریدار میپرسد اگر پروژه شکست خورد چه کسی پاسخ میدهد و دادهی فعلی چطور منتقل میشود. سه چیز دیگر هم زمان را کش میدهد:
- بودجهی سالانه. سازمان ممکن است نیاز را قبول داشته باشد ولی خرید را به سال مالی بعد موکول کند.
- دامنهی متغیر. هر جلسه نیاز تازهای روی میز میگذارد و پروپوزال باید دوباره نوشته شود.
- رقیب پنهان. گاهی رقیب شما شرکت دیگری نیست؛ تیم فناوری داخلی است که میگوید خودمان میسازیم، یا مدیری که میگوید با همین اکسل ادامه میدهیم.
در چنین فروشی یک ماه بعد کسی یادش نیست واحد فناوری در جلسهی دوم چه شرطی گذاشت یا کدام نسخهی پروپوزال برای مالی رفت. کار یک CRM شرکت فناوری اطلاعات این است که همین شرطها و نسخهها را کنار هر فرصت، با مرحله، مسئول و قدم بعدی نگه دارد تا با رفتن یک کارشناس گم نشوند.
مراحل فروش: تماس، دمو، پروپوزال، مذاکره و قرارداد
یک فروش سازمانی معمولاً این مسیر را میرود. نام مرحلهها در هر شرکت فرق دارد، ولی منطقش همین است:
- تماس اولیه. سرنخ از معرفی، نمایشگاه یا سایت میرسد. منبع و مشکلش باید همینجا ثبت شود؛ روشش را در راهنمای مدیریت سرنخ فروش نوشتهایم.
- نیازسنجی. جلسه با واحد کاربر: فرایند امروزشان چیست و چه کسی تصمیم میگیرد.
- دمو. نمایش همهی امکانات نیست؛ همان سناریویی است که در نیازسنجی شنیدهاید، با دادهی نزدیک به کار مشتری.
- پروپوزال. دامنهی کار، زمانبندی و مبلغ روی کاغذ میآید و باید معلوم باشد آخرین نسخه کدام است.
- مذاکره. روی دامنه، پرداخت مرحلهای، مالکیت کد و شرایط پشتیبانی چانه زده میشود.
- قرارداد. واحد حقوقی و مالی متن را میبینند و اولین پرداخت انجام میگیرد.
- اجرا، وصول و تمدید. کار به تیم فنی میرود، مرحلههای پرداخت پیگیری میشود و سال بعد نوبت تمدید میرسد.
وضعیت فروش را نباید روی خودِ مشتری نوشت، چون یک سازمان میتواند همزمان یک پروژهی در حال اجرا و یک فرصت تازه داشته باشد. برای شمردن عبور فرصتها از هر مرحله، راهنمای قیف فروش را ببینید.
در ملل CRM هر فرصت یک معامله در «معاملهها» است و مراحل را مدیر شرکت در «تنظیمات» ← «مدلهای فروش» میسازد. با دکمهی «مدلِ جدید» و «استفاده از این الگو» روی الگوی «فروشِ خدمات» این هفت مرحله میآید: «تماسِ اولیه»، «جلسه/نیازسنجی»، «ارائهیِ پروپوزال»، «مذاکره»، «عقدِ قرارداد»، «اجرا و تحویل» و «پیگیریِ وصول». مرحلهی جدایی به نام دمو در این الگو نیست؛ با «افزودنِ مرحله» آن را اضافه میکنید، با دکمههای بالا و پایین به جای درستش میبرید و «ذخیرهی مدل» را میزنید. بعد در فهرست مدلها دکمهی «پیشفرض» را بزنید، چون مدل پیشفرض اولیه «فروشِ کالا» است و ستونهای «کاریز» فقط از مدل پیشفرض ساخته میشوند. این مراحل به فاکتور وصل نیستند، پس معامله با «بردن به مرحلهی …» در صفحهی معامله یا با کشوی مرحله روی کارت «کاریز» جلو میرود. در «کاریز» هر مرحله یک ستون با تعداد و جمع مبلغ است. جابهجایی مرحله، افزودن محصول و بستن معامله فقط با مسئول همان معامله یا مدیر شرکت است.
چند تصمیمگیر در یک سازمان
در فروش به یک سازمان معمولاً با چهار نقش روبهرو هستید، حتی اگر روی کارت ویزیتها اینطور نوشته نشده باشد:
- کاربر یا حامی. کسی که مشکل را هر روز حس میکند و شما را به داخل سازمان میآورد.
- مدیر فناوری اطلاعات. سازگاری، امنیت، میزبانی و پشتیبانی را بررسی میکند و میتواند کار را متوقف کند.
- مدیر مالی. بودجه، شکل پرداخت و هزینهی سالهای بعد را میسنجد.
- امضاکننده. مدیرعامل یا هیئتمدیره که شاید فقط در آخرین جلسه او را ببینید.
خطر بزرگ این است که همهی ارتباط از یک نفر بگذرد. اگر آن حامی جابهجا شود، شما میمانید و سازمانی که کسی را در آن نمیشناسید.
در ملل CRM هر شخص زیر یک «سازمان» ثبت میشود و «سمت در سازمان» خودش را دارد؛ یعنی مدیر فناوری و مدیر مالی هرکدام شماره و سابقهی جدا دارند. روی هر معامله یک «رابطِ این معامله» از اشخاص همان سازمان انتخاب میشود و بقیه در پروندهی سازمان میمانند. هر مکالمه با کشوی «معامله» به فرصت مربوط وصل میشود و فایل پروپوزال را میتوانید در کادر «پیوست فایل» همان مکالمه بگذارید تا هر نسخه کنار گفتوگوی خودش بماند.
فروش همزمان نرمافزار و سختافزار در یک معامله
شرکت فناوری اطلاعات اغلب فقط نرمافزار نمیفروشد. یک معامله میتواند هم سرور و تجهیزات شبکه داشته باشد، هم نصب و راهاندازی و قرارداد پشتیبانی. شرکتهای سختافزاری هم با همین ترکیب روبهرو هستند، پس یک CRM شرکتهای سختافزاری باید هر دو را یکجا ببیند. سختافزار موجودی و زمان تحویل دارد ولی نصب و پشتیبانی موجودی ندارند؛ پس معامله باید یکجا دیده شود و موجودی فقط برای بخش کالا حساب شود.
در ملل CRM در فرم افزودن کالا/خدمت کشوی «نوع» هست: «کالا» موجودی دارد و «خدمت» موجودی ندارد. در صفحهی هر معامله کارت «محصولات و خدمات» هست و با «افزودنِ محصول» هر دو نوع را کنار هم میگذارید؛ تا وقتی معامله محصول دارد، مبلغ آن جمع همین ردیفهاست. دکمهی «صدور پیشفاکتور» ردیفها را به پیشفاکتور میبرد و پیش از ثبت میتوانید عوضشان کنید. جزئیات این سند را در راهنمای پیشفاکتور بخوانید. برای بخش سختافزار، ورود کالا در «رسیدهای انبار» ثبت میشود و مانده را در «موجودی انبار» میبینید.
یک نکتهی عملی: میشود برای کالا و خدمات دو مدل فروش جدا ساخت، ولی ستونهای «کاریز» فقط از مدلِ پیشفرض ساخته میشوند و معاملهی مدل دیگر در ستون «بدونِ مرحله» مینشیند. اگر بیشتر معاملههایتان ترکیبیاند، یک مدل مشترک سادهتر است.
پیشبینی درآمد از معاملههای باز
جمع سادهی مبلغ معاملههای باز گمراهکننده است، چون معاملهای که تازه دمو شده با معاملهای که قراردادش پیش واحد حقوقی است یک ارزش ندارد. راه رایج پیشبینی وزنی است: مبلغ هر معامله ضربدر احتمال موفقیتش. مثال فرضی: قراردادی با ۸۰۰ میلیون ریال پیادهسازی و ۲۰۰ میلیون ریال پشتیبانی سال اول، با احتمال ۴۰٪ در پیشبینی ۴۰۰ میلیون ریال حساب میشود؛ ولی پشتیبانی سالهای بعد در این عدد نیست و باید جدا دیده شود. روشها را در راهنمای پیشبینی فروش توضیح دادهایم.
در ملل CRM هر مرحلهی مدل فروش ستون «احتمالِ موفقیت» دارد و هر معامله کادر «احتمالِ موفقیت (٪)» که اگر پر شود بر عدد مرحله اولویت دارد. پیشفرض مرحله ۱۰۰ است، پس عددها را باید خودتان تنظیم کنید؛ وگرنه پیشبینی بیش از واقع درمیآید. با «تاریخِ احتمالیِ بستن» معامله در ماه درست مینشیند. دکمهی «گزارش و پیشبینی» بالای صفحهی معاملهها جدولی ماهبهماه با «مبلغِ کامل» و «مبلغِ احتمالی» میدهد. این عدد از مبلغ معاملهها میآید و درآمد تکرارشوندهی اشتراکها را جدا نمیسنجد. مدیر شرکت عدد همهی همکاران را میبیند و کارشناس فقط معاملههای خودش را.
از فروش به اجرا: تحویل کار به تیم فنی
یک گرفتاری رایج بعد از قرارداد این است که کارشناس فروش چیزی قول داده که تیم فنی از آن خبر ندارد، مثل یک گزارش اضافه یا اتصال به نرمافزار حسابداری مشتری. یادداشت تحویل باید دامنهی نهایی، نسخهی پذیرفتهشدهی پروپوزال، رابط فنی سازمان، محل میزبانی و دسترسیها، دادهای که باید منتقل شود، مهلتها و هر قول شفاهی را داشته باشد.
در ملل CRM بعد از «عقدِ قرارداد» در «پروژه ها(وظایف)» یک پروژه میسازید و زیر آن وظیفه تعریف میکنید. در بخش «مسئولانِ این وظیفه» برای هر نفر نقش «مسئولِ انجام» یا «فقط اطلاع»، «اولویت» و «مهلتِ انجام» تعیین میشود. پروژه به معامله وصل نیست؛ پس نام سازمان یا معامله را در عنوان پروژه بنویسید. کارشناس عادی فقط معاملهای را میبیند که مرحلهی فعلیاش به خودش سپرده شده؛ پس تیم فنی بهطور معمول صفحهی معامله را نمیبیند و دامنه و قولها را باید در «شرح عملیات» همان وظیفه بنویسید. فرم وظیفه هم پیوست فایل ندارد، پس فایل نهایی پروپوزال را جدا به تیم فنی برسانید.
تمدید سالانه و قرارداد پشتیبانی را از یاد نبرید
درآمد قرارداد پشتیبانی بیسروصدا از دست میرود: تاریخ تمدید میگذرد، کسی زنگ نمیزند و مشتری هم خودش پیگیری نمیکند. پیگیری تمدید قرارداد پشتیبانی باید زودتر از سررسید شروع شود، نه روز آخر. نشانههای پیش از رفتن مشتری را در راهنمای ریزش مشتری ببینید.
یک روال ساده: هر قرارداد یک تاریخ پایان و یک مسئول تمدید داشته باشد؛ چند هفته مانده به سررسید با مشتری تماس گرفته شود، پیشفاکتور تمدید برود و نتیجه ثبت شود.
در ملل CRM این روال با کار دورهای ساخته میشود. در «پروژه ها(وظایف)» برای همان قرارداد یک وظیفه بسازید، تیک «نیاز به زمانبندی دوره ای» را بزنید، «نوع زمانبندی» را «سالیانه» بگذارید، «تاریخ اجرای بعدی» را چند هفته قبل از سررسید قرار دهید و حتماً «زمان اجرا» بدهید؛ کاری که ساعت نداشته باشد زنگ نمیزند. هر سال نتیجه را با «انجام وظایف دوره ای» ثبت میکنید و تاریخ بعدی یک دوره جلو میرود. این یادآور فقط یک کار دورهای است: قرارداد بهصورت ساختاری ثبت نمیشود، تاریخ پایان و مبلغ تمدید را نمیشود گزارش گرفت، و برای هر قرارداد باید وظیفهی جدا ساخت.
چرا معامله را باختیم؟
معاملهی باخته هم داده است. اگر باختها بهخاطر نبودن یک قابلیت است، به تیم محصول خبر میدهید؛ اگر بهخاطر قیمت است، پیشنهادتان را بازبینی میکنید. این فقط وقتی کار میکند که دلیل از یک فهرست ثابت انتخاب شود، نه اینکه هر کارشناس جملهی خودش را بنویسد.
در ملل CRM معامله با «ناموفق شد» بسته میشود و کشوی «دلیلِ شکست» اجباری است. فهرست از شش دلیل آماده شروع میشود، از جمله «قیمت بالا»، «خرید از رقیب» و «نبودِ بودجه»، و مدیر میتواند در «دلایلِ شکستِ معامله» موردهایی مثل «ساخت داخلی» یا «نبود قابلیت» را اضافه کند. در «گزارش و پیشبینی» جدول «دلایلِ شکست» باختها را به تفکیک دلیل نشان میدهد و معاملهی بسته مرحلهاش را نگه میدارد تا معلوم باشد کجای مسیر باختهاید. اگر سازمانی سال بعد برگشت، معاملهی تازه بسازید تا دلیل باخت قبلی در گزارش بماند. «تبدیل به جاری» برای معاملهای است که اشتباهی بسته شده: مسئول معامله یا مدیر آن را باز میکند و دلیل شکستش دیگر شمرده نمیشود.
ملل CRM برای شرکت نرمافزاری چه دارد و چه ندارد
خلاصه: ملل CRM برای مدیریت فروش، پیشفاکتور و انبار سختافزار به کار شرکت نرمافزاری میآید؛ برای مدیریت اشتراک، پشتیبانی مشتری و کار توسعه نه. اگر تیم فروشتان کوچک است، راهنمای CRM برای کسبوکار کوچک را هم بخوانید.
| نیاز شرکت نرمافزاری | در ملل CRM | توضیح |
|---|---|---|
| مراحل فروش خدماتی با پروپوزال و قرارداد | ✓ داریم | الگوی «فروشِ خدمات»؛ مرحلهی دمو را با «افزودنِ مرحله» اضافه میکنید |
| چند مدل فروش برای کالا و خدمات | ✓ داریم | «مدلهای فروش»؛ ستونهای «کاریز» فقط از مدل پیشفرض ساخته میشوند |
| نرمافزار و سختافزار در یک معامله | ✓ داریم | کشوی «نوع» با «کالا» و «خدمت»، کارت «محصولات و خدمات» و دکمهی «صدور پیشفاکتور» |
| پیشبینی درآمد از معاملههای باز | ✓ داریم | «احتمالِ موفقیت (٪)» و «گزارش و پیشبینی» |
| تحلیل دلیل باخت | ✓ داریم | کشوی اجباری «دلیلِ شکست» و جدول «دلایلِ شکست» |
| تحویل کار به تیم فنی | ✓ داریم | «پروژه ها(وظایف)» و «مسئولانِ این وظیفه»؛ پروژه به معامله وصل نیست |
| یادآور سالانهی تمدید | ✓ داریم | «نیاز به زمانبندی دوره ای» با نوع «سالیانه» و ثبت نتیجه با «انجام وظایف دوره ای»؛ فقط یک کار دورهای است |
| موجودی سختافزار | ✓ داریم | «رسیدهای انبار» و «موجودی انبار» |
| سری ساخت سختافزار | ✓ داریم | تیک «ردیابی با سری ساخت» روی کالا، جدول «سریهای این کالا» در «موجودی انبار» و کادر «شمارهی سری (لات)» روی هر قلم سند |
| چند مخاطب با سمت جدا در یک سازمان | ✓ داریم | «سمت در سازمان» برای هر شخص و یک «رابطِ این معامله» برای هر معامله |
| چند تصمیمگیر با نقش خرید روی یک معامله | ندارد | هر معامله یک رابط دارد؛ نقش هر نفر در خرید (حامی، امضاکننده) ثبت نمیشود و بقیه فقط در پروندهی سازمان میمانند |
| قرارداد ساختاری با تاریخ پایان و مبلغ تمدید | ندارد | یادآور تمدید فقط یک کار دورهای است و قرارداد جدا ثبت نمیشود |
| صورتحساب خودکار اشتراک و شاخص درآمد تکرارشونده | ندارد | فاکتور تمدید را خودتان صادر میکنید و شاخص ماهانهی اشتراک حساب نمیشود |
| تیکت مشتریان شما، SLA و پرتال مشتری | ندارد | «تیکتهای پشتیبانی» داخل برنامه برای ارتباط خودتان با پشتیبانی ملل است |
| ثبت زمان کار روی پروژه و اتصال به ابزار توسعه | ندارد | برای هر مسئول «مدتِ تخمینی» هست، ولی زمان واقعیِ صرفشده روی پروژه یا وظیفه ثبت نمیشود و به ابزار تیم فنی وصل نیست |
| مدیریت کلید لایسنس و سوابق هر دستگاه | ندارد | کلید لایسنس نرمافزار ثبت نمیشود و گارانتی و سابقهی تعمیر هر دستگاه دنبال نمیشود |
| وبسرویس (API) و وبهوک | ندارد | امروز راه اتصال به سامانههای شما نیست و تاریخی هم اعلام نشده |
پرسشهای متداول دربارهی CRM شرکت نرمافزاری
آیا ملل CRM مرحلهی دمو و پروپوزال دارد؟
الگوی «فروشِ خدمات» مرحلهی «ارائهیِ پروپوزال» را دارد ولی مرحلهی جدایی به نام دمو ندارد. مدیر شرکت در «تنظیمات» ← «مدلهای فروش» با «افزودنِ مرحله» آن را اضافه میکند، با دکمههای بالا و پایین جابهجا میکند، «ذخیرهی مدل» را میزند و این مدل را «پیشفرض» میکند.
تمدید قرارداد پشتیبانی خودکار یادآوری میشود؟
فقط بهصورت یک کار دورهای. برای هر قرارداد وظیفهای با «نیاز به زمانبندی دوره ای» و نوع «سالیانه» میسازید و حتماً «زمان اجرا» میدهید. خودِ قرارداد، تاریخ پایان و مبلغ تمدید بهصورت ساختاری ثبت نمیشود و فاکتور تمدید هم خودکار صادر نمیشود.
نرمافزار و سختافزار را میشود در یک معامله فروخت؟
بله. هر قلم با کشوی «نوع» بهعنوان «کالا» یا «خدمت» تعریف میشود و هر دو در کارت «محصولات و خدمات» همان معامله کنار هم مینشینند. «صدور پیشفاکتور» این ردیفها را به پیشفاکتور میبرد و «خدمت» موجودی ندارد.
ملل CRM صورتحساب اشتراک یا تیکت برای مشتریان من دارد؟
نه. صورتحساب خودکار اشتراک، شاخص درآمد تکرارشونده، تیکت مشتریان شما، SLA و پرتال مشتری در ملل CRM نیست. «تیکتهای پشتیبانی» داخل برنامه برای ارتباط خود شرکت شما با پشتیبانی ملل است.