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