پرونده‌ی مشتری در CRM: چه اطلاعاتی ثبت کنیم و چطور تمیز نگهش داریم؟

پرونده‌ی مشتری در CRM یعنی چه؟

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

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

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

پنج لایه‌ی پرونده: سازمان، شخص، مکالمه، معامله و سند

در فروشِ سازمانی (B2B) پرونده‌ی مشتری یک برگه نیست؛ پنج لایه است که روی هم سوار می‌شوند. قاطی‌کردنِ این لایه‌ها ریشه‌ی بیشترِ دیتابیس‌های به‌هم‌ریخته است.

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

مهم‌ترین تصمیمِ این ساختار جداکردنِ سازمان از شخص است. وقتی مدیرِ خریدِ یک بیمارستان عوض می‌شود، نباید نام و شماره‌ی نفرِ قبلی را در پرونده پاک کنید و نفرِ تازه را جایش بنویسید؛ نفرِ تازه یک رابطِ دیگر زیرِ همان سازمان است، و همه‌ی سابقه‌ی نفرِ قبلی سرِ جایش می‌ماند. اشتباهِ رایجِ مقابل هم این است که نامِ سازمان داخلِ نامِ شخص نوشته شود («آقای رضایی - بیمارستان مهر»). از آن لحظه نه می‌شود تعدادِ سازمان‌ها را شمرد، نه دو رابطِ یک سازمان را کنارِ هم دید.

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

حداقلِ اطلاعاتِ لازم، و فیلدهایی که فقط شلوغ می‌کنند

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

در طرفِ مقابل، چهار دسته فیلد تقریباً همیشه فقط شلوغ می‌کنند:

1. فیلدی که هیچ‌کس نمی‌خواند. «فکس»، «علاقه‌مندی‌ها»، «توضیحات ۲». اگر در هیچ گزارش یا فیلتری به کار نمی‌آید، حذفش کنید یا در یک کادرِ توضیحاتِ آزاد ادغامش کنید.
2. فیلدی که سیستم باید خودش حساب کند. «تاریخِ آخرین تماس»، «تعدادِ خرید»، «مرحله‌ی فروش». این‌ها از روی مکالمه‌ها و اسناد معلوم می‌شوند؛ اگر دستی تایپ شوند، از فردا کهنه‌اند و هیچ‌کس نمی‌داند کدام عدد درست است.
3. متنِ آزاد برای چیزی که باید فهرست باشد. شهر، سمت، نوعِ سازمان. وقتی تایپی‌اند، «تهران»، «تهرن» و «Tehran» سه شهرِ جدا می‌شوند و هیچ فیلتری درست کار نمی‌کند.
4. فیلدِ بی‌تعریف. «اولویت» یا «درجه‌ی مشتری» بدونِ اینکه کسی نوشته باشد «بالا» یعنی چه. هر کارشناس معنیِ خودش را می‌گذارد و گزارشِ حاصل بی‌معنی است.

یک قاعده‌ی کوچک ولی مهم: خالی با صفر فرق دارد. خالی یعنی «نمی‌دانیم» و صفر یعنی «می‌دانیم که هیچ». اگر شمار کارکنان یا ظرفیتِ یک مرکز را نمی‌دانید، خالی بگذارید؛ صفرِ ساختگی بعداً در میانگین‌ها و فیلترها مثلِ داده‌ی واقعی حساب می‌شود.

فیلدهای اجباری: چرا اجبارِ زیاد ورودِ داده را می‌خواباند

وسوسه‌ی هر مدیری این است که برای داشتنِ داده‌ی کامل، نیمی از فرم را اجباری کند. نتیجه معمولاً برعکس است. کارشناسی که وسطِ یک تماسِ تلفنی سی ثانیه برای ثبتِ یک نفر وقت دارد و فرم از او شناسه‌ی ملی و کدِ پستی می‌خواهد، یکی از این سه کار را می‌کند: ثبت را به «بعداً» می‌سپارد و هیچ‌وقت انجامش نمی‌دهد، شماره را در دفترچه یا اکسلِ شخصی‌اش می‌نویسد، یا فیلد را با مقدارِ ساختگی پر می‌کند — «-»، «۰۰۰۰»، «نامشخص».

