FutureForgeFutureForge

خدمات FutureForge

  • طراحی و ساخت محصولاز شناخت نیاز تا انتشار محصول، یک مسیر روشن پیش رو دارید.
  • توسعه فول‌استکوب‌اپلیکیشن، API و داده را هماهنگ و یکپارچه توسعه دهید.
  • ممیزی مهندسیپیش از هزینه‌ی بیشتر، از وضعیت واقعی محصول‌تان باخبر شوید.
  • مشاوره معماریپیش از یک تصمیم فنی پرهزینه، گزینه‌ها را درست بسنجید.
  • زیرساخت و استقرارمحصول را با خیال راحت منتشر کنید و پایدار نگه دارید.
  • هوش مصنوعی در محصولهوش مصنوعی را فقط جایی به کار می‌گیریم که مسئله‌ای را حل کند.
نمونه‌کارهایادداشت‌هاقیمت‌گذاریدرباره ما
شروع گفتگو
  1. خانه
  2. /یادداشت‌ها
  3. /یادداشت‌ها
FutureForge

استودیوی مهندسی محصول — طراحی، ساخت و استقرار نرم‌افزار.

خدمات

طراحی سایت با وردپرستوسعه اختصاصیمهندسی محصولزیرساخت و استقرارمشاوره معماریهوش مصنوعی در محصول

راهنمای انتخاب

یادداشت‌هاقیمت‌گذاریتخمین هزینه پروژهمقایسه روش‌هانمونه‌کارهادرباره ماتماس

ارتباط

hello@futureforge.ir

ایده‌ای برای ساخت دارید؟

نیازتان را مطرح کنید تا درباره مسیر توسعه و قدم بعدی صحبت کنیم.

شروع گفتگو

© 2026 FutureForge. همه حقوق محفوظ است.

حریم خصوصیشرایط استفاده
خانهنمونه‌کارشروعتماس
مهندسی محصول

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

سا
سهیل ابراهیم‌پور
·۲ آبان ۱۴۰۵·6 دقیقه مطالعه
قیف فروشpipeline CRMمرحلهٔ فروشمعیار خروجپیش‌بینی فروش
تیم فروش در حال مرور برد کارت‌های خط لولهٔ فروش

قیف فروش CRM با تعریف مرحله، شرط ورود، شاهد خروج و مالک؛ بدون نرخ تبدیل ادعایی. جدول، چک‌لیست و اشتباهات رایج.

خط لولهٔ فروش بیشتر وقت‌ها با یک ستون‌بندی زیبا ساخته می‌شود: «جدید»، «در حال مذاکره»، «پیشنهاد»، «بسته‌شده». بعد از سه ماه، هیچ‌کس نمی‌داند «در حال مذاکره» یعنی چه، فروشنده‌ها هر کدام بر اساس حس خودشان کارت را جابه‌جا می‌کنند و پیش‌بینی فروش بی‌معنا می‌شود. راه‌حل: هر مرحله یک شرط ورود، یک شاهد خروج و یک مالک داشته باشد. این مقاله روش نوشتن آن‌ها را با نمونه می‌گوید.

مرز منابع: ساختار خط لوله و مرحله را از مستندات HubSpot و Odoo گرفته‌ایم (فروشنده‌های CRM). نرخ تبدیل، درصد برد یا هر عدد «استاندارد صنعت» نمی‌دهیم؛ عددها را از داده خودتان بخوانید. جدول‌ها و معیارها توصیهٔ نویسنده‌اند. برای مفهوم کلی CRM راهنمای CRM را ببینید ؛ قانون داده شخصی ایران بررسی نشده است.

مرحله چیست؟

