الخلاصة التنفيذية
Baly يجمع في Listing العراق حجز الرحلات وتوصيل الطعام، مع تحديد مواقع، أنواع مركبات، طرق دفع، تقييم سائق، تتبع للطلب ومحفظة. كما يظهر Listing عراقي نشط وتحديثات حديثة عند التحقق. تجارياً، الدمج منطقي لأن الخدمتين تشتركان في المستخدم والخرائط والدفع والدعم، لكنهما لا تشتركان في العملية: رحلة راكب تختلف جذرياً عن طلب مطعم.
أكبر خطأ في مشروع مشابه هو بناء order عام لكل شيء. النقل يحتاج Matching فوري، تسعير رحلة وسلامة. الطعام يحتاج تاجر، قائمة، تحضير وسلسلة استلام. يجب أن يكون Shell مشتركاً والـDomains منفصلة.
مؤكد علناً: الخدمات والميزات من App Store العراق. استنتاج تحليلي: البنية والاقتصاديات أدناه نموذج للفئة، لا كشفاً لنظام Baly.
لماذا يجمع المنتج خدمتين؟
- تطبيق واحد واكتساب مستخدم مشترك.
- خرائط، هوية، محفظة، دعم وإشعارات مشتركة.
- فرص استخدام في أوقات مختلفة من اليوم.
- Cross-promotion بين الرحلات والطعام.
لكن جانب العرض مختلف: السائق المؤهل لنقل الركاب ليس بالضرورة مندوب طعام، ومتطلبات السيارة والسلامة والتسوية مختلفة. الدمج الأمامي لا يعني دمج كل Operations.
رحلة التاكسي
تحديد pickup/dropoff ← عرض فئة/سعر تقديري ← طلب ← Matching ← وصول السائق ← بدء الرحلة ← تتبع/سلامة ← إنهاء ← دفع/تقييم/دعم.
نقاط الفشل: GPS غير دقيق، Driver cancellation، عدم ظهور بيانات كافية، تغيير الوجهة، خلاف السعر، حادث أو غرض مفقود. لذلك تحتاج الرحلة إلى Event trail، قنوات Safety، وحالات دعم مرتبطة بالرحلة.
رحلة الطعام
مطعم وقائمة ← سلة ← قبول وتحضير ← مندوب ← استلام ← توصيل ← تسوية.
هنا يضاف Merchant/POS والمخزون والبدائل ووقت التحضير. إعادة استخدام تطبيق السائق ممكن تقنياً، لكن واجهة المهمة والقواعد والحوافز يجب أن تعرف نوع الخدمة.
نموذج العمل
تفاصيل عمولة Baly وإيراده غير منشورة ضمن مصدرنا. للفئة:
- Take rate أو رسم على الرحلة.
- رسوم خدمة/توصيل وعمولة تاجر للطعام.
- اشتراكات أو باقات سائق/عميل محتملة.
- Ads/placement للطعام.
- Wallet incentives.
لا تقيس نجاح الدمج بإجمالي الطلبات فقط. افصل Contribution وRetention وSupport لكل Domain، ثم قس Cross-service lift.
الاستراتيجية التسويقية
التموضع المنشور يركز على السهولة والتوفير. السعر أداة قوية لدخول سوق النقل، لكنه قد يجذب حساسية عالية ويضغط السائقين والوحدة الاقتصادية. الدفاع الأطول:
- توفر سائق موثوق وETA صادق.
- سلامة ودعم سريع.
- أسعار مفهومة بلا مفاجآت.
- تغطية دقيقة حسب المدينة والوقت.
- Merchant selection جيد في الطعام.
Referral مناسب لأن الرحلة تجربة قابلة للمشاركة، لكن يجب قياس Fraud وتكرار الأجهزة/طرق الدفع. عروض الطعام والنقل تحتاج Budgets وEligibility منفصلة.
البنية البرمجية
Shared platform
Identity، Profile، payment methods/wallet، maps abstraction، notifications، support، offers، analytics، consent وfraud signals.
Mobility domain
- Driver onboarding/documents/vehicle.
- Geospatial availability وMatching.
- Fare engine، ETA، trip state، safety events.
- Driver earnings وcash settlement.
Delivery domain
- Merchant catalog/POS.
- Order state، prep، courier dispatch.
- Inventory، substitutions، refunds وmerchant settlement.
Operations
لوحات منفصلة مع Command center مشترك. الصلاحيات تمنع موظف دعم الطعام من الوصول إلى بيانات غير لازمة في ملف السائق، والعكس.
Matching ليس "أقرب سائق"
اختيار الأقرب قد يرفع الإلغاء أو يترك منطقة بلا عرض. محرك التوزيع يوازن ETA، نوع المركبة، قبول السائق، اتجاهه، حدود المنطقة، العدالة، السلامة والحوافز. ابدأ بقواعد قابلة للتفسير، ثم استعمل نماذج عندما تتوفر بيانات صحيحة.
السلامة والثقة
أي منتج نقل يحتاج:
- تحقق هوية ووثائق مع إعادة تحقق.
- عرض السائق والمركبة ولوحة التسجيل للمستخدم.
- مشاركة رحلة/زر مساعدة وسياسة Incident واضحة.
- Masked calling إن أمكن.
- سجل تغييرات لا يمكن تعديله بصمت.
- فريق استجابة وتصعيد، لا Bot فقط.
هذه ليست Feature مؤجلة؛ هي شرط إطلاق.
العراق كبيئة تشغيل
- Landmarks وPickup confirmation مهمان.
- النقد يتطلب Ledger وتسوية للسائق والمندوب.
- تفاوت الاتصال والهواتف يستدعي تطبيقاً خفيفاً وRetry.
- اختلاف قواعد المدن والمطارات يجب أن يكون Config لا Hard-code.
- دعم عربي/كردي وتدريب السائق جزء من المنتج.
خارطة MVP
إذا كانت الأولوية نقل الركاب، أطلق Mobility وحده في Zone/مدينة مع Safety وSupport وSettlement. أضف الطعام بعد ثبات الشبكة أو كفريق Domain منفصل. إذا كانت لديك شبكة مطاعم أقوى، اعكس الترتيب. لا تطلق الخدمتين ضعيفتين معاً.
KPIs
النقل
Request-to-match، pickup ETA accuracy، driver/customer cancellation، completion، safety contacts، trips/active driver hour وContribution.
الطعام
Accept/prep/delivery time، cancellation reason، accuracy، repeat وContribution.
المنصة المشتركة
Cross-service adoption، Wallet usage، support contact rate، crash-free sessions وFraud loss.
أسئلة شائعة
هل نستخدم تطبيق سائق واحد للخدمتين؟
يمكن، إذا كان نوع المهمة واضحاً والقواعد والصلاحيات والمستحقات منفصلة. لا تجعل الواجهة معقدة لسائق يعمل في نوع واحد.
ما الأصعب: التاكسي أم الطعام؟
كلاهما صعب بطريقة مختلفة: التاكسي أعلى في السلامة والمطابقة الفورية؛ الطعام أعلى في تعدد الأطراف والقائمة والتحضير.
متى نضيف محفظة؟
عندما تحل مشكلة فعلية في الدفع/الحوافز/التسوية ويمكن إدارة الامتثال والأمن والمطابقة، لا لمجرد تسمية Super App.
قرار SUMIX
نبني Shared platform بحدود واضحة، ونختار Domain إطلاق واحداً يملك عرضاً وتشغيلاً كافيين. بعدها يصبح التوسع قرار بيانات لا شعاراً.
CTA: ناقش نظام التاكسي وإدارة الأسطول → /solutions/taxi-app مقال مرتبط: تحليل Careem في العراق
المصدر
*تحليل مستقل. Baly/بَلي وعلاماتها ملك أصحابها.*