طراحی قیف فروش CRM: ورود، خروج و مالک هر مرحله
6 دقیقه مطالعه

قیف فروش CRM با تعریف مرحله، شرط ورود، شاهد خروج و مالک؛ بدون نرخ تبدیل ادعایی. جدول، چکلیست و اشتباهات رایج.
خط لولهٔ فروش بیشتر وقتها با یک ستونبندی زیبا ساخته میشود: «جدید»، «در حال مذاکره»، «پیشنهاد»، «بستهشده». بعد از سه ماه، هیچکس نمیداند «در حال مذاکره» یعنی چه، فروشندهها هر کدام بر اساس حس خودشان کارت را جابهجا میکنند و پیشبینی فروش بیمعنا میشود. راهحل: هر مرحله یک شرط ورود، یک شاهد خروج و یک مالک داشته باشد. این مقاله روش نوشتن آنها را با نمونه میگوید.
مرز منابع: ساختار خط لوله و مرحله را از مستندات HubSpot و Odoo گرفتهایم (فروشندههای CRM). نرخ تبدیل، درصد برد یا هر عدد «استاندارد صنعت» نمیدهیم؛ عددها را از داده خودتان بخوانید. جدولها و معیارها توصیهٔ نویسندهاند. برای مفهوم کلی CRM راهنمای CRM را ببینید ؛ قانون داده شخصی ایران بررسی نشده است.
مرحله چیست؟
HubSpot خط لوله را راهی برای نمایش فرایند از طریق مرحلهها میداند؛ مرحلهها گامهاییاند که نشان میدهند رکورد کجای فرایند است. برای درآمد، خط لولهٔ معامله و برای مشکلات مشتری، خط لولهٔ تیکت میسازند. نکتهٔ ما: مرحله باید وضعیت مشتری را نشان دهد (مثلاً «نیاز تأیید شده»)، نه فعالیت فروشنده (مثلاً «تماس گرفتم»). فعالیتها در خود رکورد ثبت میشوند؛ مرحله نتیجهٔ آنهاست.
قالب هر مرحله
| مرحله | شرط ورود | شاهد خروج (برای رفتن به بعدی) | مالک |
|---|---|---|---|
| صلاحیتسنجی | سرنخ پذیرفتهشده با راه تماس معتبر | نیاز، تصمیمگیر و بازهٔ زمانی ثبت شده | فروشندهٔ اولیه |
| کشف نیاز | گفتوگوی مستقیم با تصمیمگیر یا تأثیرگذار | مشکل و معیار موفقیت مشتری مکتوب | فروشنده |
| پیشنهاد | نیاز و بودجهٔ تقریبی تأیید شده | پیشنهاد کتبی ارسال شده و قدم بعدی تاریخدار | فروشنده + مدیر |
| مذاکره | مشتری بازخورد کتبی یا جلسه روی پیشنهاد داده | شرایط نهایی توافق شفاهی/کتبی | فروشنده + مدیر |
| بستهشده–برد | توافق نهایی مکتوب | قرارداد/سفارش ثبت شده | مدیر فروش |
| بستهشده–باخت | مشتری رد کرد یا پاسخ نداد پس از پیگیریهای توافقشده | دلیل باخت ثبت شده | فروشنده |
نامها و تعداد مرحلهها نمونهاند؛ مهم، ساختار «ورود/شاهد/مالک» است. شاهد خروج باید چیزی باشد که یک نفر دیگر هم بتواند در رکورد ببیند (یک یادداشت، یک سند، یک تاریخ)؛ «حس خوبی دارم» شاهد نیست.