HubSpot خط لوله را راهی برای نمایش فرایند از طریق مرحله‌ها می‌داند؛ مرحله‌ها گام‌هایی‌اند که نشان می‌دهند رکورد کجای فرایند است. برای درآمد، خط لولهٔ معامله و برای مشکلات مشتری، خط لولهٔ تیکت می‌سازند. نکتهٔ ما: مرحله باید وضعیت مشتری را نشان دهد (مثلاً «نیاز تأیید شده»)، نه فعالیت فروشنده (مثلاً «تماس گرفتم»). فعالیت‌ها در خود رکورد ثبت می‌شوند؛ مرحله نتیجهٔ آن‌هاست.

قالب هر مرحله

مرحلهشرط ورودشاهد خروج (برای رفتن به بعدی)مالک
صلاحیت‌سنجیسرنخ پذیرفته‌شده با راه تماس معتبرنیاز، تصمیم‌گیر و بازهٔ زمانی ثبت شدهفروشندهٔ اولیه
کشف نیازگفت‌وگوی مستقیم با تصمیم‌گیر یا تأثیرگذارمشکل و معیار موفقیت مشتری مکتوبفروشنده
پیشنهادنیاز و بودجهٔ تقریبی تأیید شدهپیشنهاد کتبی ارسال شده و قدم بعدی تاریخ‌دارفروشنده + مدیر
مذاکرهمشتری بازخورد کتبی یا جلسه روی پیشنهاد دادهشرایط نهایی توافق شفاهی/کتبیفروشنده + مدیر
بسته‌شده–بردتوافق نهایی مکتوبقرارداد/سفارش ثبت شدهمدیر فروش
بسته‌شده–باختمشتری رد کرد یا پاسخ نداد پس از پیگیری‌های توافق‌شدهدلیل باخت ثبت شدهفروشنده

نام‌ها و تعداد مرحله‌ها نمونه‌اند؛ مهم، ساختار «ورود/شاهد/مالک» است. شاهد خروج باید چیزی باشد که یک نفر دیگر هم بتواند در رکورد ببیند (یک یادداشت، یک سند، یک تاریخ)؛ «حس خوبی دارم» شاهد نیست.

مرحله‌ها با ورود و شاهد خروج
نمودار مفهومی.

اجبار با سیستم

HubSpot اجازه می‌دهد برای ورود به یک مرحله، پر بودن خصیصه‌ای را الزامی کنید (بسته به طرح اشتراک)؛ بدون پر شدن، رکورد وارد آن مرحله نمی‌شود. اگر CRM شما چنین قابلیتی ندارد، همین قاعده را با اعتبارسنجی یا اتوماسیون پیاده کنید. نمونهٔ خصیصه‌های الزامی (توصیهٔ نویسنده):

  • پیشنهاد: مبلغ، تاریخ ارسال، تاریخ قدم بعدی.
  • باخت: دلیل باخت (فهرست بسته، نه متن آزاد).
  • برد: شمارهٔ قرارداد یا سفارش.

هر فیلد الزامی هزینه‌ای برای فروشنده دارد؛ آن را فقط جایی بگذارید که تصمیم بعدی به آن وابسته است (به اصول طراحی فرم در فرم‌های خوب چگونه طراحی می‌شوند نگاه کنید).

احتمال هر مرحله: با احتیاط

HubSpot برای هر مرحلهٔ معامله احتمال تعریف می‌کند و می‌گوید مرحله‌های برد (۱۰۰٪) و باخت (۰٪) برای گزارش لازم‌اند. Odoo هم امتیازدهی پیش‌بینی‌کننده دارد که از داده تاریخی خود شما یاد می‌گیرد؛ مرحله و تیم همیشه در آن دخیل‌اند و هرچه فرصت بیشتری از خط لوله عبور کند برآورد دقیق‌تر می‌شود. دو درس:

  1. احتمال‌های اولیه حدسی‌اند. آن‌ها را «موقت» بنامید و بعد از چند ماه با داده برد/باخت واقعی خودتان بازنویسی کنید.
  2. پیش‌بینی درآمد خط لوله (جمع مبلغ × احتمال) فقط وقتی معنا دارد که تعریف مرحله‌ها رعایت شود؛ وگرنه خروجی یک عدد ظاهراً دقیق و واقعاً بی‌معناست.

