اطلاعات مورد نیاز CRM: چه نگه داریم و چه نه

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

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

اشیای اصلی

HubSpot مدل داده را شیء، رکورد، ویژگی و ارتباط می‌داند و می‌گوید ارتباط‌ها دوطرفه‌اند. Salesforce و Odoo هم تقریباً همین ساختار را به شکل سرنخ، حساب (شرکت)، مخاطب و فرصت دارند. ساده‌ترین مدل مفید:

فعالیت رکوردی است که به بقیه وصل می‌شود، نه شیء مستقل از مشتری. اگر تیم شما نیاز به «محصول»، «قرارداد» یا «تیکت» دارد، آن‌ها را بعداً با ارتباط اضافه کنید، نه با فیلد متنی.

چرا سرنخ جدا از حساب و مخاطب؟

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

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

یکتایی و حذف تکرار

HubSpot مخاطب‌ها را بر پایهٔ ایمیل و شرکت‌ها را بر پایهٔ نام دامنه حذف تکرار می‌کند. در بازار ما ایمیل همیشه موجود نیست؛ کلید یکتایی را باید خودتان تعریف کنید (مثلاً شمارهٔ موبایل نرمال‌شده، شناسهٔ سازمانی داخلی یا کد مشتری). برای هر شیء بنویسید «کلید یکتایی چیست و اگر نبود چه می‌شود؟» و تبدیل ارقام فارسی و عربی و فاصله‌ها را نرمال کنید.

آزمون «چرا لازم است؟»

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

1. این فیلد کدام تصمیم یا کار را ممکن می‌کند؟ (نام ساده است؛ «تاریخ تولد» برای چه؟)
2. چه کسی آن را می‌خواند و چند وقت یک بار؟
3. اگر خالی بماند چه خراب می‌شود؟
4. مالک به‌روزرسانی آن کیست؟
5. تا کی نگه داشته می‌شود و چه کسی حذفش می‌کند؟

اگر پاسخ پرسش اول «شاید روزی لازم شد» است، فیلد را نگذارید. فیلدهای حساس (مثلاً اطلاعات هویتی، سلامت، مالی) را تا وقتی دلیل مشخص و مالک ندارند وارد CRM نکنید. تعیین حدود حقوقی نگه‌داری و رضایت در ایران را از منبع رسمی بپرسید.

حداقل مدل پیشنهادی

مثال فرضی: مسیر یک درخواست

فردی فرم «درخواست مشاوره» را پر می‌کند (مثال نویسنده):

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

در این مسیر هیچ فیلد «شاید لازم شد» وجود ندارد، و هر رکورد مالک و قدم بعدی دارد.

فعالیت‌ها: ثبت کنید، ولی چه چیزی؟

فعالیت باید نتیجه و قدم بعدی را ثبت کند، نه رونوشت کامل مکالمه. الگوی کوتاه: نوع، تاریخ، خلاصهٔ دو خطی، نتیجه، وظیفهٔ بعدی با مسئول و تاریخ. ثبت متن کامل پیام‌ها و تماس‌ها بدون دلیل، حجم داده شخصی را بالا می‌برد و جست‌وجو را سخت می‌کند.

دسترسی و امنیت

CRM پر از اطلاعات تماس و قیمت است. دو قاعده: نقش‌ها را حداقلی تعریف کنید (فروشنده فقط رکوردهای خودش یا تیمش را ببیند) و ارتباط را رمزگذاری‌شده (HTTPS) نگه دارید؛ برای مفهوم ساده، SSL و HTTPS چیست را ببینید. صادرات انبوه داده را به نقش مدیر محدود کنید و ثبت لاگ بگذارید. جزئیات امنیتی تخصصی‌تر را از متخصص بگیرید.

ورود داده از فرم‌ها

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

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

• ریختن سرنخ و مشتری در یک فهرست.
• فیلد آزاد «توضیحات» برای همه‌چیز.
• جمع‌آوری اطلاعات «شاید لازم شد».
• نداشتن کلید یکتایی و در نتیجه مخاطب‌های تکراری.
• نداشتن مالک برای هر رکورد و هر فیلد.
• دسترسی بیش از نیاز و صادرات بی‌ثبت.

چک‌لیست

1. اشیای سرنخ، حساب، مخاطب، فرصت و فعالیت با ارتباط‌ها تعریف شده‌اند.
2. کلید یکتایی هر شیء و قاعدهٔ نرمال‌سازی نوشته شده است.
3. هر فیلد جواب «چرا لازم است؟» و مالک دارد.
4. فیلدهای حساس دلیل و مالک دارند، وگرنه حذف شده‌اند.
5. فعالیت‌ها نتیجه و قدم بعدی ثبت می‌کنند، نه متن کامل.
6. نقش‌ها و صادرات داده محدود و ثبت‌شده است.
7. فرم‌های ورودی فقط فیلدهای الزامی را می‌پرسند.
8. الزامات داده‌های شخصی و حریم خصوصی ایران از منبع رسمی روز و مشاور حقوقی بررسی شده است.

منابع و مراجع

• How to use objects for business processes — HubSpot، 2026-10-02.
• Convert leads into opportunities (Odoo 20.0) — Odoo S.A..
• Convert Qualified Leads — Salesforce.
• Regulation (EU) 2016/679 (GDPR), Article 5(1)(c) — EUR-Lex / European Union، 2016.