یک فایل اکسل با چند برگه، فهرستی از شمارههای قدیمی، یادداشتهای پراکنده کارشناسان و پروندههایی که بخشی از اطلاعاتشان ناقص است؛ این معمولاً نقطه شروع مهاجرت داده به CRM است. مسئله فقط جابهجا کردن ردیفها نیست. باید تصمیم بگیرید چه چیزی ارزش ورود دارد، چه دادهای باید اصلاح شود، چه کسی نتیجه را بررسی کند و در صورت خطا چگونه به نسخه قبلی برگردید. در این نوشته، مسیر انتقال اطلاعات را به چند مرحله روشن تقسیم میکنیم تا مدیر کسبوکار و ادمین CRM بتوانند بدون آشفتگی پیش بروند.
پیش از انتقال، نقشه داده را روی کاغذ بیاورید
قبل از باز کردن فایل خروجی یا ساختن قالب ورود، فهرست کنید که چه اطلاعاتی در اختیار دارید. اطلاعات فروش ممکن است در اکسل، نرمافزار حسابداری، پیامرسان، دفترچه تلفن، ایمیل یا حتی یادداشت شخصی کارشناسان پخش شده باشد. اگر این منابع را نشناسید، بخشی از سابقه مشتری بیرون از فرایند باقی میماند و بعداً معلوم نیست کدام نسخه معتبر است.
برای هر منبع، این موارد را بنویسید: نام منبع و محل نگهداری اطلاعات، مالک یا مسئول پاسخگویی درباره داده، نوع اطلاعات موجود، بازه زمانی اطلاعات، قالب فایل یا روش استخراج، میزان کامل بودن اطلاعات، احتمال وجود داده تکراری و حساسیت اطلاعات و گروههایی که باید آن را ببینند.
این فهرست، نقشه اولیه انتقال است. لازم نیست از همان ابتدا تمام ستونها را به قالب نهایی تبدیل کنید. ابتدا ببینید هر منبع چه چیزی دارد. یک فایل ممکن است فهرست شرکتها را نگه دارد، فایل دیگر شماره تماس افراد را، و فایل سوم وضعیت پیگیری را. ترکیب این منابع بدون بررسی، میتواند یک مشتری را چند بار وارد سیستم کند یا سابقه یک فرصت را به پرونده اشتباه وصل کند.
دادهها را به چند گروه جدا تقسیم کنید: اطلاعات پایه مشتری، مانند نام شرکت، نام فرد، شماره تماس و نشانی؛ اطلاعات فرصت فروش، مانند موضوع درخواست، ارزش تقریبی، مرحله و مسئول پیگیری؛ سابقه ارتباط، مانند تماسها، جلسهها، پیامها و یادداشتها؛ کارهای باز، مانند پیگیری وعدهدادهشده، موعد تماس یا ارسال مدرک؛ و اطلاعات مدیریتی، مانند منبع ورود، منطقه، صنعت یا دسته مشتری.
این تفکیک کمک میکند بفهمید هر داده در سامانه جدید کجا قرار میگیرد. نام شرکت با یادداشت تماس یکسان نیست و نباید هر دو را در یک ستون وارد کرد. همین اشتباه ساده بعداً گزارشگیری و پیگیری را دشوار میکند.
در کلید، پرونده مشتری میتواند اطلاعات مشتری و فرصت فروش، مکالمات و فعالیتها و اقدام بعدی را کنار هم نگه دارد. پس هنگام بررسی منابع قدیمی، فقط به فهرست نامها اکتفا نکنید. ببینید برای هر مشتری، ادامه مسیر فروش هم وجود دارد یا نه. اگر یک فایل فقط شماره تلفن دارد، نباید آن را با پروندهای که سابقه مذاکره و اقدام بعدی دارد همارز در نظر بگیرید.
هر دادهای ارزش ورود به سامانه را ندارد
انتقال همه اطلاعات قدیمی، تصمیم محتاطانهای به نظر میرسد؛ اما همیشه نتیجه خوبی ندارد. دادههای بسیار قدیمی، ناقص یا بیصاحب میتوانند جستوجو، گزارشگیری و کار روزانه تیم را شلوغ کنند. معیار انتخاب باید به کاربرد آینده مربوط باشد، نه فقط به اینکه دادهای وجود دارد.
برای هر مجموعه اطلاعات این پرسشها را پاسخ دهید: این داده در پیگیری آینده استفاده میشود؟ مالک یا مسئول اصلاح آن مشخص است؟ اطلاعات به اندازهای کامل هست که تصمیمی بر اساس آن گرفته شود؟ زمان آخرین فعالیت یا بهروزرسانی معلوم است؟ ورود آن به گزارشهای مدیریتی کمک میکند؟ نگهداری آن با سیاست دسترسی و حریم خصوصی کسبوکار سازگار است؟ آیا همان اطلاعات در منبع دیگری وجود دارد؟
گروه اول، قابل انتقال فوری: اطلاعاتی که کامل، قابل شناسایی و مرتبط با کار جاری هستند. مشتریان فعال، فرصتهای باز و پیگیریهای موعددار معمولاً در این گروه قرار میگیرند.
گروه دوم، نیازمند بررسی: اطلاعاتی که بخشی از آنها کامل است، اما مالک، وضعیت یا ارتباطشان با مشتری روشن نیست. این گروه را قبل از انتقال نهایی به مسئول مربوط بسپارید.
گروه سوم، خارج از انتقال فعلی: دادههایی که قدیمی، تکراری، بیمنبع یا فاقد کاربرد مشخص هستند. نگهداشتن نسخه پشتیبان از آنها با وارد کردنشان به محیط کاری روزانه فرق دارد.
مثلاً اگر شرکتی 5 سال سابقه استعلام قیمت دارد، نباید همه استعلامها را بدون توجه به وضعیت فعلی وارد کند. ابتدا مشتریان فعال، فرصتهای باز و قراردادهایی را که هنوز تعهد اجرایی دارند جدا کنید. سوابق قدیمی را میتوان در آرشیو نگه داشت تا در صورت نیاز بررسی شوند، اما قرار نیست همه آنها در فهرست کار روزانه تیم دیده شوند.
در این مرحله، مالکیت داده را هم مشخص کنید. مدیر فروش درباره فرصتهای باز نظر میدهد، واحد پشتیبانی درباره وضعیت مشتریان فعال اطلاعات دقیقتری دارد و ادمین CRM مسئول آمادهسازی قالب و کنترل ساختاری دادههاست. تقسیم این نقشها باید پیش از ورود اطلاعات روشن شود. برای طراحی این تقسیم کار، راهنمای مسئولیت کیفیت داده مشتری میتواند چارچوب مناسبی در اختیار تیم بگذارد.
پاکسازی را از نام، شماره و تکرارها شروع کنید
پاکسازی داده را به بعد از انتقال موکول نکنید. هرچه اطلاعات نامرتبتر وارد سامانه شود، اصلاح آن سختتر میشود؛ چون باید تشخیص دهید خطا از منبع اصلی آمده یا هنگام ورود ایجاد شده است.
پاکسازی را از سه بخش شروع کنید.
نامها را به یک الگوی ثابت برسانید
نام شرکتها ممکن است با شکلهای مختلف ثبت شده باشد: «شرکت نمونه»، «نمونه»، «نمونه بازرگانی» یا نام کوتاهشدهای که فقط یک کارشناس آن را میشناسد. پیش از تغییر نامها، قانون مشخصی بنویسید. برای نمونه:
- نام رسمی شرکت در فیلد نام سازمان ثبت شود.
- نام کوتاه یا نام رایج در فیلد جداگانه قرار بگیرد.
- نام فرد با نام سازمان در یک ستون ترکیب نشود.
- فاصلههای اضافی و نشانههای بیکاربرد حذف شوند.
- حروف متفاوت، شکل نوشتاری یکسانی داشته باشند.
این قانون را روی چند ردیف آزمایش کنید. اصلاح گروهی بدون بررسی نمونه ممکن است بخشی از نام را حذف کند یا دو شرکت متفاوت را شبیه هم نشان دهد.
شمارهها را قابل جستوجو کنید
شماره تلفنها معمولاً با فاصله، خط تیره، پرانتز یا پیششمارههای متفاوت ذخیره شدهاند. یک قالب واحد انتخاب کنید و همه شمارهها را به همان شکل نزدیک کنید. شماره ثابت شرکت، شماره همراه فرد و شماره داخلی را در ستونهای جدا قرار دهید.
اگر یک شماره برای چند نفر ثبت شده است، آن را بهسرعت به یک نفر نسبت ندهید. ابتدا مشخص کنید آیا افراد یک شرکت هستند، آیا یک شماره عمومی دارند یا یکی از رکوردها اشتباه ثبت شده است. دادهای که در این مرحله نامطمئن است، باید علامتگذاری شود تا صاحب آن بررسی کند.
رکوردهای تکراری را پیدا کنید
برای تشخیص تکراریها فقط به نام نگاه نکنید. ترکیبی از نام سازمان، شماره تلفن، نشانی ایمیل و نام فرد را بررسی کنید. دو شرکت ممکن است نام مشابه داشته باشند و یک شرکت هم ممکن است چند شماره تماس معتبر داشته باشد.
روند پیشنهادی این است: رکوردهای مشکوک را با یک برچسب جدا کنید؛ منبع و تاریخ آخرین بهروزرسانی هر رکورد را ببینید؛ رکورد اصلی را با نظر مالک داده انتخاب کنید؛ اطلاعات مفید رکوردهای دیگر را به پرونده اصلی منتقل کنید؛ پس از کنترل، رکوردهای اضافی را حذف یا بایگانی کنید؛ و نتیجه ادغام را در یک فهرست ثبت کنید.
حذف تکراریها بدون ثبت تصمیم، بعداً اعتماد تیم به داده را کم میکند. بهتر است بدانید چه رکوردهایی ادغام شدهاند و اگر لازم شد، بتوانید دلیل تصمیم را توضیح دهید. در راهنمای جلوگیری از رکورد تکراری، جستوجو، بررسی و بازبینی این فرایند از هم جدا شدهاند.
انتقال آزمایشی را با یک گروه کوچک اجرا کنید
بهجای ورود همه دادهها، یک گروه کوچک و نماینده انتخاب کنید. این گروه باید چند نوع وضعیت را نشان دهد: یک مشتری کامل، یک مشتری ناقص، یک فرصت باز، یک سابقه ارتباط و یک رکوردی که احتمال تکراری بودن دارد.
انتقال آزمایشی باید پاسخ چند سؤال را روشن کند: ستونهای منبع به فیلدهای مقصد درست وصل شدهاند؟ تاریخها، شمارهها و مقدارهای متنی درست نمایش داده میشوند؟ رکوردهای مشتری و فرصت به هم ارتباط دارند؟ فعالیتها و اقدامهای بعدی در جای مناسب قرار گرفتهاند؟ سطح دسترسی کاربران با انتظار مدیر سازگار است؟ گزارشها اطلاعات واردشده را درست میخوانند؟ رکوردهای بدون مالک یا بدون موعد مشخص دیده میشوند؟
برای کنترل نتیجه، فقط به یک نگاه کلی اکتفا نکنید. چند رکورد را از ابتدا تا انتها دنبال کنید. مثلاً یک شرکت را باز کنید، اطلاعات تماسش را بررسی کنید، فرصت مرتبط را ببینید، آخرین مکالمه را بخوانید و اقدام بعدی را کنترل کنید. اگر این مسیر برای یک رکورد کامل نیست، انتقال گسترده مشکل را بیشتر میکند.
در نمونهای از کار با کلید، مدیر میتواند بررسی کند که یک فرصت فروش پس از ورود، مسئول مشخص، مرحله روشن و اقدام بعدی دارد یا نه. اگر یادداشت تماس وارد شده اما موعد پیگیری منتقل نشده باشد، اطلاعات ظاهراً سالم است، ولی کار روزانه تیم ناقص خواهد بود. همین تفاوت میان «ورود رکورد» و «آماده بودن پرونده برای کار» باید در آزمون دیده شود.
نتیجه آزمایش را در یک جدول ساده ثبت کنید:
| مورد بررسی | نتیجه مورد انتظار | نتیجه واقعی | تصمیم |
|---|---|---|---|
| نام سازمان | یکدست و قابل جستوجو | نامها با دو قالب وارد شدهاند | اصلاح قالب |
| شماره تماس | یک شماره در فیلد درست | چند شماره در یک ستون هستند | تفکیک شمارهها |
| فرصت فروش | مرتبط با مشتری | بخشی بدون ارتباط مانده است | بررسی اتصال |
| اقدام بعدی | دارای مسئول و موعد | موعد منتقل نشده است | تکمیل قالب |
اگر خطا تکرار میشود، بهجای اصلاح دستی تکتک رکوردها، علت را در قالب، نگاشت ستونها یا قانون پاکسازی پیدا کنید. انتقال آزمایشی زمانی مفید است که به اصلاح روش منجر شود.
نتیجه را با صاحب هر داده تأیید کنید
ادمین CRM میتواند ساختار داده را بررسی کند، اما درباره اعتبار تجاری هر رکورد همیشه تصمیمگیرنده اصلی نیست. مدیر فروش باید فرصتهای باز را تأیید کند، مسئول پشتیبانی وضعیت مشتریان فعال را ببیند و مدیر کسبوکار درباره دادههای حساس یا قدیمی تصمیم بگیرد.
برای تأیید، فهرستهای جدا بسازید: مشتریان فعال و اطلاعات تماس آنها؛ فرصتهای باز و مرحله فعلی هرکدام؛ پیگیریهای عقبافتاده؛ مشتریان بدون مسئول؛ رکوردهای تکراری یا مشکوک؛ و دادههایی که به دلیل ناقص بودن وارد نشدهاند.
هر مسئول باید نتیجه را با یک تصمیم مشخص برگرداند: تأیید، اصلاح، ادغام، انتقال به آرشیو یا حذف از این مرحله. پاسخهایی مثل «به نظر درست است» برای دادههای حساس کافی نیست؛ بهتر است مشخص شود کدام بخش بررسی شده و چه چیزی هنوز نیاز به پیگیری دارد.
در کسبوکارهایی که چند تیم با یک پرونده کار میکنند، سطح دسترسی هم باید در همین مرحله آزمایش شود. فروش ممکن است به فرصت و مکالمه نیاز داشته باشد، اما همه کاربران نباید به تمام اطلاعات مدیریتی یا حساس دسترسی داشته باشند. راهنمای تفکیک دسترسی فروش و پشتیبانی درباره طراحی ماتریس نقشها و دادهها توضیح میدهد.
تأیید نهایی را در یک جلسه طولانی و مبهم برگزار نکنید. برای هر فهرست، یک مالک و یک مهلت تعیین کنید. اگر کسی فرصت بررسی ندارد، آن داده را بهصورت خودکار تأییدشده فرض نکنید. نبود پاسخ، با تأیید تفاوت دارد.
انتقال نهایی را در یک بازه کنترلشده انجام دهید
پیش از انتقال نهایی، یک نسخه پشتیبان از منابع اصلی بگیرید و ثبت کنید که این نسخه در چه تاریخی تهیه شده است. همچنین مشخص کنید از چه زمانی ورود اطلاعات به منبع قدیمی متوقف میشود. اگر تیم همزمان در دو سیستم داده وارد کند، اختلاف بین نسخهها دوباره شکل میگیرد.
برنامه انتقال نهایی باید این موارد را داشته باشد: زمان شروع و پایان کار؛ فهرست دادههای مشمول انتقال؛ مسئول اجرای ورود؛ مسئول کنترل نتیجه؛ روش ثبت خطاها؛ روش برخورد با رکوردهای جدیدی که در زمان انتقال ایجاد میشوند؛ و تصمیم درباره منبع قدیمی پس از پایان کار.
بهتر است انتقال را زمانی انجام دهید که تیم کمترین فعالیت را دارد، اما زمان انتخابی به کسبوکار بستگی دارد. برای تیمی که هر روز فرصت جدید ثبت میکند، توقف کامل ممکن است عملی نباشد. در چنین شرایطی، باید یک فهرست جدا برای تغییرات میان زمان استخراج و زمان ورود داشته باشید.
پس از ورود نهایی، بلافاصله همه اطلاعات را تغییر ندهید. ابتدا نمونهبرداری کنید. چند رکورد از هر گروه را بررسی کنید، گزارشهای اصلی را باز کنید و چند اقدام بعدی را بهصورت واقعی دنبال کنید. اگر خطا جدی است، از اصلاح گسترده تا روشن شدن علت خودداری کنید.
برای اجرای کلی، راهنمای استقرار CRM تیم فروش هم به هماهنگی انتقال اطلاعات، آموزش تیم و کنترل پیگیریها توجه میکند. انتقال فنی وقتی کامل است که تیم بداند از روز بعد، کدام سیستم مرجع کار خواهد بود.
برنامه کنترل داده پس از انتقال را بنویسید
روز پایان ورود داده، پایان پروژه نیست. بخشی از خطاها فقط وقتی دیده میشوند که کارشناسان با پروندهها کار کنند. ممکن است یک شماره در جستوجو پیدا نشود، یک فرصت بدون مالک بماند یا اقدام بعدی به دلیل قالب اشتباه در گزارش دیده نشود.
برای 2 تا 4 هفته اول، کنترلهای کوتاه و منظم تعریف کنید. مدیر یا ادمین میتواند این موارد را بررسی کند: رکوردهای جدید بدون نام یا شماره معتبر؛ مشتریان بدون مسئول؛ فرصتهای بدون مرحله؛ فرصتهای بدون اقدام بعدی؛ پیگیریهای گذشته از موعد؛ رکوردهای تکراری تازهثبتشده؛ تغییرات غیرعادی در نام یا وضعیت مشتری؛ و کاربرانی که اطلاعات را در فیلد اشتباه وارد میکنند.
یک دفتر ثبت خطا داشته باشید. برای هر خطا، تاریخ، رکورد، نوع مشکل، مسئول اصلاح و وضعیت را بنویسید. اگر یک خطا چند بار تکرار شد، مشکل احتمالاً فقط بیدقتی یک کاربر نیست؛ شاید نام فیلد روشن نباشد، آموزش کافی نبوده باشد یا فرایند ثبت نیاز به تغییر داشته باشد.
بعد از دوره اولیه، برنامه را سبکتر اما دائمی کنید. برای نمونه، هر هفته فرصتهای بدون اقدام بعدی و رکوردهای بدون مالک بررسی شوند و هر ماه چند نمونه از مشتریان و مکالمات کنترل شود. این بازبینی باید به تصمیم منجر شود، نه فقط تولید یک فهرست خطا.
یک چکلیست کوتاه برای مدیر و ادمین:
- منبع هر مجموعه داده مشخص است.
- دادههای قابل انتقال از دادههای آرشیوی جدا شدهاند.
- قالب نام و شماره یکسان شده است.
- رکوردهای تکراری بررسی شدهاند.
- انتقال آزمایشی روی نمونه واقعی انجام شده است.
- مالک هر گروه داده نتیجه را تأیید کرده است.
- نسخه پشتیبان و زمان انتقال ثبت شده است.
- گزارش خطا و مسئول اصلاح مشخص است.
- کنترل پس از انتقال در تقویم تیم قرار گرفته است.
پرسشهای رایج
همه اطلاعات قدیمی را وارد کنیم یا فقط اطلاعات فعال را؟
بهتر است انتقال را بر اساس کاربرد آینده انجام دهید. مشتریان فعال، فرصتهای باز، پیگیریهای موعددار و سابقهای که برای تصمیمگیری لازم است، اولویت دارند. اطلاعات ناقص یا بسیار قدیمی را میتوان پس از بررسی در آرشیو نگه داشت، نه اینکه بدون تصمیم وارد محیط کاری تیم کرد.
اگر دو رکورد شبیه هم باشند، کدام را نگه داریم؟
به نام تنها تکیه نکنید. شماره تماس، ایمیل، تاریخ آخرین فعالیت، مالک پرونده و سابقه مکالمه را کنار هم ببینید. رکوردی را نگه دارید که منبع معتبرتر و سابقه کاملتری دارد و اطلاعات مفید رکورد دیگر را پیش از ادغام منتقل کنید.
انتقال آزمایشی باید چه اندازه باشد؟
نمونه باید کوچک اما متنوع باشد. چند مشتری کامل، چند رکورد ناقص، فرصت باز، سابقه تماس، اقدام بعدی و رکورد مشکوک به تکرار را در آن بگذارید. اندازه دقیق به حجم داده بستگی دارد؛ مهم این است که مسیرهای مختلف را نشان دهد، نه اینکه فقط چند ردیف مشابه انتخاب شود.
اگر بعد از انتقال خطا پیدا شد، دادهها را دوباره وارد کنیم؟
نه همیشه. ابتدا علت خطا را پیدا کنید. اگر مشکل از نگاشت ستونها یا قانون پاکسازی است، ورود دوباره بدون اصلاح همان خطا را تکرار میکند. نسخه پشتیبان، فهرست تغییرات و ثبت خطا کمک میکند تصمیم بگیرید اصلاح محدود کافی است یا باید یک بخش از انتقال دوباره انجام شود.
چه کسی باید کیفیت داده را بعد از انتقال کنترل کند؟
ادمین ساختار و خطاهای فنی را کنترل میکند، اما اعتبار تجاری داده به صاحب آن مربوط است. مدیر فروش، مسئول پشتیبانی و مدیر کسبوکار باید هرکدام بخش مرتبط با کار خود را بررسی کنند. این تقسیم مسئولیت از واگذار شدن همه خطاها به ادمین جلوگیری میکند.
از فردا، کار را با ساختن یک فهرست از منابع داده شروع کنید؛ نه با انتقال فایل. برای هر منبع، مالک، نوع اطلاعات و وضعیت فعلی را بنویسید. سپس فقط یک گروه کوچک را پاکسازی و آزمایش کنید و نتیجه را از کسی بگیرید که هر روز با همان اطلاعات کار میکند. بعد از تأیید، انتقال نهایی را در بازهای مشخص انجام دهید و کنترلهای پس از آن را در برنامه کاری بگذارید. اگر میخواهید جایگاه قابلیتهای کلید در ثبت مشتری، پیگیری فروش و مدیریت فعالیتها را بررسی کنید، راهکارهای کلید برای مدیریت فروش و ارتباط با مشتری را ببینید و پرسشهای اجرایی خود را از مسیر تماس با کلید مطرح کنید.