عبارت «سایت شبیه دیجیکالا» معمولاً به یک فروشگاه ساده اشاره نمیکند. منظور اغلب یک مارکتپلیس چندفروشندگی است که کالا، فروشنده، قیمت، موجودی، سفارش، ارسال، مرجوعی، کمیسیون و تسویه را در یک سیستم هماهنگ مدیریت میکند. چنین پروژهای باید مانند یک سامانه عملیاتی طراحی شود، نه فقط یک قالب فروشگاهی بزرگ.
نام «دیجیکالا» در این مقاله فقط برای توضیح الگوی شناختهشده مارکتپلیس چندفروشندگی استفاده شده است؛ هدف، تحلیل معماری یک محصول مستقل است و هیچ ادعای ارتباط، نمایندگی یا کپی رابط و برند دیگری مطرح نیست.
فروشگاه اینترنتی با مارکتپلیس چه تفاوتی دارد؟
در فروشگاه تکفروشنده، مالک سایت محصول، قیمت و موجودی را کنترل میکند. در مارکتپلیس چند فروشنده ممکن است یک کالای مشابه را با قیمت، موجودی، شرایط ارسال یا ضمانت متفاوت عرضه کنند. همین تفاوت باعث میشود مدل داده و فرآیند سفارش پیچیدهتر شود.
هسته اول: کاتالوگ محصول باید از پیشنهاد فروشنده جدا باشد
یکی از تصمیمهای مهم این است که «محصول» با «پیشنهاد فروش» یکی نباشد. مشخصات اصلی یک گوشی یا کالا میتواند یک بار در کاتالوگ ثبت شود، اما چند فروشنده برای همان کالا قیمت، موجودی و شرایط متفاوت داشته باشند. این مدل جلوی ایجاد صدها صفحه تکراری را میگیرد.
پنل فروشنده چه امکاناتی لازم دارد؟
ثبت یا اتصال کالا، قیمت و موجودی، مشاهده سفارش، آمادهسازی ارسال، اسناد مالی، درخواست تسویه و گزارش عملکرد از نیازهای اصلی فروشنده است. دسترسی فروشنده باید محدود باشد و هیچ فروشندهای داده یا سفارش فروشنده دیگر را نبیند.
سفارش چندفروشندگی چگونه مدیریت میشود؟
ممکن است سبد خرید مشتری شامل کالاهای چند فروشنده باشد. سیستم باید بتواند سفارش اصلی را به زیرسفارشهای مرتبط تقسیم کند، وضعیت هر بخش را جدا نگه دارد و در عین حال تجربه واحدی برای مشتری ارائه دهد. این موضوع روی ارسال، لغو، مرجوعی و تسویه اثر مستقیم دارد.
کمیسیون و تسویه فقط یک درصد ساده نیست
کمیسیون میتواند بر اساس دسته کالا، فروشنده، کمپین یا قرارداد متفاوت باشد. تسویه نیز باید بعد از درنظرگرفتن مرجوعی، تخفیف، هزینه ارسال و سایر کسورات انجام شود. ثبت شفاف ریز محاسبات برای جلوگیری از اختلاف بین پلتفرم و فروشنده ضروری است.
انبار و موجودی را از اول جدی بگیرید
در بعضی مارکتپلیسها کالا نزد فروشنده میماند و در بعضی مدلها انبار مرکزی یا ترکیبی وجود دارد. نوع موجودی تعیین میکند چه زمانی رزرو کالا انجام شود، چه کسی مسئول ارسال باشد و اگر موجودی همزمان تغییر کرد سیستم چگونه از فروش کالای ناموجود جلوگیری کند.
جستوجو و فیلتر ستون اصلی تجربه مشتری است
هرچه تعداد کالا بیشتر شود، دستهبندی، ویژگیها، فیلتر، مرتبسازی و جستوجو اهمیت بیشتری پیدا میکنند. ساختار ویژگی محصول باید استاندارد باشد تا کاربر بتواند مثلاً موبایل را با حافظه، رنگ، برند یا بازه مشخصات فنی فیلتر کند.
مدیریت محتوای محصول و کنترل کیفیت فروشنده
مارکتپلیس باید مشخص کند فروشنده تا چه حد اجازه تغییر عنوان، تصویر، مشخصات یا توضیح را دارد. برای حفظ کیفیت و سئو معمولاً بخشی از اطلاعات کاتالوگ مرکزی است و پیشنهادهای فروشنده روی قیمت، موجودی و شرایط فروش تمرکز میکنند.
پنل مدیریت چه چیزی را باید کنترل کند؟
فروشندگان، تأیید مدارک، کالاها، سفارشها، شکایتها، مرجوعی، کمیسیون، تسویه، تخفیف، محتوا و گزارشهای عملیاتی هسته پنل مدیریت هستند. هدف پنل این نیست که فقط آمار نشان دهد؛ باید عملیات روزانه را سریع و قابل پیگیری کند.
سایت، اپ و پنل فروشنده باید از یک API استفاده کنند
اگر سایت مشتری، اپ موبایل و پنل فروشنده هرکدام منطق جدا داشته باشند، قیمت و موجودی خیلی زود ناسازگار میشوند. معماری مناسب یک هسته مرکزی برای کاربران، کاتالوگ، پیشنهاد فروشنده و سفارش دارد و رابطهای مختلف از همان داده استفاده میکنند.
آیا باید از روز اول همه امکانات دیجیکالا را ساخت؟
خیر. نسخه اول میتواند روی یک حوزه کالا، تعداد محدود فروشنده، ثبت محصول، قیمت و موجودی، خرید، سفارش، کمیسیون و تسویه پایه تمرکز کند. قابلیتهایی مثل لجستیک پیچیده، سیستم پیشنهاد هوشمند، باشگاه مشتریان یا تبلیغات فروشنده پس از اعتبارسنجی مدل اضافه میشوند.
چه زمانی طراحی اختصاصی منطقیتر از افزونه چندفروشندگی است؟
برای شروع کوچک، وردپرس و افزونههای چندفروشندگی ممکن است کافی باشند. اما وقتی قوانین کمیسیون، تسویه، انبار، نقشها، API، اپلیکیشن یا حجم عملیات اختصاصی شود، طراحی سامانه اختصاصی کنترل بیشتری روی توسعه و نگهداری میدهد. انتخاب باید بعد از نیازسنجی انجام شود، نه صرفاً بر اساس نام فناوری.
جمعبندی
ساخت سایت چندفروشندگی با الگوی یک مارکتپلیس بزرگ، پروژه طراحی ظاهر نیست؛ پروژه مدلسازی عملیات فروش است. کاتالوگ مرکزی، پیشنهاد فروشنده، سفارش چندبخشی، کمیسیون، تسویه، موجودی و پنل مدیریت باید از ابتدا بهعنوان یک سیستم هماهنگ دیده شوند. نسخه اول بهتر است کوچک، قابل استفاده و آماده توسعه باشد.
اگر این پروژه را برای کسبوکار خودتان میخواهید
مسیرهای تخصصی مرتبط با این مقاله
درباره نویسنده
رضا اسماعیل گل
طراح سایت، اپلیکیشن و سامانههای خدماتی با ۲۰ سال تجربه کاری. در این بلاگ تجربههای اجرایی پروژههای فارسی را به زبان کاربردی منتشر میکنم.
این موضوع را برای پروژه خودتان میخواهید؟
نیاز، بودجه و نسخه اول پروژه را بررسی میکنیم تا قبل از توسعه مشخص شود چه چیزی واقعاً باید ساخته شود.