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