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