تبدو معظم تطبيقات التوصيل بسيطة من الخارج. يختار العميل مطعمًا، ويدفع، ثم يصل المندوب. لكن خلف هذه الخطوة عميل وتاجر ومندوب وفريق تشغيل، ولكل منهم شاشاته وقواعده ورؤية مباشرة للطلب نفسه.
هذا بالضبط هو شكل 3nnak، منصة توصيل عند الطلب قمنا ببنائها وتغطي المطاعم والمتاجر والصيدليات والأعمال المحلية، مع طرق دفع متعددة وشبكة مندوبين مخصصة. المشاريع من هذا النوع لا تفشل بسبب سوء البرمجة بقدر ما تفشل بسبب قرارات تم تجاهلها في البداية. وهكذا نفكر فيها.
في هذا الدليل ستتعرف على:
- لماذا تُعد منصة التوصيل عدة منتجات تتشارك طلبًا واحدًا
- كيف تقسّم الأدوار والتطبيقات والمسؤوليات قبل بدء التطوير
- أي القرارات يجب حسمها قبل طلب عرض السعر
إذا كنت تخطط لسوق إلكتروني أو منتج توصيل، فسيوفر عليك هذا الدليل إعادة بناء مكلفة أكثر من مرة.
جدول المحتويات
1. لماذا تُعد منصة التوصيل أربعة منتجات في منتج واحد
يضم نظام 3nnak تطبيقات ويب وجوال للعملاء، ولوحات تحكم للتجار، وتطبيقات لإدارة المتاجر، وتطبيقات للمندوبين، وبوابة إدارة مركزية. هذا ليس توسعًا في المزايا بلا داعٍ، بل هو الحد الأدنى الذي يحتاجه نشاط التوصيل ليعمل.
كل فئة تريد شيئًا مختلفًا من الطلب نفسه:
- العملاء يريدون التصفح والدفع والتتبع.
- التجار يريدون قبول الطلب وتجهيزه وتحديده كجاهز.
- المندوبون يريدون نقطة استلام واضحة ومسارًا وتسليمًا مؤكدًا.
- فريق التشغيل يريد رؤية شاملة وتحكمًا وطريقة لحل المشكلات.
إذا خصصت ميزانيتك لـ "تطبيق" واحد فقط، فقد غطيت ربع العمل تقريبًا. نقول هذا للعملاء في أول مكالمة، لأن المفاجأة لاحقًا أغلى بكثير.
2. حدد الأدوار قبل كتابة الكود
قبل أي تصميم نكتب كل دور والإجراءات الخمسة أو الستة التي ينفذها. يبدو الأمر بديهيًا، لكنه يمنع أكثر خلافات النطاق شيوعًا: ميزة "من الواضح" أنها تتبع جهة ما، دون أن يتفق أحد على أي جهة.
- 1العميل يطلبالسلة والدفع
- 2التاجر يقبللوحة المتجر
- 3تعيين مندوبتطبيق المندوب
- 4تم التسليمتسليم مؤكد
- 5إشراف الإدارةالبوابة المركزية
مثال توضيحي
نصيحة: ارسم دورة حياة الطلب على صفحة واحدة وحدد الدور المسؤول عن كل تغيير في الحالة. أي حالة بلا مسؤول هي خلل ينتظر الظهور.
3. خادم واحد وتطبيقات متعددة
خمس واجهات لا تعني خمس مجموعات من منطق العمل. نحتفظ بالقواعد (التسعير وحالات الطلب والصلاحيات والإشعارات) في مكان واحد، ونجعل كل تطبيق واجهة خفيفة مخصصة للدور فوقها.
| الأسلوب | الميزة | الخطر |
|---|---|---|
| خادم مشترك وتطبيقات حسب الدور | اتساق القواعد وتعديلات أسرع | يحتاج تصميم صلاحيات دقيقًا |
| خادم منفصل لكل تطبيق | استقلال الفرق | تتباعد المنطقيات وتتضاعف الأخطاء |
| تطبيق واحد لكل الأدوار | الأرخص في البداية | تجربة مربكة وصعوبة في التأمين |
في منصة تضم عملاء وتجارًا ومندوبين، يفوز الخيار الأول في أغلب الحالات. فتغيير رسوم التوصيل أو حالة الطلب يتم مرة واحدة لا خمس مرات.
4. الطلبات والدفع والتوزيع
هناك ثلاثة مجالات تستحق وقتًا في التصميم أكثر مما تناله عادة.
4.1 حالات الطلب
عرّف كل حالة (تم الطلب، تم القبول، قيد التجهيز، تم الاستلام، تم التسليم، ملغي) وكل انتقال مسموح بينها. الحالات الاستثنائية مثل رفض التاجر للطلب بعد الدفع يجب تصميمها لا اكتشافها.
4.2 الدفع
تقدم 3nnak عدة طرق دفع آمنة. التنوع مفيد للتحويل، لكن كل طريقة تضيف تسويات واسترجاعات ومعالجة للأعطال. حدد الطرق التي تحتاجها فعلًا عند الإطلاق.
4.3 التوزيع
مطابقة الطلبات مع شبكة مندوبين مخصصة مشكلة قائمة بذاتها: التوفر والتعيين وما يحدث عندما لا يستجيب المندوب. ابدأ بقواعد بسيطة ومتوقعة قبل التفكير في التحسين.
5. دعم الطلبات خارج القائمة
إلى جانب الطلب التقليدي، تتيح 3nnak للعملاء طلب منتجات من أي موقع تقريبًا، ويتولى مندوب التوصيل عملية الشراء كاملة نيابة عنهم. هذا مسار مختلف: لا يوجد كتالوج ثابت، لذلك قد يتم تأكيد السعر والصنف أثناء التنفيذ.
الدرس هو التعامل معه كنوع طلب أساسي منذ البداية. إضافة طلب حر إلى نموذج طلبات قائم على القوائم لاحقًا تعني غالبًا إعادة العمل على الحالات ومسار الدفع وتطبيق المندوب معًا.
نصيحة: إذا توقعت أنك ستحتاج نوع طلب ثانيًا لاحقًا، فأخبر فريق التطوير الآن. التصميم له يكلف ساعات، أما تعديله لاحقًا فيكلف أسابيع.
6. ما يجب حسمه قبل البناء
قبل أن تطلب عرض سعر من أي شركة، حدد ما يلي:
- الأدوار: من يستخدم المنصة، وماذا يستطيع كل منهم أن يفعل؟
- أنواع الطلبات: طلبات عادية فقط، أم طلبات مخصصة أيضًا؟
- الدفع: ما الطرق المطلوبة منذ اليوم الأول؟
- التشغيل: ماذا يحتاج فريق الإدارة أن يراه ويتحكم فيه؟
- نطاق الإطلاق: أي التطبيقات تصدر أولًا وأيها يتبعها؟
الإجابات الواضحة هنا تحول التقدير الغامض إلى تقدير يمكن الاعتماد عليه. وإذا أردت رأيًا ثانيًا في فكرة منصتك، فيسعد فريقنا بمناقشتها معك.
7. الأسئلة الشائعة
كم تطبيقًا تحتاج منصة التوصيل؟
على الأقل تطبيق للعميل، وواجهة للتاجر أو المتجر، وتطبيق للمندوب، وبوابة إدارة. تضم 3nnak كل ذلك، مع تطبيقات للعملاء على الويب والجوال.
هل يجب أن تتشارك كل الأدوار خادمًا واحدًا؟
في أغلب الحالات نعم. الخادم المشترك يحافظ على اتساق التسعير وحالات الطلب والصلاحيات، بينما يبقى كل تطبيق واجهة مركزة على دور محدد.
هل يمكن لمنصة التوصيل دعم طلبات الشراء المخصصة؟
نعم. تتيح 3nnak للعملاء طلب منتجات من أي موقع تقريبًا ويتولى مندوب عملية الشراء. ويكون الأداء أفضل عند تصميمها كنوع طلب مستقل منذ البداية.
ما الذي يجب حسمه قبل طلب عرض سعر؟
حدد الأدوار وأنواع الطلبات وطرق الدفع المطلوبة واحتياجات الإدارة والتطبيقات التي ستصدر أولًا. الإجابات الواضحة تعطي تقديرًا أدق بكثير.
الخاتمة
تنجح منصة التوصيل عندما يكون لكل دور مهمة واضحة ولكل طلب مسؤول واضح في كل خطوة. التقنية هي الجزء الأسهل. أما القرارات حول الأدوار والحالات والنطاق فهي التي تحسم نجاح المشروع أو فشله.
ومع توسع الخدمات عند الطلب إلى فئات جديدة، ستنجز الفرق التي تخطط للمنظومة كاملة مبكرًا أسرع ممن يرقّعونها لاحقًا.
💬 أي دور في منصتك يقلقك أكثر: العملاء أم التجار أم المندوبون أم التشغيل؟
التعليقات