مقدارِ ساختگی از خالی بدتر است، چون شبیهِ داده است. فیلدِ خالی دستِ‌کم صادقانه می‌گوید «نمی‌دانیم»؛ اما ده پرونده با کدِ پستیِ «۱۱۱۱۱۱۱۱۱۱» در گزارش‌ها کامل به نظر می‌رسند و هیچ‌کس به فکرِ تکمیلشان نمی‌افتد. چند نشانه می‌گوید اجبار زیاد شده است: پرونده‌های تازه پر از خط‌تیره و صفرند، تعدادِ ثبت‌ها بعد از اجباری‌کردنِ یک فیلد ناگهان افتاده، و کارشناس‌ها هنوز فهرستِ خودشان را بیرون از نرم‌افزار نگه می‌دارند.

سه قاعده برای اجباری‌کردن:

1. فقط آنچه برای پیداکردن، تماس‌گرفتن و سپردنِ پرونده به یک نفر لازم است اجباری باشد: نامِ سازمان، نام یا نام خانوادگیِ شخص، و کارشناسِ مسئول؛ موبایل هم اگر کارِ تیم با تلفن است.
2. بقیه در طولِ رابطه کامل شوند. سمت و شهر در تماسِ دوم، مشخصاتِ حقوقی هنگامِ پیش‌فاکتور. هر اطلاعات را در لحظه‌ای بخواهید که واقعاً به آن نیاز دارید.
3. قاعده‌ی تازه پرونده‌ی قدیمی را قفل نکند. اگر امروز «سمت» اجباری شد، پرونده‌ای که سالِ پیش بی‌سمت ثبت شده نباید با یک ویرایشِ ساده‌ی شماره‌تلفن گیر کند؛ اجبار برای ثبتِ تازه است.

و یک هشدار: فیلدی را اجباری نکنید که فهرستش هنوز تعریف نشده. اگر «شهر» اجباری شود ولی فهرستِ شهرها خالی باشد، هیچ‌کس نمی‌تواند مشتریِ تازه ثبت کند.

برچسب، فهرست و مرحله: سه نوع داده‌ی توصیفی

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

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

اینکه با این سه نوع داده مشتریان را چطور بخش‌بندی کنید و هر بخش چه ریتمِ پیگیری‌ای بگیرد، موضوعِ مقاله‌ی بخش‌بندی مشتریان است. این‌جا فقط یک نکته: برچسبی که تعریف ندارد، مثلِ فیلدِ بی‌تعریف، بعد از شش ماه ده معنیِ مختلف پیدا می‌کند. برای هر برچسب یک جمله بنویسید که دقیقاً یعنی چه.

صاحبِ پرونده: کارشناسِ اصلی، کارشناسِ اضافی و رابطِ همکار

پرونده‌ای که صاحب ندارد، پیگیری نمی‌شود؛ پرونده‌ای که سه صاحبِ هم‌وزن دارد هم معمولاً پیگیری نمی‌شود، چون هر کس فکر می‌کند دیگری زنگ زده. برای همین بیشترِ تیم‌های فروش به سه مفهوم می‌رسند:

• کارشناسِ اصلی: یک نفر که مسئولِ این مشتری است. هشدارِ «مدت‌هاست کسی سراغش نرفته» درباره‌ی مشتریانِ اوست و گزارشِ فروش به نامِ او نوشته می‌شود.
• کارشناسِ اضافی: همکارانی که به‌خاطرِ کارِ تیمی — کارشناسِ فنی، پشتیبان، مدیرِ منطقه — باید پرونده را کامل ببینند و برایش کار ثبت کنند، بی‌آنکه مسئولیتِ اصلی جابه‌جا شود.
• یک سازمان، یک مسئول: سازمان و اشخاصش بهتر است صاحبِ یکسان داشته باشند؛ وگرنه دو کارشناس با دو رابطِ یک بیمارستان دو قیمتِ متفاوت می‌دهند. استثنای رایجش رابطی است که همکارِ دیگری می‌شناسد، در سازمانی که مالِ کارشناسِ دیگری است: او می‌تواند همان یک نفر را ثبت و پیگیری کند، ولی کلِ سازمان و اسنادش با این کار به او نمی‌رسد.

جابه‌جاییِ صاحبِ پرونده هم باید یک کارِ گروهی باشد، نه پرونده‌به‌پرونده: وقتی کارشناسی از شرکت می‌رود یا منطقه‌ها از نو تقسیم می‌شوند، مدیر باید بتواند همه‌ی مشتریانِ یک نفر یا یک استان را یکجا به نفرِ دیگر بسپارد. مبناهای تقسیم و حلِ تعارضِ دو کارشناس را در تقسیم مشتریان بین کارشناسان فروش گفته‌ایم؛ اینکه در روزِ رفتنِ یک کارشناس دقیقاً چه چیزهایی را باید بست و چه کسی چه چیزی را ببیند، در امنیت اطلاعات مشتریان آمده است.

