باصری‌تک سیستم‌سازی کسب‌وکار
پلتفرم ثبت سفارش و CRM

بروبه — سامانه‌ی ثبت سفارش و CRM برای فروشگاه‌ها

یک سامانه‌ی اشتراکی که هر فروشگاه داخلش عضو می‌شه و یه لینک عمومی ثبت سفارش می‌گیره تا به مشتری‌هاش بده — به‌جای جمع‌کردن سفارش از دایرکت و واتساپ و تلگرام. پشت اون لینک، یه پنل مدیریت سفارش، گزارش فروش و CRM هست.

  • Laravel
  • معماری چندمستأجری
  • رابط راست‌به‌چپ فارسی
  • صفحه‌ی سفارش بدون نیاز به ثبت‌نام
لایه‌ی زیر — پنل فروشگاه: سفارش‌ها، گزارش فروش به تفکیک پلتفرم و CRM چیزی که ما ساختیم
لایه‌ی رو — صفحه‌ی عمومی ثبت سفارش، همان چیزی که مشتریِ فروشگاه می‌بیند چیزی که مشتری می‌بینه

بازسازی وایرفریمی از همان پنل، با داده‌ی ساختگی. اسکرین‌شات واقعی منتشر نمی‌کنیم، چون داده‌ی فروشگاه‌های عضو و مشتری‌هاشون توش دیده می‌شه.

چالش

فروشگاه‌هایی که تو شبکه‌های اجتماعی می‌فروشن، سفارش رو از هر جایی می‌گیرن: دایرکت اینستاگرام، واتساپ، تلگرام، گاهی هم تماس تلفنی. هیچ‌کدوم از این‌ها بد نیستن؛ مشکل اینه که هیچ‌کدوم جای ثبت سفارش نیستن. نتیجه‌اش اینه که سفارش لای مکالمه‌ها گم می‌شه، سابقه‌ی خرید مشتری هیچ‌جا جمع نمی‌شه، و صاحب فروشگاه آخر ماه هیچ راهی نداره بفهمه واقعاً چقدر فروخته یا مشتری‌هاش از کجا اومدن.

محدودیت‌ها

چیزهایی که نمی‌شد عوضشون کرد

این‌ها موانع پروژه نبودن؛ بخشی از صورت‌مسئله بودن. تصمیم‌های بعدی بدون این‌ها قابل‌فهم نیستن.

  • چند فروشگاه روی یک سامانه

    این یه نرم‌افزار اختصاصیِ یک کسب‌وکار نیست؛ فروشگاه‌های مختلف داخلش عضو می‌شن. یعنی جداسازی داده بین فروشگاه‌ها باید از پایه در مدل داده باشه، نه یه فیلتر روی کوئری‌ها.

  • مشتریِ نهایی حساب کاربری نداره

    کسی که سفارش می‌ده، مشتریِ فروشگاهه نه کاربر سامانه. مسیر ثبت سفارش باید بدون ثبت‌نام و بدون ورود کار کنه — هر اصطکاکی این‌جا مستقیم به سفارشِ از‌دست‌رفته تبدیل می‌شه.

  • منبع سفارش باید حفظ بشه

    وقتی همه‌ی سفارش‌ها از یک لینک وارد می‌شن، به‌طور طبیعی این اطلاعات از بین می‌ره که مشتری از کدوم پلتفرم اومده. حفظ این تفکیک یه تصمیم طراحی بود، نه یه قابلیت جانبی — چون بدونش صاحب فروشگاه نمی‌فهمه کدوم کانالش واقعاً کار می‌کنه.

رویکرد

به‌جای این‌که به هر فروشگاه بگیم «فروشگاه اینترنتی بساز»، مسئله رو کوچک‌تر و دقیق‌تر گرفتیم: گلوگاه، نداشتنِ سایت نبود؛ نداشتنِ یه نقطه‌ی واحد برای فرود سفارش بود. برای همین واحد اصلی محصول شد «یک لینک عمومی» که فروشگاه هرجا می‌خواد منتشرش می‌کنه. هر چیز دیگه‌ای — گزارش، تفکیک پلتفرم، سابقه‌ی مشتری — از همون یک نقطه تغذیه می‌شه.

راه‌حل

یه سامانه‌ی اشتراکیِ چندفروشگاهی: هر فروشگاه بعد از عضویت یه لینک عمومی ثبت سفارش می‌گیره که بدون ثبت‌نام برای مشتری‌هاش کار می‌کنه. پشت اون، پنل اختصاصی فروشگاه قرار داره با مدیریت سفارش‌ها، گزارش‌های تفصیلی فروش، تفکیک منبع سفارش بر اساس پلتفرم، و یک CRM برای نگه‌داشتن سابقه و ارتباط با مشتری. ساخته‌شده روی Laravel با رابط راست‌به‌چپ فارسی.

نتیجه

سفارش‌ها به‌جای پخش‌شدن بین چند پیام‌رسان، از یک مسیر مشخص وارد یک پنل می‌شن. سابقه‌ی هر مشتری تو CRM جمع می‌شه و برای هر سفارش معلومه از کدوم پلتفرم اومده — چیزی که قبلش اصلاً قابل اندازه‌گیری نبود.

چی یاد گرفتیم

وسوسه‌ی اولیه این بود که برای این فروشگاه‌ها «فروشگاه اینترنتی» ساخته بشه. ولی مسئله‌ی واقعی‌شون فروختن نبود، جمع‌کردن سفارش بود. یه لینک ثبت سفارش، مداخله‌ی خیلی کوچک‌تری از یه فروشگاه کامله و دقیقاً همون گلوگاه رو باز می‌کنه. درسِ ماندگارش این بود: قبل از ساختن، باید مطمئن شد داریم گلوگاه رو حل می‌کنیم، نه چیزی که ساختنش برای ما جذاب‌تره.

مسئله‌ی شما هم شبیه همینه؟

بگید کدوم بخش کارتون بیش‌تر از همه وقت می‌گیره. اولین جلسه رایگانه و خروجی‌اش یه فهرست مشخص از مسائل شماست.