ما هیچ نرخ تبدیل یا احتمال پیش‌فرض پیشنهاد نمی‌کنیم.

سرنخ: پیش از خط لولهٔ فروش

در Odoo سرنخ گام صلاحیت‌سنجی پیش از فرصت رسمی است. این جدا کردن مفید است: سرنخ‌ها خط لولهٔ خودشان را دارند و فقط پس از صلاحیت‌سنجی وارد خط لولهٔ فروش می‌شوند؛ در غیر این صورت فرصت‌های واقعی در میان صدها علاقه‌مندیِ تأییدنشده گم می‌شوند.

چند مرحله؟

قاعدهٔ عملی (توصیهٔ نویسنده): آن‌قدر مرحله بگذارید که هر کدام یک شاهد خروج متمایز داشته باشند. اگر نمی‌توانید برای دو مرحله شاهدهای متفاوت بنویسید، آن‌ها را ادغام کنید. معمولاً پنج تا هفت مرحله (به‌علاوهٔ برد و باخت) برای فروش خدماتی کافی است، اما این عدد تجربی است و باید با فرایند شما جور شود، نه برعکس. اگر فروشنده‌ها مرتب مرحله‌ها را رد می‌کنند یا برمی‌گردانند، تعریف مرحله مبهم است.

مثال فرضی: فروش یک خدمت نرم‌افزاری

شرکتی فرضی پروژهٔ سفارشی نرم‌افزاری می‌فروشد. خط لولهٔ آن (نمونه):

  1. صلاحیت‌سنجی: فرم مشاوره تأیید شد و یک تماس انجام شد. شاهد خروج: ثبت نیاز، نام تصمیم‌گیر، بازهٔ زمانی تقریبی.
  2. کشف: جلسهٔ اول با تصمیم‌گیر. شاهد: سند یک‌صفحه‌ای «مسئله و معیار موفقیت» که مشتری تأیید کرده است.
  3. برآورد و پیشنهاد: دامنهٔ اولیه مشخص و پیشنهاد کتبی فرستاده شد. شاهد: پیشنهاد در رکورد و قدم بعدی با تاریخ.
  4. مذاکره: مشتری روی پیشنهاد بازخورد داد. شاهد: فهرست موارد باز و تصمیم دربارهٔ هر کدام.
  5. برد/باخت: قرارداد امضاشده یا دلیل باخت از فهرست بسته.

به شاهدها دقت کنید: همه چیزی هستند که همکار دیگر می‌تواند در رکورد ببیند. در جلسهٔ هفتگی، مدیر فقط کافی است ببیند «کدام رکورد شاهدش را ندارد». برای تبدیل نیازها به کارهای قابل‌پیگیری در تیم فنی هم می‌توانید همین منطق «شاهد» را در معیار پذیرش داستان کاربر به‌کار ببرید.

پیری و بازبینی

برای هر مرحله یک «حداکثر ماندن» تعیین کنید (عدد را داده خودتان تعیین می‌کند) و رکوردهای بیش از آن را در جلسهٔ هفتگی بازبینی کنید: یا قدم بعدی تاریخ‌دار می‌گیرند یا بسته (باخت) می‌شوند. فرصت بدون قدم بعدی تاریخ‌دار، پیش‌بینی را خراب می‌کند.

جلسهٔ هفتگی خط لوله

  • فرصت‌های بدون قدم بعدی را پیدا کنید.
  • فرصت‌هایی که از حداکثر ماندن گذشته‌اند را تعیین تکلیف کنید.
  • مرحله‌ای که شواهدش کم است برگردانده شود.
  • دلیل‌های باخت هفته را بخوانید و فهرست دلایل را اصلاح کنید.