تاریخچه و حذفِ نرم

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

عادتِ دوم حذفِ واقعی است. پرونده‌ای که اشتباهی حذف شده — یا پرونده‌ی تکراری‌ای که به‌جای یکی‌شدن پاک شده — همه‌ی مکالمه‌ها و پیوندهایش را با خودش می‌برد. نرم‌افزارِ درست حذفِ نرم دارد: رکورد از فهرست‌ها بیرون می‌رود ولی در دیتابیس می‌ماند، و هر کاری که برگشت ندارد — مثلِ یکی‌کردنِ دو پرونده — ردی از خودش می‌گذارد که بگوید چه کسی، کِی و چه چیزی را جابه‌جا کرده است.

داده‌ی تمیز: پیداکردن و یکی‌کردنِ تکراری‌ها

تکراری‌ها بی‌سروصدا جمع می‌شوند و هر کدام یک گزارش را خراب می‌کنند: مشتری‌ای که دو پرونده دارد در یکی «بی‌پیگیری» دیده می‌شود، در شمارشِ مشتریان دو بار می‌آید، و شاید دو کارشناس هم دارد. منشأشان معمولاً یکی از این‌هاست:

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

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

وقتی تکراری پیدا شد، یکی‌کردنش چهار قاعده دارد:

1. پاک نکنید، یکی کنید. مکالمه‌ها، معامله‌ها و اسنادِ پرونده‌ی تکراری باید به پرونده‌ی ماندنی منتقل شوند.
2. پرونده‌ی پُرتر بماند. معمولاً پرونده‌ای که مکالمه‌ی بیشتری دارد پرونده‌ی اصلی است.
3. مقدارِ متفاوت گم نشود. اگر دو پرونده دو شماره‌ی متفاوت دارند، شماره‌ی دوم به راه‌های ارتباطیِ پرونده‌ی ماندنی برود؛ اگر دو نشانیِ متفاوت دارند، دومی جایی یادداشت شود.
4. اول پیش‌نمایش، بعد اجرا. پیش از یکی‌کردن ببینید چه چیزی کجا می‌رود؛ و اگر دو پرونده دو شناسه‌ی ملیِ متفاوت دارند، احتمالاً اصلاً تکراری نیستند.

پرونده‌ی مشتری در ملل CRM

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

