بلوک های ساختمانی تجارت قابل ترکیب

Composable Commerce به سه الزام اصلی تقسیم می شود، front-end، API و ادغام. بخش جلویی شامل هر رابط کاربری یا نقطه تماس مشتری است که رایج ترین آنها یک وب سایت است، اما همچنین می تواند شامل برنامه های کاربردی تلفن همراه، سیستم های POS، AR/VR و موارد دیگر باشد.

ادغام ها به ترکیب API های متعدد و همچنین انتقال داده ها بین آنها کمک می کند.

در نهایت، آنها خود API می کنند. اینها معمولاً سرویس‌های SaaS هستند و معمولاً وقتی مردم در مورد بلوک‌های سازنده ترکیب‌پذیر صحبت می‌کنند، منظور آنهاست. این موارد می تواند شامل موارد زیر باشد:

محصولات در مرکز تجارت دیجیتال زندگی می کنند، بدون محصول چیزی برای فروش وجود ندارد. یک PIM قوی یک جزء اساسی و یک نقطه شروع عالی است. PIM کسب‌وکارها را قادر می‌سازد تا داده‌های محصول را ذخیره، مدیریت و نگهداری کنند. این شامل ویژگی ها، توضیحات، تصاویر و مشخصات فنی است. با متمرکز کردن این اطلاعات محصول اصلی، یک PIM به جای کپی کردن داده ها به صورت دستی در چندین سیستم، به اطمینان از دقت در نقاط تماس کمک می کند.

PIM های سنتی بر ایجاد محصولات تمرکز می کنند و ممکن است برای ارائه آن داده ها به وب سایت ها یا برنامه های تلفن همراه طراحی نشده باشند. در برخی از پروژه ها ممکن است حفظ PIM سنتی و افزودن یک PIM دیجیتال برای غنی سازی داده ها و انتشار آن داده ها از طریق API های مقیاس پذیر مفید باشد.

برای PIM مهم است که انعطاف پذیر باشد و قیمت ها، کاتالوگ ها، زبان ها و تغییرات زیادی را ارائه دهد. محدودیت‌ها در PIM از طریق بقیه پیاده‌سازی کاهش خواهند یافت.

کشف محصول / جستجو

هنگامی که داده های محصول تعریف شد، گام بعدی این است که مشتریان را قادر می سازد تا محصولات مورد نیاز خود را به سرعت پیدا کنند. این با یک موتور جستجوی قوی شروع می شود که باید فراتر از یک جستجوی کلیدواژه اصلی باشد و شامل فیلترهای پیشرفته، توصیه های شخصی، عملکرد تقویت/دفن کردن، و جنبه های قابل تنظیم باشد. بسته به محصولات، جستجو ممکن است نیاز به کاتالوگ های بزرگ با تغییرات زیادی داشته باشد.

سرویس جستجوی محصول همچنین باید API-First و مقیاس پذیر باشد، این سرویس وظیفه تامین انرژی صفحات فهرست محصول (PLP) و صفحات جستجوی محصول را بر عهده خواهد داشت که هر دو در بالای یک قیف تجاری سنتی قرار دارند و حجم قابل توجهی از ترافیک دریافت می کنند.

سیستم مدیریت سفارش (OMS)

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

مدیریت ارتباط با مشتری (CRM)

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

سیستم مدیریت محتوا (CMS)

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

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

پرداخت و کشف تقلب

درگاه های پرداخت یک نیاز واضح برای هر تجربه تجارت دیجیتال هستند، نه فقط راه حل های قابل ترکیب. با انتخاب گزینه‌های API-first قابل ترکیب برای همه مؤلفه‌ها، می‌توان از داده‌های بیشتری در هنگام رسیدگی به تشخیص تقلب استفاده کرد. به خصوص داده های OMS و CRM برای شناسایی متخلفان مکرر یا رفتار غیرمنتظره.

خلاصه

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