الخلاصة التنفيذية
طلبات في العراق يقدّم وعداً بسيطاً للمستهلك—اختيار الطعام ومتابعته حتى الباب—ووعداً موازياً للمطعم: مبيعات ووصول وموارد تشغيل. لكن المنتج الحقيقي هو Marketplace بثلاثة أسواق مترابطة: العملاء، المطاعم، وقدرة التوصيل. نجاح الواجهة يعتمد على توازن هذه الأطراف داخل كل منطقة وكل ساعة.
الموقع العراقي الرسمي يعرض التسجيل، اكتشاف المطاعم، السلة، العنوان، التتبع، العروض ووضوح الرسوم. كما تعرض Sitemap الرسمية صفحات مدن عراقية متعددة. هذا يثبت اتساع الحضور الرقمي، لكنه لا يثبت وحده كثافة الطلب أو الحصة السوقية في كل مدينة.
مؤكد علناً: الوظائف والتغطية الرقمية مأخوذة من صفحات طلبات الرسمية. استنتاج تحليلي: المحركات التقنية وEconomics أدناه نموذج مطلوب لفئة Marketplace، لا وصف لكود طلبات الداخلي.
المنتج من زاوية كل طرف
العميل
يشتري تنوعاً، اكتشافاً، سعراً معروفاً، وطمأنينة التتبع والدعم.
المطعم
يشتري اكتساباً رقمياً وطلبات إضافية، لكنه يدفع كلفة اقتصادية وتشغيلية: تحديث القائمة، الالتزام بالتحضير، معالجة الاستثناءات وربما العروض.
شبكة التوصيل
تحول الطلب إلى رحلة مادية. هدفها ليس أقصر طريق منفرد دائماً، بل أعلى إكمال ضمن وقت وتكلفة ومناطق وقواعد سلامة.
المنصة
تدير الاكتشاف والتسعير والثقة والتوازن. إذا كان المطعم ممتازاً لكن لا يوجد مندوب، فشل الوعد. وإذا وصل المندوب قبل التحضير، ترتفع كلفة الانتظار.
نموذج الربح: ما نعرفه وما لا نعرفه
لا ننشر عمولات طلبات أو CAC/LTV في العراق بلا إفصاح مباشر. نموذج الفئة قد يجمع عمولة، رسوم خدمة/توصيل، ظهوراً إعلانياً، اشتراكات أو خدمات للتاجر. يجب فصل:
- GMV عن إيراد المنصة.
- إيراد الطلب عن Contribution بعد الدعم والحوافز.
- نمو الطلبات المدفوع بالخصم عن الاحتفاظ العضوي.
المشكلة الشائعة في مشروع جديد هي تسعير رسوم منخفضة لكسب المستخدم من دون معرفة كلفة الكيلومتر والانتظار والإلغاء وإعادة المحاولة.
التسويق: الطلب القريب أهم من الجمهور الكبير
في Marketplace محلي، إعلان وطني لا يعالج نقص المطاعم في حي محدد. النمو يعمل جغرافياً:
- اجلب مطاعم Anchor يبحث عنها الناس.
- ابنِ عرضاً كافياً في Zone صغيرة.
- ضمن قدرة التوصيل في ساعات الذروة.
- وجّه الإعلان إلى سكان المنطقة.
- استخدم تجربة أولى جيدة لإعادة الطلب.
العروض مفيدة لتنشيط أول طلب أو وقت هادئ، لكنها تصبح خطرة إذا عودت العميل على سعر غير مستدام. الاحتفاظ الأقوى يأتي من دقة القائمة، وقت موثوق، دعم سريع، ومفضلات/إعادة طلب.
نظام الاكتشاف والترتيب
أي منصة من هذه الفئة تحتاج Ranking يوازن، لا مجرد الأكثر مبيعاً:
- ملاءمة الموقع وساعات العمل.
- نوع المطبخ والبحث.
- ETA والتوفر.
- الجودة وموثوقية القبول.
- تفضيلات العميل.
- الظهور المدفوع مع Label واضح.
قرار أخلاقي وتجاري: إذا خلطت الإعلان بالترتيب الطبيعي بلا شفافية، قد تحصل على إيراد قصير وتخسر ثقة المستخدم وجودة الاختيار.
البنية البرمجية المتوقعة للفئة
- Merchant catalog مع فروع وقوائم وتوفر وإضافات.
- Search/Index يدعم العربية، اختلافات الكتابة والموقع.
- Cart/Pricing engine للرسوم والحد الأدنى والكوبون والضرائب إن وجدت.
- Order orchestration مع حالات وإلغاءات وتعويضات.
- Prep-time prediction وCourier dispatch.
- Tracking، Notifications، masked communication ودعم.
- Merchant portal/POS وCourier app وOperations console.
- Ledger للتسويات والعمولات وCOD، لا مجرد عمود
balance. - Experimentation وFeature flags مع Guardrails تشغيلية.
التعقيد الذي لا يظهر في الشاشة
مزامنة التحضير والمندوب
تعيين مبكر يعني انتظاراً؛ متأخر يعني طعاماً بارداً. يجب قياس Ready-at، وقت وصول المندوب، والانحراف حسب المطعم والساعة.
الاستثناءات
صنف نافد، عنوان غير دقيق، مطعم مغلق، مندوب انسحب، عميل لا يجيب. لكل حالة Owner وTimeout وخيار حل وتعويض وسجل.
التسوية
المطعم، المندوب والمنصة لكل منهم مستحقات وخصومات وتسويات. Ledger قابل للتدقيق أهم من Dashboard جميلة.
بناء نسخة مناسبة للعراق
- ابدأ بمدينة أو Zone ذات كثافة، لا خريطة وطنية فارغة.
- اعتمد Pin + landmark + تعليمات، ولا تفترض عناوين معيارية.
- ادعم COD من اليوم الأول إذا كان نموذج الإطلاق يحتاجه، مع تسوية يومية/دورية.
- جهّز POS أو Merchant app يتحمل شبكة ضعيفة وتنبيهاً احتياطياً.
- اجعل العربية طبيعية، وأضف الكردية عندما تخدم مدناً تتطلبها فعلياً.
خارطة MVP
0–1: 30–50 متجراً فعلياً في منطقة محددة، قائمة دقيقة، طلب، COD، قبول وتحضير، تعيين وتتبع ودعم. 1–10: مناطق، تسويات، تقارير، عروض مضبوطة، Search أفضل، مراقبة SLA. 10–100: Prediction، Batching، Personalization، Sponsored discovery وضبط احتيال.
الأرقام أعلاه نطاق تخطيط تشغيلي توضيحي، وليست وصفاً لطلبات ولا وعداً بنتيجة.
KPIs
- Search-to-menu وMenu-to-cart وCart-to-order.
- Availability rate وOrder acceptance.
- ETA accuracy لا متوسط ETA وحده.
- Late rate حسب سبب التأخير.
- Cancellation/refund وContact rate.
- 30/60-day reorder cohort.
- Merchant active rate وCatalog accuracy.
- Contribution per order/zone/time window.
أسئلة شائعة
هل كثرة المطاعم تكفي للفوز؟
لا. الاختيار غير المتوفر أو البطيء يضر أكثر مما ينفع. جودة العرض وكثافته داخل المنطقة أهم من رقم إجمالي تسويقي.
هل نحتاج ذكاء اصطناعي من البداية؟
لا. قواعد تشغيل واضحة وبيانات صحيحة أولاً. التنبؤ يصبح مفيداً بعد توفر تاريخ كافٍ وقياس للخطأ.
هل يمكن للمطعم استخدام هاتف فقط؟
نعم في الحجم الصغير، لكن POS/Tablet مع طابعة وتنبيه وFallback يقلل الطلبات المفقودة عند الذروة.
قرار SUMIX
قبل بناء Marketplace، نحدد Zone والسيولة المطلوبة لكل طرف ودورة الاستثناء والتسوية. هذا يحول الفكرة من "قائمة مطاعم" إلى نظام قابل للتشغيل والقياس.
CTA: صمّم منصة التوصيل الخاصة بسوقك → /solutions/delivery-app مقال مرتبط: تحليل Toters: التوصيل متعدد الفئات
المصادر
*تحليل مستقل. talabat/طلبات وعلاماتها ملك أصحابها.*