مطالعهٔ موردی · ۲۰۲۵
ثبت سفارش و داشبورد زندهٔ فروش برای یک بازرگانی آیفون
سه ربات تلگرامی، مدیریت دسترسی و احراز هویت و فرم ۱۹ مرحلهای ثبت سفارش را از هم جدا میکنند. سفارشها در PostgreSQL ثبت میشوند و روی داشبوردی مینشینند که هر ده ثانیه خودش را بهروز میکند.
- نقش
- فریلنس، از ابتدا تا انتها: رباتها، اتوماسیون، دیتابیس و داشبورد
- مدت
- ۲۰۲۵
- کارفرما
- بازرگانی فروش آیفون — ۲ ادمین، ۱۳ فروشنده، ۳ سرپرست فروش
مسئله
سفارشها اول در دفتر نوشته میشدند و بعد در گروههای تلگرامی قرار میگرفتند. ثبت هر سفارش حدود پانزده دقیقه طول میکشید، بعضیشان جایی بین دفتر و گروه گم میشدند، و خطا در ثبت اطلاعات عادی بود. هیچکس بدون جمعکردن گزارش فروشندهها و سرپرستها نمیتوانست بگوید وضعیت فروش چیست — گزارشهایی که گاهی با هم تناقض داشتند و رسیدنشان به مدیر ساعتها طول میکشید.
محدودیتها
- فقط ادمینهایی که مدیر مجاز کرده بود میتوانستند سفارش ثبت کنند.
- هر سفارش باید هویت فردی را که ثبتش کرده با خودش حمل میکرد.
- ثبت باید سریع و مرحلهبهمرحله میبود، نه یک فرم بلند.
- فرم باید بر اساس پاسخهای قبلی تغییر میکرد، نه اینکه همهچیز را بپرسد.
- اطلاعات باید در یک جای مرکزی و ساختاریافته ذخیره میشدند.
- گزارشگیری نباید به ارسال دستی گزارش توسط کسی وابسته میبود.
- مدیر باید وضعیت فروش را بدون درخواست و هماهنگی میدید.
- داشبورد باید اطلاعات جدید را بدون Refresh دستی نشان میداد.
تصمیمهایی که شکلش دادند
سه ربات، سه مسئولیت مشخص
بهجای یک ربات که همهکار میکند، سیستم از یک ربات مدیریت — که ادمینها را بر اساس شمارهٔ موبایل تعریف یا حذف میکند — یک ربات احراز هویت، و یک ربات ثبت سفارش که فقط برای ادمین احرازشده باز میشود تشکیل شده. مدیریت دسترسی، هویت و ثبت اطلاعات سه چیز جدا میمانند، و تغییر یکی به معنی دستزدن به دو تای دیگر نیست.
نوزده مرحله، بعد یک بازبینی
ثبت سفارش یک گفتوگوی ۱۹ مرحلهای است: سرپرست، فروشنده، خریدار، شمارهٔ تماس، مدل، رنگ، حافظه، کد سفارش، قیمت، مبلغ پرداختشده، پلن خرید، روش پرداخت، تاریخ و ساعت، نوع تحویل، آدرس در صورت نیاز، و توضیحات. در پایان، ادمین تمام سفارش را یکجا میبیند و میتواند به هر مرحله برگردد و اصلاحش کند. تا پیش از آن تأیید نهایی، هیچ چیزی در دیتابیس نوشته نمیشود.
فرم واقعاً داینامیک است
فرم مجموعهای از فیلدهای ثابت نیست. تحویل حضوری اصلاً آدرس و کد پستی نمیپرسد. مدل آیفونی که انتخاب میشود تعیین میکند چه رنگها و چه حافظههایی پیشنهاد شوند. پلن خرید روی منطق زمان تحویل اثر میگذارد. ادمین فقط به چیزی پاسخ میدهد که همین سفارش واقعاً لازم دارد.
PostgreSQL بهعنوان تنها مرجع
سفارشها در یک ساختار PostgreSQL که برای همین کسبوکار طراحی شده ذخیره میشوند، و هر سفارش علاوه بر مشتری و محصول، به ادمینی که ثبتش کرده هم متصل است. همین اتصال است که داده را داخل جریان فروش قابل پیگیری میکند، نه انبوهی از رکوردهای مستقل.
n8n میان رباتها و داده
n8n لایهٔ اتوماسیون است: آنچه تلگرام میفرستد را میگیرد، منطق لازم را اعمال میکند، و پس از تأیید نهایی در PostgreSQL مینویسد. همین چیزی است که یک روال دستی چندمرحلهای را به یک جریان مشخص با یک نقطهٔ تغییر تبدیل کرد.
دیتابیس تبدیل به داشبورد میشود
دادهای که فقط داخل دیتابیس میماند یعنی هیچ دیدی وجود ندارد؛ به همین دلیل سیستم وبسایت و داشبورد اختصاصی خودش را هم دارد که مستقیماً به داده وصل است و هر ده ثانیه بهروز میشود. تعداد کل فروش، مبلغ فروش، مبالغ دریافتشده، مانده حسابها، زمانبندی تحویل، نزدیکترین سفارشهای پیشرو، فروش هر فروشنده و هر سرپرست و تیمش را نشان میدهد، همراه با نمودار، فیلتر و بازههای زمانی.
چه چیزی تحویل شد
- ربات مدیریت که ادمینها را بر اساس شمارهٔ موبایل تعریف و حذف میکند
- ربات احراز هویت، با بررسی دسترسی در برابر شمارههای مجاز
- ربات ثبت سفارش با فرایند ۱۹ مرحلهای
- پیشنمایش کامل سفارش با امکان ویرایش هر مرحله پیش از ثبت نهایی
- گزینههای رنگ و حافظه وابسته به مدل، و منطق تحویل وابسته به پلن خرید
- ذخیرهسازی متمرکز در PostgreSQL، با اتصال هر سفارش به ادمین ثبتکنندهاش
- اتوماسیون کامل کل فرایند در n8n
- وبسایت و داشبورد که مستقیم داده را میخوانند و هر ۱۰ ثانیه بهروز میشوند
- گزارش فروش و وضعیت پرداخت، بههمراه عملکرد هر فروشنده و هر سرپرست
- فیلتر، دستهبندی، مرتبسازی، نمودارهای فروش و فیلترهای زمانی
چیز مشابهی روی میزتان هست؟
محدودیتی که زیر آن کار میکنید را بگویید تا بگویم این رویکرد به کارتان میآید یا نه.