برای استفاده از داده فروش، شناسه مشتری، تاریخ واقعی فاکتور، اقلام خرید و منبع رکورد باید درست منتقل شوند. این داده بعداً در پروفایل، RFM، سگمنت و سناریوهای وفاداری استفاده میشود.
این اتصال داده موردنیاز مشتری، فاکتور، محصول و شعبه را از سیستم مبدأ به لژیون منتقل میکند. دامنه دقیق داده و روش همگامسازی به سیستم و پروژه شما بستگی دارد.
برندهایی که از لژیون برای مدیریت رابطه با مشتری استفاده کردهاند
اتصال فنی زمانی ارزش دارد که منبع حقیقت، هویت مشتری، زمان ایونت و مسئولیت هر سیستم روشن بماند. مسئلههای همین صفحه را قبل از توسعه دامنه اتصال بررسی کنید.
یکپارچهسازی موفق از نظر فنی لزوماً داده قابل اعتماد برای CRM نمیسازد. وقتی اطلاعات مشتری و مشتری، فاکتور، اقلام فروش، محصول و اطلاعات شعبه فقط در نرمافزار فروش، حسابداری یا برنامهریزی منابع سازمانی (ERP) بمانند، تیم برای استفاده از آنها در سگمنت مشتریان، وفاداری یا سفر مشتری مجبور به خروجی گرفتن و انتقال دستی میشود. این فاصله باعث تاخیر، ناسازگاری و فرایندهای تکراری میشود.
اگر شماره موبایل، ایمیل یا شناسه داخلی در منابع مختلف با قواعد متفاوت ثبت شوند، یک مشتری ممکن است به چند پروفایل شکسته شود یا رکوردهای اشتباه با هم ادغام شوند. سیاست هویت و نرمالسازی باید قبل از همگامسازی مشخص باشد.
برای تحلیل رفتاری، زمان واقعی ایونت و وضعیت معتبر آن اهمیت دارد. درونریزی با تاریخ امروز یا انتقال همه وضعیتها به یک شکل میتواند تازگی، تکرار و ارزش خرید (RFM)، سفر مشتری و گزارشها را تحریف کند. نگاشت زمانی و وضعیت باید بخشی از قرارداد یکپارچهسازی باشد. پیش از اتومیشن، باید معلوم باشد این مسئله با کدام داده قابل تشخیص است.
اتصال پایدار باید مشخص کند در خطای شبکه، داده ارسالی ناقص یا اجرای دوباره چه اتفاقی میافتد. شناسه یکتا، تلاش مجدد کنترلشده و مانیتورینگ کمک میکنند داده تکراری یا گمشده در سیستم باقی نماند.
قابلیتهای این صفحه نشان میدهند اتصال فقط انتقال رکورد نیست؛ داده باید به هویت درست برسد و در ادامه بتواند در سگمنتبندی، سفر مشتری یا اقدام بعدی استفاده شود.
فاکتور باید با تاریخ واقعی خرید و هویت مشتری منتقل شود تا تازگی خرید و سفرهای مشتری زمانمحور بر اساس زمان درونریزی محاسبه نشوند.
شناسه مشتری، شناسه کالا (اسکیو) یا شناسه محصول باید با سیستم مبدأ هماهنگ باشند. تغییر دلخواه کلیدهای مرجع میتواند همگامسازی آینده را مختل کند.
در کسبوکار چندشعبهای، شناسه شعبه روی تراکنش کمک میکند رفتار مشتری در کل شبکه و در هر نقطه جداگانه تحلیل شود.
در صورت وجود سابقه قابل اتکا، فاکتورهای قدیمی میتوانند پایه تازگی، تکرار و ارزش خرید (RFM) و تحلیل نگهداشت باشند. کیفیت تاریخ و هویت برای این کار ضروری است.
فروش جدید میتواند محرک خرید دوم، پیام پس از خرید یا تغییر سگمنت مشتریان باشد.
اگر لژیونر یا صندوق فروشگاهی دیگری نیز وجود دارد، منبع مرجع فاکتور و نحوه جلوگیری از ثبت دوباره باید در معماری مشخص باشد.
نتیجه اتصال باید در کیفیت داده، یکپارچگی هویت و امکان استفاده از ایونت در تصمیم بعدی مشتری دیده شود.
اطلاعات مشتری، فاکتور، اقلام فروش، محصول و اطلاعات شعبه از نرمافزار فروش، حسابداری یا برنامهریزی منابع سازمانی (ERP) به ساختاری وارد میشوند که بتوان از آنها برای شناخت و تصمیمگیری درباره مشتری استفاده کرد. پس از اتصال، نمونه داده را از مبدأ تا پروفایل و گزارش نهایی بازسازی و تطبیق کنید.
داده تازه میتواند وضعیت سگمنت مشتریان یا محرک اتومیشن را تغییر دهد و نیاز به ساخت فهرستهای دستی و انتقال دورهای فایل را کاهش دهد.
قرارداد مشخص داده، هویت و تلاش مجدد باعث میشود رفتار یکپارچهسازی قابل تست و قابل پیشبینیتر باشد و اختلاف میان سیستمها زودتر آشکار شود.
پس از پایدار شدن اتصال، همان داده میتواند در وفاداری، گزارش، کمپین و سفرهای مشتری جدید استفاده شود بدون اینکه برای هر کاربرد یکپارچهسازی جدا ساخته شود.
ترتیب مراحل کمک میکند قرارداد داده و مالکیت هر مرحله قبل از گسترش اتصال روشن بماند.
مشخص میشود نرمافزار فروش، حسابداری یا برنامهریزی منابع سازمانی (ERP) مالک کدام فیلدها و ایونتهاست و چه دادهای باید به لژیون منتقل شود. از ارسال اطلاعات بدون کاربرد یا فیلدهایی که منبع معتبر ندارند پرهیز میشود.
نام فیلدها، نوع داده، شناسه مشتری، تاریخ، واحد پول یا سایر مقادیر با مدل لژیون تطبیق داده میشوند. قواعد نرمالسازی قبل از انتقال انبوه مستند و روی نمونه تست میشوند.
چند رکورد واقعی یا کنترلشده منتقل میشوند تا هویت، تاریخ، وضعیت و روابط اصلی بررسی شوند. هدف این است که خطاهای نگاشت قبل از همگامسازی گسترده پیدا شوند.
پس از تأیید نمونه، مسیر پایدار داده فعال میشود. تلاش مجدد، گزارش ثبت و نحوه برخورد با رکورد ناقص یا تکراری باید مشخص باشند تا یکپارچهسازی در بلندمدت قابل نگهداری بماند. اتصال کانال یا اقدام را بعد از تثبیت داده و منطق تصمیم انجام دهید.
پس از پایدار شدن داده، پروفایل مشتری، تازگی، تکرار و ارزش خرید (RFM)، وفاداری و سفر مشتری پس از خرید روی اطلاعات واقعی اجرا میشود و سلامت یکپارچهسازی در کنار نتیجه سناریوها پایش میگردد. پس از اتصال، نمونه داده را از مبدأ تا پروفایل و گزارش نهایی بازسازی و تطبیق کنید.
سناریوهای صفحه نشان میدهند داده ورودی چگونه باید به هویت مشتری و اقدام قابل استفاده متصل شود.
فاکتور ثبتشده در سیستم فروش به پروفایل مشتری متصل میشود تا سابقه آفلاین در سگمنت مشتریان و تازگی، تکرار و ارزش خرید (RFM) قابل استفاده باشد. این سناریو را با یک گروه محدود، شرط خروج روشن و معیار نتیجه شروع کنید.
فاکتورهای گذشته با تاریخ واقعی و هویت قابل اتکا وارد میشوند تا تحلیل مشتری از روز شروع یکپارچهسازی صفر نشود. یکپارچهسازی موفق از نظر فنی لزوماً داده قابل اعتماد برای CRM نمیسازد.
فروش جدید محرک سناریوی تشکر، پیشنهاد مکمل یا خرید دوم میشود و در صورت خرید بعدی مسیر قبلی متوقف میشود. اگر مشتری رفتار هدف را انجام داد، مسیر باید بتواند متوقف یا تغییر کند.
شناسه شعبه در تراکنش اجازه میدهد خرید مشتری در سطح کل برند و هر شعبه تحلیل شود و تجربه وفاداری هماهنگ بماند. مقایسه با رفتار طبیعی مشتری کمک میکند اثر سناریو بیشبرآورد نشود.
در سناریوهایی که محصول برای سگمنت مشتریان یا پیشنهاد مهم است، شناسه مرجع محصول باید ثابت بماند تا ارتباط تراکنش با کاتالوگ از بین نرود. پس از اتصال، نمونه داده را از مبدأ تا پروفایل و گزارش نهایی بازسازی و تطبیق کنید.
برای هر وابستگی باید نقش سیستم، منبع داده و رفتار خطا یا تلاش مجدد مشخص باشد.
منبع اصلی مشتری، فاکتور، اقلام فروش، محصول و اطلاعات شعبه. در اتصال، هویت مشتری و زمان واقعی ایونت باید حفظ شوند.
داده ورودی در پروفایل و تاریخچه مشتری قابل استفاده میشود. منبع حقیقت و رفتار داده تکراری را قبل از اجرای سناریو مشخص کنید.
ویژگی و رفتار تازه میتواند عضویت بخشهای مشتری را بهروز کند. هدف یکپارچهسازی انتقال حداکثری داده نیست؛ داده باید کاربرد روشن داشته باشد.
رویداد یا تغییر وضعیت میتواند محرک یا شرط سفر مشتری باشد. نمونه رکورد را از سیستم مبدأ تا استفاده نهایی انتهابهانتها کنترل کنید.
قبل از توسعه دامنه، منبع داده، قرارداد فیلدها، هویت مشتری و سناریوی خطا را روی دامنه محدود بررسی کنید.
منابع داده مشتری، خرید، تعامل و کانالهای اجرایی بررسی میشوند تا مشخص شود چه اطلاعاتی برای سناریوهای موردنظر در دسترس است. کیفیت هویت مشتری، تاریخ رویدادها و مالک هر فیلد باید قبل از استقرار روشن باشد.
هدف تجاری، بخشهای مشتری، رویدادها، مزایا و شاخصهای اندازهگیری تعریف میشوند. در این مرحله مشخص میشود چه قابلیتهایی واقعاً برای فاز اول لازماند و چه بخشهایی میتوانند بعد از تثبیت داده و فرایند توسعه پیدا کنند.
سیستمهای مبدأ از طریق یکپارچهسازی آماده، API، فایل یا اتصال اختصاصی به لژیون متصل میشوند. برای داده تاریخی باید هویت مشتری، تاریخ واقعی و ساختار کلیدی اطلاعات حفظ شوند تا تحلیل و سفرهای مشتری روی داده تحریفشده اجرا نشوند. تاریخ ایونت و هویت واقعی مشتری در انتقال داده نباید از بین بروند.
بخشهای مشتری، سفرهای مشتری، کمپینها، قواعد وفاداری و سایر تنظیمات موردنیاز ساخته میشوند. هر سناریو باید محرک، شرایط خروج و معیار نتیجه روشن داشته باشد تا قابلیت محصول به یک جریان عملیاتی قابل سنجش تبدیل شود.
داده نمونه، مسیرهای اصلی، تلاش مجددها و رفتارهای مرزی تست میشوند. سپس تیم کسبوکار با منطق استفاده از سیستم آشنا میشود و استقرار با توجه به دسترسیها، وابستگیهای فنی و پیچیدگی پروژه انجام میشود. استقرار پایان کار نیست؛ پس از اجرا باید کیفیت داده و رفتار سناریو بازبینی شوند.
پاسخ کوتاه به پرسشهایی که معمولاً هنگام بررسی این راهکار، نیازهای فنی و مسیر راهاندازی مطرح میشوند.
معمولاً داده مشتری، فاکتور، اقلام فروش، محصول و شعبه بررسی میشوند. فیلدهای نهایی باید بر اساس سناریو و ساختار سیستم مبدأ مشخص شوند.
پاسخ سؤال ۱کلید مناسب به سیستم مبدأ و کیفیت داده بستگی دارد. شماره موبایل، ایمیل یا شناسه داخلی هرکدام محدودیت دارند. مهم است قبل از همگامسازی یک سیاست هویت مشخص، نرمالسازی و رفتار ادغام تعریف شود تا یک مشتری چند بار ساخته نشود یا افراد اشتباه ادغام نشوند.
پاسخ سؤال ۲در صورت وجود داده قابل اتکا و مسیر انتقال داده، بله. باید تاریخ واقعی ایونتها، شناسه مشتری و روابط اصلی حفظ شوند. درونریزی تاریخی بهتر است ابتدا روی نمونه محدود تست شود تا اثر آن روی تازگی، تکرار و ارزش خرید (RFM)، سگمنت مشتریان و سفرهای مشتری زمانمحور قابل پیشبینی باشد.
پاسخ سؤال ۳برای رویدادها و تراکنشهایی که امکان تلاش مجدد دارند باید شناسه پایدار یا منطق جلوگیری از ثبت تکراری وجود داشته باشد. در غیر این صورت اجرای دوباره گردش کار میتواند خرید، امتیاز یا محرک را چند بار ثبت کند. رفتار دقیق باید در قرارداد اتصال تعریف و تست شود. بهتر است اول روی یک نمونه محدود تست شود و بعد از تأیید داده و فرایند، دامنه اجرا بزرگتر شود.
پاسخ سؤال ۴این موضوع به سناریو و قابلیت یکپارچهسازی بستگی دارد و نباید بدون طراحی فرض شود. برای هر فیلد باید مشخص باشد منبع مالک کدام سیستم است. همگامسازی دوطرفه بدون مالکیت روشن میتواند چرخه، بازنویسی یا تناقض ایجاد کند و فقط در صورت نیاز واقعی باید پیاده شود. پس از اتصال، نمونه داده را از مبدأ تا پروفایل و گزارش نهایی بازسازی و تطبیق کنید.
پاسخ سؤال ۵ثبت گزارش ثبت خطا، تعداد رکوردهای موفق و ناموفق، کاهش ناگهانی حجم داده و تست دورهای نمونهها مهم هستند. علاوه بر سلامت فنی، باید بررسی شود داده تازه واقعاً در پروفایل، سگمنت مشتریان یا سفر مشتری موردنظر دیده میشود و مسیر فروش فقط بدون خطا اجرا نمیشود. قبل از تصمیم، باید محدودیت داده و سیستمهای فعلی همان کسبوکار را هم دید. تعریف شناسه مشتری، زمان واقعی ایونتها و مسئولیت هر سیستم میتواند روی روش پیادهسازی و نتیجه عملی اثر مستقیم بگذارد.
پاسخ سؤال ۶زمان به استاندارد بودن سیستم مبدأ، کیفیت API یا فایل، تعداد فیلدها، نیاز به انتقال داده تاریخی و پیچیدگی هویت مشتری بستگی دارد. اتصال استاندارد با داده تمیز سریعتر از پروژهای با چند نسخه نرمافزار و دادههای ناسازگار اجرا میشود. برای فاز اول، یک رفتار هدف و یک منبع داده قابل اتکا را انتخاب کنید تا نتیجه قابل تفسیر بماند.
پاسخ سؤال ۷در جلسه دمو، ابتدا مسئله، منبع داده و رفتار هدف روشن میشوند؛ سپس درباره سناریوی قابل اجرا و روش سنجش آن صحبت میکنیم. پس از اتصال، نمونه داده را از مبدأ تا پروفایل و گزارش نهایی بازسازی و تطبیق کنید.
پلتفرم داده مشتریباشگاه مشتریانصندوق لژیونرراهکار چندشعبهایتحلیل تازگی، تکرار و ارزش خرید (RFM)درخواست دمو