اشتباهات رایج

  • نام‌گذاری مرحله بر اساس فعالیت فروشنده.
  • مرحله بدون شاهد خروج و بدون مالک.
  • احتمال‌های حدسی که هیچ‌وقت با داده بازنویسی نمی‌شوند.
  • مرحله‌های بسیار زیاد؛ فروشنده‌ها دیگر تفاوت‌ها را نمی‌فهمند.
  • دلیل باخت به‌صورت متن آزاد؛ قابل‌تحلیل نیست.
  • اختلاط سرنخ و فرصت در یک ستون‌بندی.

چک‌لیست

  1. هر مرحله شرط ورود، شاهد خروج و مالک دارد.
  2. مرحله‌ها وضعیت مشتری را نشان می‌دهند، نه فعالیت فروشنده.
  3. برد و باخت مرحله‌های جدا با خصیصهٔ الزامی (قرارداد/دلیل باخت) هستند.
  4. احتمال‌ها موقت‌اند و تاریخ بازنویسی با داده دارند.
  5. سرنخ‌ها قبل از ورود به خط لولهٔ فروش صلاحیت‌سنجی می‌شوند.
  6. برای هر مرحله حداکثر ماندن و بازبینی هفتگی تعریف شده است.
  7. هیچ نرخ تبدیل بدون منبع یا داده خودتان در گزارش نیامده است.

اگر وظایف تیم فروش را مثل داستان کاربر می‌نویسید، قالب 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 است. روی طراحی محصول، معماری و استقرار نرم‌افزار سفارشی کار می‌کند.

یادداشت‌های مرتبط

یادداشت‌های مرتبط

دسته‌بندی‌ها

خدمات مرتبط

از یادداشت تا پروژه

اگر با مسئله‌ای شبیه این روبه‌رو هستید، درباره‌ی شرایط پروژه‌تان با هم صحبت کنیم.

برای انتخاب مسیر فنی پروژه‌تان کمک می‌خواهید؟

از مسئله و محدودیت‌هایتان بگویید؛ اگر بتوانیم همراهی‌تان کنیم، برای گفت‌وگو هماهنگ می‌کنیم.

سهیل ابراهیم‌پور
یادداشت‌ها
نقشهٔ راه بک‌اند: مرحله‌ها، پروژه‌ها و مهارت‌های سنجش‌پذیر
نقشهٔ راه هوش مصنوعی: ML، LLM و مهندسی محصول
نقشهٔ راه فرانت‌اند: از HTML تا رابط آمادهٔ تولید
سیستم مناسب برای برنامه‌نویسی: حداقل‌ها و کنترل هزینه
نقشهٔ راه CTO: از تصمیم فنی تا ظرفیت‌سازی سازمان

مهندسی محصول

نقشهٔ راه بک‌اند: مرحله‌ها، پروژه‌ها و مهارت‌های سنجش‌پذیر

۲ آبان ۱۴۰۵

مهندسی محصول

نقشهٔ راه هوش مصنوعی: ML، LLM و مهندسی محصول

۲ آبان ۱۴۰۵

مهندسی محصول

نقشهٔ راه فرانت‌اند: از HTML تا رابط آمادهٔ تولید

۲ آبان ۱۴۰۵

مهندسی محصول

سیستم مناسب برای برنامه‌نویسی: حداقل‌ها و کنترل هزینه

۲ آبان ۱۴۰۵

مهندسی محصول

نقشهٔ راه CTO: از تصمیم فنی تا ظرفیت‌سازی سازمان

۲ آبان ۱۴۰۵
همه یادداشت‌ها294
معماری نرم‌افزار22
واژه‌نامه37
عملیات و استقرار90
مهندسی محصول117
راهنمای وب28
طراحی و ساخت محصول
توسعه فول‌استک
ممیزی مهندسی
مشاوره معماری
زیرساخت و استقرار
شروع گفتگو
ابزارهای رایگان
شروع گفتگو