• فیلدهای سازمان: «نام سازمان» (همیشه الزامی)، «گروه»، «نوع مالکیت»، «شناسه ملی / کد ملی»، «کد اقتصادی»، «شماره ثبت»، «کد پستی»، «تلفن»، «تلفن دوم»، «آدرس» و «توضیحات سازمان» برای نکته‌های ثابت درباره‌ی خودِ سازمان — نه گزارشِ تماس. دو تیکِ «این سازمان مشتری ماست» و «این سازمان تامین‌کننده ماست» هم هست. «کد پستی»، «تلفن»، «تلفن دوم» و «آدرس» در کارتِ «مجموعه‌های نشانی» می‌نشینند و با «+ افزودن مجموعه‌ی نشانی» نشانی‌های دیگرِ همان سازمان (مثلاً انبار یا محلِ ارسالِ کالا) هم ثبت می‌شود؛ در ویرایش، کارتِ «شماره‌ها و راه‌های تماسِ سازمان» شماره، ایمیل و وب‌سایتِ بیشتر را نگه می‌دارد. دکمه‌ی «اطلاعات مالیاتی» فیلدهای مودیان را باز می‌کند و کارتِ «اعتبار و تخفیف» (لیست سیاه، سقف اعتبار، تخفیف پیش‌فرض) را فقط ادمینِ شرکت عوض می‌کند. در فیلدِ «تعداد تخت فعال» ی مراکزِ درمانی همان قاعده‌ی بالا رعایت شده: «۰» یعنی واقعاً صفر و خالی یعنی نمی‌دانیم.
• فیلدهای شخص: «کارشناس فروش مربوطه»، «کارشناس‌های فروش اضافی (اختیاری)»، «نام مشتری»، «نام خانوادگی مشتری»، «شماره موبایل»، «وضعیت رفتاری»، «کشور»، «استان»، «شهر»، «آدرس»، «سمت در سازمان»، «تاریخ تولد»، «جنسیت»، «معرف»، «نحوه آشنایی»، «توضیحات» و شماره‌های اضافه با دکمه‌ی «افزودن». دکمه‌ی ثبت «ذخیره اطلاعات» و دکمه‌ی ذخیره‌ی تغییرات «ویرایش اطلاعات» است.
• فیلدهای اجباری را هر شرکت خودش انتخاب می‌کند: ادمینِ شرکت در «تنظیمات» ← کارتِ «فیلدهای الزامیِ معرفی سازمان و شخص» تیک می‌زند؛ این تیک‌ها فقط برای ثبتِ تازه‌اند. «کارشناس فروش مربوطه» ولی در ویرایش هم لازم است: پرونده‌ی قدیمیِ بی‌کارشناس تا کارشناس نگیرد ویرایش نمی‌شود. جزئیات و پیام‌ها را در راهنمای ثبت مشتری آورده‌ایم.
• برچسب و مرحله جدا از هم: «وضعیت رفتاری» (مثلِ «خوش‌قول»، «بدقول»، «خوش‌اخلاق») چندتایی و دستی است و فهرستش در «تنظیمات» مدیریت می‌شود. مرحله‌ی فروش (کادرهای بالای فهرستِ مشتریان) از روی رویدادها عوض می‌شود، نه با تیکِ دستی: ثبتِ شخص زیرِ سازمانی که «این سازمان مشتری ماست» خورده، اولین مکالمه، تبدیلِ پیش‌فاکتور به فاکتور، و پاسخِ بررسیِ رضایت. «وفادار» مرحله نیست؛ نشانی است که کنارِ مرحله می‌نشیند و آن را عوض نمی‌کند. این نشان برای مشتریِ «راضی» با دکمه‌ی «علامت‌گذاری به‌عنوان مشتری وفادار» زده می‌شود، یا وقتی مشتری معرفِ مشتریِ تازه‌ای شود خودکار می‌آید. تنها جایی که وضعیت را دستی انتخاب می‌کنید، ادغامِ دو سازمانی است که هر دو در قیف جلو رفته‌اند.
• صاحبِ پرونده: «کارشناس فروش مربوطه» برای هر شخص، در ثبت و ویرایش، الزامی است و فقط ادمینِ شرکت عوضش می‌کند؛ «کارشناس‌های فروش اضافی» یعنی چند نفر هم‌زمان به آن مشتری دسترسیِ کامل دارند. کارشناسِ عادی فقط مشتریانِ خودش را می‌بیند. سازمان و اشخاصش یک مسئول دارند: اگر ادمین کارشناسِ یکی از اشخاص را عوض کند، «مسئولِ سازمان» و بقیه‌ی اشخاصِ همان سازمان هم همان همکار می‌شوند — جز «شخصِ مهمان» (بندِ بعد): عوض‌شدنِ کارشناسِ او سازمان را جابه‌جا نمی‌کند، و خودش هم با سازمان جابه‌جا نمی‌شود مگر کارشناسش همان مسئولِ قبلیِ سازمان باشد — و کارشناس‌های اضافی دست نمی‌خورند.
• شخصِ مهمان: اگر همکارِ غیرادمین شخصی را زیرِ سازمانی ثبت کند که مالِ او نیست، پیش از ذخیره نوشته‌ی نارنجیِ «این سازمان مالِ شما نیست؛ این شخص «مهمان» ثبت می‌شود …» را می‌بیند. او همان شخص و مکالماتش را می‌بیند، ولی سازمان در «لیست سازمان ها» ی او نمی‌آید و بقیه‌ی پیش‌فاکتورها و فاکتورهای آن سازمان برایش بسته است. فقط ادمینِ شرکت تیکِ «شخصِ مهمان در این سازمان» را می‌بیند و می‌تواند بردارد.
• واگذاریِ گروهی: «پخش استانی مشتریان» (فقط ادمین) مشتریانِ یک استان یا شهر، یا همه‌ی مشتریانِ یک همکار، را یکجا و پس از یک کادرِ تأیید به همکارِ دیگر می‌سپارد. این کار برگشت ندارد جز با واگذاریِ دوباره، و سابقه‌ی «قبلاً مالِ که بود» نگه داشته نمی‌شود؛ پیش از تأیید ببینید مشتریانِ آن محدوده الان مالِ چه کسانی‌اند.
• تاریخچه و حذف: مکالمه‌های هر شخص بر اساسِ «تاریخ پیگیری» مرتب‌اند (جدیدترین بالا) و صفحه‌ی سازمانی که مکالمه دارد، کارتِ «مکالمه‌های این سازمان» را دارد که مکالمه‌های همه‌ی رابط‌هایش را کنارِ هم نشان می‌دهد. حذف در بیشترِ جاها نرم است: پرونده با «حذف اطلاعات» از فهرست بیرون می‌رود ولی در دیتابیس می‌ماند. ادمین می‌تواند برای هر همکار اجازه‌ی «حذف» را روی مشتریان ببندد.
• تکراری‌ها: سازمانی با نامِ دقیقاً یکسان پیامِ «نام سازمان تکراری ست!» می‌گیرد؛ نوشتارِ متفاوت (مثلاً با کسره یا پسوندِ «(خصوصی)») گرفته نمی‌شود، پس پیش از ثبت در کادرِ «...جستجوی نام سازمان» بالای کشوی «انتخاب نام شرکت/سازمان» بخشی از نام را جست‌وجو کنید. این کشو نامِ همه‌ی سازمان‌های شرکت را نشان می‌دهد تا کسی سازمانِ موجود را دوباره نسازد. ستونِ «مکالمه» در فهرستِ مشتریان کمک می‌کند بینِ دو پرونده‌ی هم‌نام، پرونده‌ی اصلی را پیدا کنید. ردیف‌هایی با برچسبِ «رابط ثبت نشده» تکراری نیستند: سازمانی که با تیکِ «این سازمان مشتری ماست» و بی‌مخاطب ثبت شود، یک رابطِ موقت می‌گیرد تا در قیف دیده شود.
• یکی‌کردن: ادمینِ شرکت در ویرایشِ پرونده کارت‌های «ادغام با رابطِ دیگر» و «ادغام با سازمانِ دیگر» را دارد. «پیش‌نمایش» می‌گوید چه چیزهایی (مکالمه، رابط، معامله، فاکتور) منتقل می‌شود و کدام مقدارها متفاوت‌اند؛ مقدارِ پرِ مقصد می‌ماند و مقدارِ متفاوت (با تیکِ تأیید) در توضیحاتِ مقصد ثبت می‌شود. در ادغامِ دو رابط، موبایلِ دوم به شماره‌های اضافه‌ی پرونده‌ی مقصد (همان ردیفِ «نوع تلفن» / «شماره تماس جدید» با دکمه‌ی «افزودن») می‌رود و کارشناس‌های پرونده‌ی تکراری — جز در حالتِ شخصِ مهمان — «کارشناسِ فروشِ اضافی» ی مقصد می‌شوند تا دسترسیِ کسی قطع نشود. دو رابط با دو کدِ ملیِ متفاوت، و دو سازمان با دو شناسه‌ی ملیِ متفاوت، یکی نمی‌شوند. برای تأیید باید نامِ پرونده را بنویسید و «ادغام شود» را بزنید؛ برگشت ندارد ولی چیزی پاک نمی‌شود و پرونده‌ی رفته پسوندِ «(ادغام‌شده در #شناسه)» می‌گیرد. قدم‌به‌قدمِ این کار در راهنمای ادغام سازمان‌ها و اشخاصِ تکراری آمده است.
• فهرست‌های یکدست: سمت‌ها و نوع‌های مالکیتِ تکراری با «یکی‌کردن با موردِ دیگر» در «تنظیمات» یکی می‌شوند. یکی‌کردنِ سمت ثبت می‌شود (چه کسی، کِی، چند مخاطب)، ولی یکی‌کردنِ نوع مالکیت برگشت ندارد و جایی ثبت نمی‌شود. استان‌ها و شهرهایی که فقط در فاصله، نیم‌فاصله، «ي/ك» ی عربی و مانندِ این‌ها فرق دارند با هر بار «ورودِ گروهی از اکسل» در ردیفِ «مکان» ی کارتِ «فهرست‌های پایه» یکی می‌شوند؛ مشتریان و سازمان‌هایشان به ردیفِ باقی‌مانده منتقل می‌شوند. املای متفاوت (مثلِ «کهکیلویه» و «کهگیلویه») خودکار یکی نمی‌شود و فقط در پیش‌نمایش با برچسبِ «نامِ تازه‌ی شبیه به موجود» هشدار می‌گیرد.

اگر پرونده‌هایتان امروز در اکسل یا نرم‌افزارِ دیگری است، پیش از ورود یک بار تکراری‌ها را پیدا کنید؛ بقیه‌ی راهنماها هم در فهرست مقالات هستند.

پرسش‌های متداول درباره‌ی پرونده‌ی مشتری