تفاوت CRM و Help Desk در مدل داده

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

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

دو چرخه، نه یک چرخه

جدول بالا ترکیب مستندات و جمع‌بندی نویسنده است. نکتهٔ اصلی: CRM چرخهٔ رابطه است و پایان ندارد، تیکت چرخهٔ درخواست است و باید بسته شود.

نمونهٔ مدل‌های موجود

Odoo Helpdesk را اپلیکیشن پشتیبانی مبتنی بر تیکت معرفی می‌کند که در آن چند تیم می‌توانند هرکدام با pipeline و مرحله‌های قابل‌تنظیم کار کنند. دید تیم را می‌توان خصوصی یا عمومی (برای کاربران پورتال) تعیین کرد و مستندات مثال می‌آورد: تیم پشتیبانی عمومی در برابر تیم مالی که فقط برای کاربران دعوت‌شده دیده می‌شود. HubSpot در مدل خود «تیکت» را شیئی جدا از «معامله» نگه می‌دارد و هر دو می‌توانند به مخاطب یا شرکت مرتبط شوند؛ ارتباط‌ها دوطرفه‌اند. الگو روشن است: حساب/مشتری مشترک است، اما تیکت و فرصت دو شیء مستقل با مراحل مخصوص خودشان‌اند.

SLA: مهلت پاسخ در تیکتینگ

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

عددها صرفاً شکل نمونه‌اند؛ مقدار واقعی را بر اساس ظرفیت تیم و قول به مشتری بنویسید.

مدل داده: چه چیزی مشترک و چه چیزی جدا باشد

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

قاعدهٔ دید داده: همه‌چیز را همه نمی‌بینند. مثلاً Odoo نشان می‌دهد تیم مالی می‌تواند فقط برای کاربران دعوت‌شده دیده شود؛ همین منطق را برای قیمت و قرارداد (دید فروش) و محتوای تیکت‌های حساس (دید پشتیبانی) اجرا کنید.

مثال فرضی: یک مشتری، دو چرخه

شرکتی خدمات نرم‌افزاری می‌فروشد. مشتری A پس از یک ماه مذاکره قرارداد می‌بندد (چرخهٔ CRM: سرنخ ← فرصت ← برد). سه ماه بعد مشکلی در ورود به سامانه پیدا می‌کند و تیکت می‌زند (چرخهٔ تیکتینگ: ثبت ← بررسی ← حل ← بسته). نکته‌ها:

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

شاخص‌ها در هر چرخه

هدف عددی را از داده خودتان بعد از چند ماه اندازه‌گیری تعیین کنید؛ هیچ عدد «استاندارد صنعت» را بدون منبع قابل‌اتکا نپذیرید.

انتخاب بر اساس گردش‌کار

ملاک انتخاب ابزار، «گردش‌کار» است نه نام آن. سه پرسش: درخواست‌ها از کجا می‌آیند؟ چه کسی مالک است؟ چه چیزی نشان می‌دهد کار تمام شد؟

اتصال دو سیستم

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

وضعیت‌های روشن در رابط

در هر دو چرخه، کاربر باید همیشه بداند درخواست کجاست: «ثبت‌شده»، «در حال بررسی»، «منتظر مشتری»، «حل‌شده». حالت‌های خالی و خطا هم در رابط پشتیبانی مهم‌اند؛ مقالهٔ Empty state، Error state و Loading state الگوی آن‌ها را می‌گوید.

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

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

چک‌لیست

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

منابع و مراجع

• Helpdesk (Odoo 20.0 documentation) — Odoo S.A..
• Service level agreements (SLA) (Odoo 20.0) — Odoo S.A..
• How to use objects for business processes — HubSpot، 2026-10-02.
• Convert leads into opportunities (Odoo 20.0) — Odoo S.A..