اجبار با سیستم
HubSpot اجازه میدهد برای ورود به یک مرحله، پر بودن خصیصهای را الزامی کنید (بسته به طرح اشتراک)؛ بدون پر شدن، رکورد وارد آن مرحله نمیشود. اگر CRM شما چنین قابلیتی ندارد، همین قاعده را با اعتبارسنجی یا اتوماسیون پیاده کنید. نمونهٔ خصیصههای الزامی (توصیهٔ نویسنده):
- پیشنهاد: مبلغ، تاریخ ارسال، تاریخ قدم بعدی.
- باخت: دلیل باخت (فهرست بسته، نه متن آزاد).
- برد: شمارهٔ قرارداد یا سفارش.
هر فیلد الزامی هزینهای برای فروشنده دارد؛ آن را فقط جایی بگذارید که تصمیم بعدی به آن وابسته است (به اصول طراحی فرم در فرمهای خوب چگونه طراحی میشوند نگاه کنید).
احتمال هر مرحله: با احتیاط
HubSpot برای هر مرحلهٔ معامله احتمال تعریف میکند و میگوید مرحلههای برد (۱۰۰٪) و باخت (۰٪) برای گزارش لازماند. Odoo هم امتیازدهی پیشبینیکننده دارد که از داده تاریخی خود شما یاد میگیرد؛ مرحله و تیم همیشه در آن دخیلاند و هرچه فرصت بیشتری از خط لوله عبور کند برآورد دقیقتر میشود. دو درس:
- احتمالهای اولیه حدسیاند. آنها را «موقت» بنامید و بعد از چند ماه با داده برد/باخت واقعی خودتان بازنویسی کنید.
- پیشبینی درآمد خط لوله (جمع مبلغ × احتمال) فقط وقتی معنا دارد که تعریف مرحلهها رعایت شود؛ وگرنه خروجی یک عدد ظاهراً دقیق و واقعاً بیمعناست.
ما هیچ نرخ تبدیل یا احتمال پیشفرض پیشنهاد نمیکنیم.
سرنخ: پیش از خط لولهٔ فروش
در Odoo سرنخ گام صلاحیتسنجی پیش از فرصت رسمی است. این جدا کردن مفید است: سرنخها خط لولهٔ خودشان را دارند و فقط پس از صلاحیتسنجی وارد خط لولهٔ فروش میشوند؛ در غیر این صورت فرصتهای واقعی در میان صدها علاقهمندیِ تأییدنشده گم میشوند.
چند مرحله؟
قاعدهٔ عملی (توصیهٔ نویسنده): آنقدر مرحله بگذارید که هر کدام یک شاهد خروج متمایز داشته باشند. اگر نمیتوانید برای دو مرحله شاهدهای متفاوت بنویسید، آنها را ادغام کنید. معمولاً پنج تا هفت مرحله (بهعلاوهٔ برد و باخت) برای فروش خدماتی کافی است، اما این عدد تجربی است و باید با فرایند شما جور شود، نه برعکس. اگر فروشندهها مرتب مرحلهها را رد میکنند یا برمیگردانند، تعریف مرحله مبهم است.
مثال فرضی: فروش یک خدمت نرمافزاری
شرکتی فرضی پروژهٔ سفارشی نرمافزاری میفروشد. خط لولهٔ آن (نمونه):
- صلاحیتسنجی: فرم مشاوره تأیید شد و یک تماس انجام شد. شاهد خروج: ثبت نیاز، نام تصمیمگیر، بازهٔ زمانی تقریبی.
- کشف: جلسهٔ اول با تصمیمگیر. شاهد: سند یکصفحهای «مسئله و معیار موفقیت» که مشتری تأیید کرده است.
- برآورد و پیشنهاد: دامنهٔ اولیه مشخص و پیشنهاد کتبی فرستاده شد. شاهد: پیشنهاد در رکورد و قدم بعدی با تاریخ.
- مذاکره: مشتری روی پیشنهاد بازخورد داد. شاهد: فهرست موارد باز و تصمیم دربارهٔ هر کدام.
- برد/باخت: قرارداد امضاشده یا دلیل باخت از فهرست بسته.
به شاهدها دقت کنید: همه چیزی هستند که همکار دیگر میتواند در رکورد ببیند. در جلسهٔ هفتگی، مدیر فقط کافی است ببیند «کدام رکورد شاهدش را ندارد». برای تبدیل نیازها به کارهای قابلپیگیری در تیم فنی هم میتوانید همین منطق «شاهد» را در معیار پذیرش داستان کاربر بهکار ببرید.
پیری و بازبینی
برای هر مرحله یک «حداکثر ماندن» تعیین کنید (عدد را داده خودتان تعیین میکند) و رکوردهای بیش از آن را در جلسهٔ هفتگی بازبینی کنید: یا قدم بعدی تاریخدار میگیرند یا بسته (باخت) میشوند. فرصت بدون قدم بعدی تاریخدار، پیشبینی را خراب میکند.
جلسهٔ هفتگی خط لوله
- فرصتهای بدون قدم بعدی را پیدا کنید.
- فرصتهایی که از حداکثر ماندن گذشتهاند را تعیین تکلیف کنید.
- مرحلهای که شواهدش کم است برگردانده شود.
- دلیلهای باخت هفته را بخوانید و فهرست دلایل را اصلاح کنید.
اشتباهات رایج
- نامگذاری مرحله بر اساس فعالیت فروشنده.
- مرحله بدون شاهد خروج و بدون مالک.
- احتمالهای حدسی که هیچوقت با داده بازنویسی نمیشوند.
- مرحلههای بسیار زیاد؛ فروشندهها دیگر تفاوتها را نمیفهمند.
- دلیل باخت بهصورت متن آزاد؛ قابلتحلیل نیست.
- اختلاط سرنخ و فرصت در یک ستونبندی.
چکلیست
- هر مرحله شرط ورود، شاهد خروج و مالک دارد.
- مرحلهها وضعیت مشتری را نشان میدهند، نه فعالیت فروشنده.
- برد و باخت مرحلههای جدا با خصیصهٔ الزامی (قرارداد/دلیل باخت) هستند.
- احتمالها موقتاند و تاریخ بازنویسی با داده دارند.
- سرنخها قبل از ورود به خط لولهٔ فروش صلاحیتسنجی میشوند.
- برای هر مرحله حداکثر ماندن و بازبینی هفتگی تعریف شده است.
- هیچ نرخ تبدیل بدون منبع یا داده خودتان در گزارش نیامده است.
اگر وظایف تیم فروش را مثل داستان کاربر مینویسید، قالب User Story چیست برای نوشتن «بهعنوان فروشنده میخواهم…» مفید است.
منابع و مراجع
- Set up and manage object pipelines — HubSpot، 2026-09-29.
- Assign leads with predictive lead scoring (Odoo 20.0) — Odoo S.A..
- Convert leads into opportunities (Odoo 20.0) — Odoo S.A..
نویسنده
سا
سهیل ابراهیمپور بنیانگذار FutureForge است. روی طراحی محصول، معماری و استقرار نرمافزار سفارشی کار میکند.
یادداشتهای مرتبط
برای انتخاب مسیر فنی پروژهتان کمک میخواهید؟
از مسئله و محدودیتهایتان بگویید؛ اگر بتوانیم همراهیتان کنیم، برای گفتوگو هماهنگ میکنیم.




