رفتن به محتوای اصلی

مهاجرت به CRM جدید: انتقال داده بدون از دست دادن مشتری

تیم روکا۱۰ دقیقه مطالعه
مهاجرت به CRM جدید: انتقال داده بدون از دست دادن مشتری

بیشتر مهاجرت‌ها به‌خاطر خرابی ابزار شکست نمی‌خورند؛ به‌خاطر اینکه داده‌ی بی‌کیفیت عیناً به خانه‌ی جدید منتقل می‌شود.

مهاجرت داده معمولاً به‌عنوان یک کار فنی دیده می‌شود: فایل را بده، وارد کن، تمام. در عمل، مهاجرت یک تصمیم مدیریتی است. سخت‌ترین بخشش نه فرمت فایل، که پاسخ به این سوال است: از این چند هزار رکوردی که سال‌ها جمع شده، کدامش واقعاً به درد فردا می‌خورد؟

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

گام صفر: تصمیم بگیرید چه چیزی را نمی‌برید

نوع دادهمنتقل شود؟دلیل
مخاطب‌های فعال دو سال اخیربلههسته‌ی کار روزمره
معامله‌های بازبله، با قدم بعدیبدون قدم بعدی، رکورد مرده وارد می‌کنید
معامله‌های بسته‌ی دو سال اخیربله، خلاصهبرای فروش مجدد و گزارش لازم است
مخاطب‌های بدون تعامل بیش از سه سالخیرآرشیو جدا کافی است
یادداشت‌های آزاد و طولانیگزینشیفقط آن‌هایی که تصمیم بعدی به آن‌ها وابسته است
فایل‌های پیوست قدیمیگزینشیقرارداد و پیش‌فاکتور بله، بقیه در آرشیو
سوابق مالی و فاکتورهامعمولاً خیرجای این داده سیستم حسابداری است

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

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

منابعی که معمولاً جا می‌مانند

داده‌ی مشتری شما فقط در فایل اکسل نیست. قبل از شروع، این منابع را فهرست کنید:

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

پاک‌سازی، قبل از انتقال نه بعد از آن

یکسان‌سازی شماره‌ها

شماره تماس کلید اصلی تشخیص تکراری‌هاست، پس اول باید یکدست شود:

حالت خامحالت یکسان‌شده
۹۱۲۳۴۵۶۷۸۹ (بدون صفر)۰۹۱۲۳۴۵۶۷۸۹
۹۸۹۱۲۳۴۵۶۷۸۹+۰۹۱۲۳۴۵۶۷۸۹
۰۹۱۲ ۳۴۵ ۶۷۸۹ با فاصله یا خط تیره۰۹۱۲۳۴۵۶۷۸۹
دو شماره در یک سلولستون شماره‌ی دوم جدا شود
شماره‌ی ثابت بدون کد شهرکد شهر اضافه شود، وگرنه بی‌فایده است

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

نام‌ها

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

حذف تکراری

ادغام را بر اساس شماره‌ی موبایل انجام دهید، نه نام. نام‌ها با املای متفاوت نوشته می‌شوند و «صادقی» و «صادقي» برای سیستم دو نفرند. ترتیب پیشنهادی:

  1. مرتب‌سازی بر اساس شماره‌ی یکسان‌شده.
  2. در رکوردهای هم‌شماره، تازه‌ترین تاریخ تماس مبنا شود.
  3. اطلاعات تکمیلی رکوردهای دیگر (ایمیل، نام شرکت، آدرس) به رکورد مبنا اضافه شود.
  4. هم‌نام‌های بدون شماره را دستی بررسی کنید؛ خودکار ادغام نکنید.

اگر فایل مبدأ اکسل است، ساختار درست ستون‌ها را در مدیریت مشتریان با اکسل آورده‌ایم و همان ساختار، مهاجرت را ساده می‌کند.

نگاشت فیلدها

قبل از هر واردسازی، یک جدول نگاشت بنویسید. این جدول سند پروژه است و اگر چیزی خراب شد، با همین می‌فهمید کجا:

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

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

تست با نمونه، پیش از انتقال کامل

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

معیار پذیرش را قبل از تست بنویسید تا نتیجه قابل قضاوت باشد:

  • هر ۲۰ رکورد وارد شده و هیچ‌کدام دوباره ساخته نشده‌اند.
  • جست‌وجو با شماره، دقیقاً یک نتیجه می‌دهد.
  • تاریخ‌ها درست‌اند و یک روز جابه‌جا نشده‌اند.
  • مرحله‌ی کاریز همان چیزی است که در فایل بود.
  • حروف فارسی درست نمایش داده می‌شوند و «ی» و «ک» عربی جایگزین نشده‌اند.

اگر یکی از این پنج مورد رد شد، نگاشت را اصلاح کنید و دوباره تست کنید. هزینه‌ی تکرار تست، در برابر هزینه‌ی پاک‌سازی پنج هزار رکورد غلط، ناچیز است.

تاریخ قطع سیستم قدیمی

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

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

برنامه‌ی بازگشت

قبل از انتقال کامل، جواب این سه سوال باید روی کاغذ باشد:

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

وقتی درباره‌ی پشتیبان و خروجی داده با فروشنده حرف می‌زنید، سوال‌های امنیتی را هم همان‌جا بپرسید؛ فهرستش در امنیت داده‌ی مشتری هست.

چک‌لیست کامل مهاجرت

پیش از شروع

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

پاک‌سازی

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

انتقال

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

بعد از انتقال

  • تعداد رکوردهای مقصد با مبدأ مقایسه و اختلاف توضیح داده شده است.
  • ده جست‌وجوی تصادفی با شماره و نام انجام شده است.
  • تاریخ قطع سیستم قدیمی اعلام شده است.
  • فایل قدیمی فقط‌خواندنی شده است.
  • دسترسی‌ها و نقش‌ها برای همه‌ی کسانی که با مشتری کار می‌کنند تعریف شده است.

هفته‌ی اول بعد از مهاجرت

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

در همین هفته تصمیم بگیرید از این به بعد چه داده‌ای اصلاً جمع می‌شود؛ چارچوبش در داده‌ی مشتری آمده و مستقیماً روی سنگینی فرم‌های آینده اثر می‌گذارد.

چه کسی مهاجرت را انجام دهد

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

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

جمع‌بندی

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

نویسنده

تیم روکا

تیم محصول روکا؛ نرم‌افزار CRM ابری فارسی برای تیم‌های فروشی که تلفنی کار می‌کنند.

اشتراک‌گذاری:تلگرامواتساپایتالینکدین

نظر شما

نظر خود را بنویسید

هنوز نظری ثبت نشده است. اولین نفری باشید که نظر می‌دهد.

مطالب مرتبط