دليل سوق طلب الطعام

إنشاء موقع طلب طعام مثل Yemeksepeti

إنشاء موقع طلب طعام مثل Yemeksepeti عمل مختلف عن تطبيق مطعم واحد: تُعرض عشرات المطابخ حسب موقعكم، ويُعتمد الطلب في المطبخ، وينفّذ التوصيل مطعم أو مندوبو المنصة. مع برمجية Softomi للأسواق يمكن إنشاء موقع يشبه Yemeksepeti من دون كتابة أكواد، فينتقل الوقت من تطوير البرمجيات إلى شبكة المطاعم وقواعد العمولة.

سوق مطاعم القائمة والتنوعات مندوبو المنصة العمولة والمستحقات منطقة التوصيل

ماذا يعني إنشاء موقع طلب طعام مثل Yemeksepeti؟

خلف رغبة «إنشاء موقع طلب طعام مثل Yemeksepeti» غالباً لا توجد واجهة مطعم واحد، بل سوق مطاعم يعرض عشرات المطابخ حسب موقع العميل. المنصة لا تحتفظ بالمخزون بنفسها؛ المطاعم هي البائع، وهي تدير القائمة، وأنتم تأخذون عمولة من كل طلب و(إن وُجدت) رسوم توصيل. يُسمّى هذا في القطاع منصة تجميع أو إنشاء موقع طلب طعام متعدد المطاعم.

يعمل هذا النموذج بمعزل عن التجارة الإلكترونية التقليدية وتطبيق المطعم الواحد. الطلب ليس ببساطة «متوفر / غير متوفر»: يجب أن تتضح معاً حالة فتح المطعم في تلك اللحظة، ومدة التجهيز، والتنوع المختار (حار، قليل النضج، إضافة مكوّن)، ونصف قطر التوصيل، ومن ينفّذ التسليم. وعلى برمجية طلب الطعام أونلاين أن تدير اعتماد المطبخ وقاعدة المنطقة بقدر ما تدير الكتالوج.

في نتائج البحث تختلط ثلاثة أشياء كثيراً. الأول تطبيق المطعم الخاص (هروباً من العمولة). والثاني تشغيل سوق متعدد المطاعم عبر بناء موقع يشبه Yemeksepeti أو تطبيق مشابه لـ Yemeksepeti. والثالث التجارة السريعة من نوع Getir التي تسلّم من مستودعها خلال دقائق. يركّز هذا الدليل على الثاني. لمعظم المشاريع التي تبدأ من الصفر تكون الخطوة الأولى الصحيحة سوق مطاعم بلا مخاطر مخزون.

إن كنتم جدداً على مفهوم السوق الإلكتروني، ابدأوا أولاً بقراءة صفحة ما هي برمجية السوق الإلكتروني؛ سيسهّل ذلك متابعة القواعد الخاصة بالطعام في هذا الدليل. ولجانب السوبرماركت السريع وdark store يمكنكم أيضاً الاطلاع على دليل إنشاء تطبيق وموقع مثل Getir.

Yemeksepeti بالأرقام: ماذا نما في 25 عاماً؟

إن اتّخذتم Yemeksepeti مثالاً فلا يكفي قول «الأكبر في تركيا». كيف نمت المنصة، ومتى بيعت، ومن أين يأتي الطلب اليوم — كل ذلك يؤثّر مباشرة في قرارات إصداركم الأول.

2001
سنة التأسيس — إسطنبول
589 M$
بيع 2015 لـ Delivery Hero
1,7 Mrd
الطلبات التراكمية (25 عاماً)
%96
حصة الطلب عبر الجوّال في 2025
2001

أسّسها في إسطنبول Nevzat Aydın وMelih Ödemiş وGökhan Akan وCem Nufusi. كانت السنوات الأولى مدينة واحدة وشبكة مطاعم محدودة.

2004–2008

وفق ما أعلنته الشركة ارتفع الطلب اليومي إلى ألف في 2004 وإلى 10 آلاف في 2008. وفي 2008 جاء استثمار European Founders Fund.

2013

أعلن Nevzat Aydın 2,2 مليون مستخدم مسجّل، وأكثر من 10 آلاف مطعم، ونحو 60 ألف طلب يومي.

2015

وفق ما نقلته Reuters اشترت Delivery Hero منصة Yemeksepeti بقيمة 589 مليون دولار. والمنصة منذ ذلك التاريخ جزء من هذه المجموعة.

2019–2022

افتُتح سوبرماركت Banabi السريع في 2019، وأصبح في 2022 باسم Yemeksepeti Market. وفي 2021 دخل Mahalle (التجار المحليون). ونما الذراع اللوجستي Yemeksepeti Express (سابقاً Vale) للمطاعم التي لا تملك مندوباً خاصاً.

2021

أُعلن عن هجوم سيبراني على أنظمة المعلومات وانتهاك لبيانات المستخدمين؛ وبدأت هيئة حماية البيانات الشخصية تحقيقاً. الدرس لمنصة جديدة واضح: بيانات الطلب والعنوان ومعلومات الدفع يجب أن تُحفظ بأمان منذ اليوم الأول.

2025–2026

وفق بيانات السنة الـ 25: 1,7 مليار طلب تراكمي، و37,6 مليون مستخدم، و13,2 مليون مستخدم نشط في 2025، و135.871 شريكاً في 81 ولاية. في 2014 كانت 64% من الطلبات تأتي من الويب، وفي 2025 بلغت حصة الجوّال 96%. وأعلنت الشركة أنها تعمل مع نحو 26 ألف مندوب نشط.

الدرس الذي يجب أن تستخلصوه من هذه الأرقام

عمّقت Yemeksepeti حضورها بين 2001 و2015 أولاً في إسطنبول ثم في تركيا؛ والانتشار إلى 81 ولاية لم يحدث في ليلة. وفي 2014 كانت معظم الطلبات ما تزال تأتي من الويب. حالة إنشاء تطبيق طلب طعام مثل Yemeksepeti التي ترونها اليوم بُنيت على سنوات من شبكة مطاعم ضيقة وموقع متوافق مع الجوّال. هدفكم الأول ليس 135 ألف شريك، بل وعد توصيل يُحترَم في حيّ واحد وطلب متكرر.

ثلاثة نماذج: مطعم واحد، سوق، وهجين

قراركم الأول هو الفصل بين ثلاثة أعمال تُذكر في الجملة نفسها تحت اسم «تطبيق طعام». احتياج رأس المال، ونطاق البرمجيات، وطريق اكتساب العملاء ليست واحدة.

المعيار تطبيق مطعم واحد سوق متعدد المطاعم هجين (سوق + مندوبو المنصة)
من البائع؟ منشأة واحدة — القائمة لديكم عشرات المطاعم — كل منها بائع المطاعم بائعة، والمندوب لكم أو مختلط
الإيراد هامش بيع الطعام (بلا عمولة) عمولة + توصيل/خدمة + واجهة عمولة + رسم خدمة لوجستية
قاعدة العملاء علامتكم أنتم — اكتساب العميل مكلف علامة المنصة — تنوّع المطاعم يجذب الواجهة نفسها، وتوصيل أكثر معيارية
التحكم بمدة التوصيل مرتفع — مطبخ واحد متوسط — يعتمد على إيقاع كل مطبخ أعلى — معيار المندوب لديكم
أكبر مخاطرة التطبيق لا يُنزَّل، والطلب لا يأتي انضباط المطعم وشكاوى العمولة تكلفة ثابتة للمندوب + برمجيات معقّدة
الملاءمة للإصدار الأول منشأة واحدة لديها عملاء أصلاً مشروع يريد إنشاء موقع مثل Yemeksepeti بعد تشكّل الكثافة

توصية عملية

إن كانت نية بحثكم بناء سوق مطاعم فلا تطلبوا تطوير تطبيق مطعم واحد؛ ذلك الطريق يقودكم إلى وعد «الهروب» من عمولة Yemeksepeti، لا إلى بناء سوق متعدد المطاعم. أدخلوا مطاعم المنطقة بائعين؛ وليُدِر كل منشأة قائمتها وطلباتها عبر لوحة بائع المطعم الخاصة بها. لا تُجبروا من لا يملك مندوباً على النظام من اليوم الأول؛ عند مجيء الكثافة أضيفوا مندوبي المنصة (من نوع Yemeksepeti Express) طبقة ثانية.

في تركيا أمثلة راسخة للنماذج الثلاثة. قناة المطعم الواحد هي تطبيقات السلاسل الخاصة. وعلى جانب سوق التجميع تقف Yemeksepeti. أما التسليم خلال دقائق من مستودعكم فهو التكوين الذي يتبادر عند ذكر Getir وإنشاء موقع مثل Getir للطعام. يمكن استخدام النواة البرمجية نفسها؛ نقطة الفصل هي عند من يكون المخزون والمطبخ والمندوب.

كيف تربح منصة طلب الطعام؟

البقاء على بند إيراد واحد في توصيل الطعام صعب، لأن لكل طلب تكلفة مطبخ ومندوب ملموسة. البنود الستة أدناه أكثر المصادر استخداماً عملياً.

عمولة المطعم

نسبة تُؤخذ من كل طلب. إن نفّذت المنصة التوصيل تُرفع النسبة عادة فوق طلب يذهب بمندوب المطعم نفسه.

رسوم التوصيل

مبلغ يُؤخذ من العميل. يمكن تعريفه على درجات حسب المسافة أو الساعة أو قيمة السلة.

رسم الخدمة

رسم خدمة صغير يظهر للعميل. إن لم يُكتب بشفافية أضرّ بثقة المطعم والعميل معاً.

الواجهة والإبراز

الظهور أعلى القائمة، أو خصم عميل جديد من نوع «Joker». بعد تشكّل الحجم يصبح أعلى البنود هامشاً.

المشاركة في الحملات

من يموّل كوبون الخصم يجب أن يُكتب منذ البداية. تنظيم 2026 يحظر إجبار المطعم على الحملة.

خدمة مندوبي المنصة

بيع التوصيل لمطعم بلا مندوب. Yemeksepeti Express المثال المعروف لهذه الطبقة.

قاعدة الشفافية 2026: يجب أن تكون جزءاً من برمجياتكم

ألزمت وزارة التجارة اعتباراً من 1 نيسان/أبريل 2026 منصات الطعام عبر الإنترنت بأن تعرض العمولة ورسوم المندوب والإعلان والحملة التي تأخذها من المطعم بنداً بنداً في لوحة البائع. لا يجوز إجبار المطعم على حملة أو إعلان؛ ولا تُفرَض عقوبة على منشأة ترفض المشاركة. وبُسِّط حساب العمولة أيضاً: إن لم يكن هناك خصم يُعتمد سعر المنتج؛ وإن قدّم المطعم وحده الخصم يُعتمد ما دفعه العميل فعلاً؛ وفي الخصم المشترك يُضاف إلى ما دفعه العميل الجزء الذي تحمّلته المنصة. هذه القاعدة كما نقلتها وكالة الأناضول لا تُؤجَّل في منصة جديدة بعبارة «نضيفها لاحقاً»؛ يجب أن تحمل لوحة بائع المطعم هذا الكشف من اليوم الأول.

في البداية ابنوا جدولاً بسيطاً بثنائي العمولة + رسوم التوصيل. فاتورة من خمسة بنود غامضة تُنفّر مطعماً يفكّر في الانضمام إلى منصة لم يثق بها بعد. أضيفوا إيرادات الواجهة والإبراز بعد استقرار تدفق طلبات منتظم.

لرؤية كيف تتجمع بنود الإيراد في نموذج السوق بمزيد من التفصيل يمكنكم مراجعة الأمثلة في صفحة كيف تُكسب المال من موقع السوق الإلكتروني.

الربح لكل طلب: رياضيات توصيل الطعام

قبل جمع المطاعم اكتبوا رياضيات الطلب على الورق. منصات الطعام غالباً لا تُغلق بسبب البرمجيات، بل لأنها تكتشف متأخراً أنها تخسر في كل طلب. الجدول سيناريو مثال؛ املؤوه بأرقام عمولتكم ومندوبكم. النسبة هنا ليست تعرفة رسمية لـ Yemeksepeti.

البند 3 تسليمات في الساعة 5 تسليمات في الساعة
متوسط قيمة السلة280 TL280 TL
عمولة المنصة (18%، مثال)50 TL50 TL
توصيل + رسم خدمة من العميل27 TL27 TL
الإيراد الإجمالي لكل طلب77 TL77 TL
تكلفة المندوب (135 TL للساعة إجمالاً)-45 TL-27 TL
عمولة بنية الدفع (2,5%)-7 TL-7 TL
حصة الإلغاء والطلب الخاطئ والتغليف-8 TL-8 TL
هامش المساهمة لكل طلب+17 TL+35 TL

الفرق الوحيد بين العمودين هو الكثافة: المندوب نفسه ينفّذ 5 تسليمات في الساعة بدل 3. في الطعام لا توفّر الكثافة ميزانية التسويق، بل منطقة ضيقة + انتظار مطبخ قصير. ثلاثة طلبات في الحي نفسه أجدى بكثير من ثلاثة طلبات موزّعة على ثلاثة أحياء. في طلب حرفي أمام مؤسسة أمين المظالم ادُعي أن العمولة والنقل معاً بلغتا 32%، ومع بنود إضافية 60%؛ هذا ليس تعرفة رسمية لكنه يبيّن حساسية جانب المطعم. أيّاً كانت نسبتكم، رؤية المطعم لكل بند في اللوحة اعتباراً من 2026 مسألة ثقة وتشريع معاً.

فخ خاص بالطعام: مدة المطبخ تُبقي المندوب منتظراً

في السوبرماركت المنتج على الرف؛ وفي الطعام المنتج لم يُطبخ بعد. إرسال المندوب مبكراً يُبقيه منتظراً، وتأخيره يبرّد الطعام. لذلك يجب أن تفصل البرمجية بين مدة التجهيز + مدة الطريق. مقاربة «لنزد عدد المدن أولاً» تضخّم الخسارة أيضاً إن كان الطلب يخسر. الهدف الأول هامش مساهمة موجب في حي واحد.

  • خذوا الحد الأدنى للسلة على محمل الجد. حصة واحدة + عنوان بعيد لا تغطي تكلفة المندوب.
  • كبّروا السلة. المشروب والإضافة واقتراح القائمة أكثر أدوات زيادة السلة طبيعية في الطعام.
  • أديروا ساعات الذروة. النطاق 12:00–14:00 و18:00–21:00 يحدّد خطة المندوبين كلها.
  • قيسوا نسبة الإلغاء و«غير متوفر». منتج يظهر في القائمة ولا يوجد في المطبخ يخسر المندوب والعميل معاً.

كيف تُبنى منطقة التوصيل ومدة المطبخ؟

في التجارة الإلكترونية التقليدية يأتي العنوان في خطوة الدفع. أما في طلب الطعام فالعنوان هو الخطوة الأولى: أي مطاعم تُعرض، والحد الأدنى للسلة، ورسوم التوصيل، والمدة الموعودة — كلها مرتبطة بالعنوان. وفوق ذلك تُضاف مدة التجهيز الخاصة بكل مطبخ.

يجب أن يحمل تعريف المنطقة والمطعم معاً هذه المعلومات السبع على الأقل:

  • حدود المنطقة: مساحة مرسومة على الخريطة أو قائمة أحياء. لا يُفتح الطلب خارج الحدود.
  • المطاعم التي تخدم المنطقة: إن خدمت مطابخ عدة العنوان نفسه فقاعدة الترتيب (المسافة، التقييم، مدة التجهيز، أو واجهة مدفوعة).
  • حالة الفتح/الإغلاق وساعات العمل: أخذ طلب من مطعم مغلق أشهر سبب للإلغاء.
  • وعد مدة التجهيز: المدة التي يحتاجها المطعم بعد قبول الطلب ليصبح جاهزاً للتسليم. هذه المدة هي محفّز إسناد المندوب.
  • الحد الأدنى للسلة ورسوم التوصيل: تعرفة متدرجة حسب المنطقة والساعة.
  • مدة التوصيل التقديرية: التجهيز + متوسط الطريق. وعد مدة مبالغ فيه أغلى خطأ.
  • تنوعات القائمة: حار، قليل/كثير النضج، إضافة مكوّن، منتج يُستبعد. في طلب الطعام هذه ليست «حقل مخزون» بل الطلب نفسه.

الميزة الملموسة للبداية الصغيرة

في الإصدار الأول تكفي 3–5 أحياء من منطقة واحدة و15–25 مطعماً. جملة «نخدم المدينة كلها» تبدو جيدة؛ ومدة توصيل لا تُحترَم لا تُعيد ذلك العميل. وفروق إيقاع المطابخ لا تتعلّمونها إلا في منطقة ضيقة.

هل يمكن إنشاء موقع يشبه Yemeksepeti من دون كتابة أكواد؟

عند ذكر «إنشاء تطبيق طلب طعام مثل Yemeksepeti» تسرد الوكالات غالباً تطبيقاً من الصفر بـ Flutter أو React Native. لكن اتفاق المطاعم وجدول العمولة وقاعدة المندوب يستغرق وقتاً بقدر البرمجيات. بنية تطبيق توصيل الطعام الجاهزة تختصر الكود إلى أسابيع وتترككم لعمل المطبخ والمنطقة.

تطوير مخصّص من الصفر

  • 6–18 شهراً؛ iOS وAndroid والعميل والمطعم والمندوب ولوحة الإدارة
  • تكلفة بداية بمئات الآلاف من الليرات
  • اعتماد مستمر على فريق تقني
  • عبء المستحقات وKVKK والصيانة عليكم
  • إنفاق ميزانية كبيرة قبل اختبار السوق

بنية سوق جاهزة

  • إطلاق خلال أسابيع
  • ميزانية بداية أدنى بوضوح
  • المطعم والطلب والتوصيل من اللوحة
  • تدفقات دفع ومستحقات مختبَرة
  • تكرار سريع وفق بيانات طلب حقيقية

المهم أن تلبي البنية التي تختارونها تشغيل الطعام فعلاً: طلب المطعم والموافقة، تنوع القائمة، تدفق حالات الطلب، العمولة والمستحقات، الإلغاء/الإرجاع، وسجلات التدقيق. لرؤية عمل اللوحات عملياً يمكنكم مشاهدة فيديوهاتنا التدريبية.

اطّلعوا فوراً على العرض التجريبي لمشروع سوق طلب الطعام

شاهد العرض التجريبي

الحد الأدنى من الميزات لـ MVP

هدف الإصدار الأول ليس تغطية كل ميزة، بل أن يسير الطلب من المطعم إلى العميل بلا عوائق. العناوين الستة أدناه نواة تطبيق توصيل الطعام.

لوحة بائع المطعم

  • تدفق الطلب والمستندات والموافقة
  • ساعات العمل وحالة الفتح/الإغلاق
  • عمولة لكل بائع وكشف البنود
  • شاشة قبول الطلب والتجهيز

القائمة والتنوعات

  • فئة وصورة وسعر
  • خيارات: حار، نضج، إضافة
  • إسقاط المنتج النافد من القائمة
  • رفع قائمة جماعي (Excel/CSV)

تدفق الطلب

  • موافقة، قيد التجهيز، في الطريق، تم التسليم
  • قاعدة رفض المطعم وتجاوز المدة
  • إشعار العميل بالرسائل النصية / البريد
  • السجل وإعادة الطلب

الدفع والمستحقات

  • حساب العمولة والخصومات
  • مقاصة الإلغاء / الإرجاع
  • تقرير رصيد المطعم (شفاف)
  • الدفع عند الاستلام + PayTR / iyzico

المندوب والتوصيل

  • مندوب المطعم أو مندوبو المنصة
  • الإسناد والحالة وتأكيد التسليم
  • مطابقة المنطقة
  • تسجيل مدة التجهيز والطريق

الثقة والتدقيق

  • سجلات العمليات ومسار التدقيق
  • مراجعة المطعم والقائمة
  • الطلب المزيف / فحص الاحتيال
  • KVKK: بيانات العنوان والدفع

ميزات يمكن تأجيلها في الإصدار الأول

تتبع المندوب بالثانية على خريطة حية، والمسار الآلي، والاقتراح المخصّص، ونقاط الولاء، وبطاقة الطعام (Sodexo/Multinet)، والتطبيق الأصلي. لا شيء من هذا يمنع أخذ أول 100 طلب؛ وكلها تؤخّر المشروع أسابيع.

من ينفّذ التوصيل؟ ثلاثة نماذج للمندوبين

تشغّل Yemeksepeti مندوب المطعم نفسه ومندوبي المنصة (Express) في النظام نفسه. لمنصة جديدة ثلاثة خيارات معقولة؛ ولستم مضطرين لبناء الثلاثة من اليوم الأول.

1

المطعم ينفّذ توصيله بنفسه (الأسهل لـ MVP)

لدى معظم مطاعم الحي مندوب دراجة أصلاً. تدير المنصة الطلب والدفع، وينفّذ المطعم التوصيل. لا تكلفة ثابتة عليكم؛ مقابل ذلك تختلف المدة وجودة التغليف من مطعم لآخر.

2

مجموعة مندوبي المنصة (من نوع Express)

لإدخال منشآت بلا مندوب وتوحيد المدة. بناؤها قبل تجاوز عتبة الكثافة أسرع بند يستنزف المال أجراً لمندوب ينتظر بلا طلب.

3

شركة مندوبين متعاقدة / 3PL

تكلفة لكل طلب بدل تكلفة ثابتة. يقلّل المخاطر حين يتذبذب الطلب؛ مقابل ذلك تتنازلون عن جزء من هامشكم. ويجب أن تبقي البرمجية سجل الإسناد والتسليم.

أيّاً كان النموذج الذي تختارونه، ما يجب أن تعرفه البرمجية واحد: الطلب عند أي مندوب، وما الحالة، وكم استغرق التجهيز، وكم بقي في الطريق. مدة توصيل لا تُقاس لا تُحسَّن. تأكدوا من عمل هذه السجلات قبل إضافة طبقة من نوع Yemeksepeti Express.

موقع أم تطبيق جوّال؟ أيهما يأتي أولاً؟

أعلنت Yemeksepeti في بيانات 2025 أن 96% من الطلبات جاءت من التطبيق الجوّال. أما في 2014 فكانت 64% من الطلبات تأتي من الموقع؛ وانعكست النسبة خلال العقد الأخير. أي أن المنصة نفسها نمت أولاً بالويب. إنشاء تطبيق طلب طعام صحيح على المدى الطويل؛ وليس شرطاً في الخطوة الأولى.

المعيار موقع متوافق مع الجوّال (PWA) تطبيق جوّال أصلي (native)
مدة الإطلاقأسابيعأشهر + إجراءات موافقة المتاجر
التكلفةمنخفضة — قاعدة كود واحدةمرتفعة — صيانة منفصلة لـ iOS وAndroid
الوصول إلى أول طلبفوري بمشاركة الرابطعائق التنزيل قائم
الإشعارات وإعادة الطلبمحدودة لكنها كافيةقوية — ميزة في الولاء
التوقيت الموصى بهالإصدار الأولبعد استقرار تدفق طلبات منتظم

الترتيب العملي كالآتي: افتحوا أولاً موقع طلب طعام متوافقاً مع الجوّال، خذوا طلبات حقيقية مع مطاعم الحي، وانظروا كم عميلاً عاد خلال 30 يوماً. إنشاء تطبيق طلب طعام يأتي بعد هذه البيانات؛ وإلا ارتبطت حسابات المتاجر وتكلفة الصيانة بنموذج لم يُختبَر بعد.

خطة الإطلاق في 10 خطوات

الترتيب أدناه معدّ للانطلاق من حي واحد والوصول إلى سوق طعام قابل للتوسع. ترتيب الخطوات مهم: كل خطوة تخفّض مخاطر التي تليها.

1

ضيّقوا المنطقة

منطقة واحدة، 3–5 أحياء. فضّلوا منطقة تصلون إلى تجّارها، وذروتها وقت الغداء والعشاء عالية. هذا القرار يؤثّر في فرص نجاح المشروع أكثر من مجموع الخطوات التسع الأخرى.

2

حدّدوا مزيج المطابخ ووعد المدة

شاورما، بيتزا، طبخ منزلي، حلويات: أي مطابخ ستكون في الواجهة الأولى؟ وكم دقيقة تعدون؟ قولوا مدة تستطيعون الوفاء بها. الوفاء بوعد 40–50 دقيقة أثمن من وعد 20 دقيقة لا يُحترَم.

3

حلّوا اقتصاد الوحدة على الورق

قبل بدء البرمجيات احسبوا هامش المساهمة لكل طلب: متوسط السلة، العمولة، رسوم التوصيل، المندوب وعمولة الدفع. إن كان الرقم سالباً صحّحوا النموذج أولاً.

4

أقنعوا أوائل المطاعم وجهاً لوجه

قابلوا 15–25 مطعماً في المنطقة. عرض عمولة مخفّضة أو فترة بلا عمولة لأوائل البائعين أقوى أداة. ابنوا العرض قبل البرمجيات.

5

اجعلوا جدول العمولة مكتوباً وشفافاً

العمولة، رسم المندوب، من يدفع الحملة، يوم الدفع، مقاصة الإلغاء. قاعدة 2026 تطلب أصلاً عرض هذه البنود بنداً بنداً في لوحة البائع. الرسم الغامض سبب مغادرة المطعم عند أول فرصة.

6

عرّفوا المنطقة والقائمة ومدد التجهيز

لكل حي: المطاعم، الحد الأدنى للسلة، رسوم التوصيل، ساعات العمل ومدة تجهيز المطبخ. يجب أن تعمل القائمة ذات التنوعات (حار، إضافة) من اليوم الأول؛ ترقيعها لاحقاً يزيد أخطاء الطلب.

7

ابنوا تدفق الدفع والمستحقات

اختاروا PayTR أو iyzico الداعمين لمستحقات البائعين الفرعيين؛ ولا تغلقوا الدفع عند الاستلام. رؤية المطعم رصيده وخصوماته من اللوحة حجر أساس الثقة.

8

اختاروا نموذج المندوب وقيسوا المدة

في المرحلة الأولى يكفي مندوب المطعم. أضيفوا مندوبي المنصة بعد مجيء الكثافة. سجّلوا من اليوم الأول مدة القبول والتجهيز والتسليم لكل طلب.

9

أطلقوا إطلاقاً محكوماً

ابدؤوا بمطاعم محدودة ومنطقة واحدة. في أول 100 طلب حدّدوا الاختناق: خطأ قائمة، قبول متأخر، أم تسليم بارد؟ حلّوا المشكلات قبل زيادة عدد المناطق.

10

ضاعفوا المنطقة الرابحة فقط

عندما تبلغون هامش مساهمة موجباً في حي، انقلوا التكوين نفسه إلى الحي المجاور. النمو نسخ قالب رابح؛ تضخيم قالب خاسر لا يفعل سوى توسيع الخسارة.

أي مؤشرات يجب أن تتابعوا؟

لا حاجة لتقارير معقّدة في توصيل الطعام. متابعة هذه المؤشرات الأربعة بانتظام في المرحلة المبكرة توجّه معظم قراراتكم.

مدة قبول المطعم والتجهيز

دقيقة قبول الطلب ومدة خروجه من المطبخ. القبول المتأخر بداية التسليم البارد والإلغاء.

مدة التوصيل (المتوسط وأبطأ 10%)

لا تنظروا إلى المتوسط بل إلى أبطأ الطلبات. خسارة العميل لا تحدث في المتوسط بل في ذلك الذيل.

إعادة الطلب وقيمة السلة

كم مرة عاد العميل نفسه خلال 30 يوماً أهم من تكلفة عميل جديد. تابعوا السلة وهامش المساهمة معاً.

نسبة الإلغاء والرفض و«غير متوفر»

رفض المطعم، ومنتج يظهر في القائمة ولا يوجد في المطبخ، وإلغاء العميل. أدق مؤشر مباشر لانضباط المطعم.

تابعوا هذه المؤشرات الأربعة أسبوعياً في الجدول نفسه. إن انخفض هامش المساهمة أو سرعة القبول بينما يرتفع عدد الطلبات، فهذا وقت وقف النمو ومراجعة تكوين المطعم والمنطقة.

ما الذي يجب أن يتغيّر في البنية مع نمو حجم الطلبات عالجناه في صفحة احتياجات برمجية السوق عالية الحجم.

بمَ تتغيّر تكلفة إنشاء موقع مثل Yemeksepeti؟

سؤال «تكلفة إنشاء موقع مثل Yemeksepeti» بلا جواب واحد، لأن أكبر بند يحدّد التكلفة غالباً ليس البرمجيات بل التشغيل. العوامل الأربعة أدناه تشكّل ميزانيتكم مباشرة.

النموذج الذي تختارونه

تطبيق مطعم واحد وبناء سوق مطاعم ليسا الميزانية نفسها. في النموذج متعدد البائعين تُضاف موافقة البائع والعمولة والمستحقات والمراجعة؛ مقابل ذلك لا تحملون مخاطر مخزون.

تشغيل التوصيل

هل ينقل المندوب المطعم، أم المنصة، أم شركة متعاقدة؟ فريق المندوبين الخاص يخلق تكلفة ثابتة وهو أسرع بند يستنزف المال عند انخفاض الحجم.

التكاملات

PayTR / iyzico، والخرائط والعنوان، والرسائل النصية، وبطاقة الطعام لاحقاً. كل تكامل إضافي ينعكس على الميزانية وقت تطوير واختبار.

نطاق الموقع + التطبيق

موقع متوافق مع الجوّال فقط، أم iOS وAndroid أيضاً؟ يضيف التطبيق إلى التطوير عبء صيانة مستمرة وإدارة متاجر.

يبدأ التطوير المخصّص من الصفر بمئات الآلاف من الليرات، بينما تتيح برمجية طلب الطعام أونلاين الجاهزة الانتقال إلى اختبار السوق في المنطقة الأولى خلال أسابيع وبميزانية أدنى بكثير. خصّصوا معظم ميزانيتكم لا للبرمجيات بل لكسب المطاعم وتجربة العميل الأولى.

لتفصيل الميزانية بنداً بنداً والجدول الزمني راجعوا صفحة تكلفة البرمجيات من الصفر وعمليات التخطيط.

لرؤية كيف تعمل اللوحات وتدفقات الإدارة يمكنكم الاطلاع على أكثر من 37 فيديو تدريبياً.

تعلّموا إدارة السوق خطوة بخطوة مع أكثر من 37 فيديو تدريبياً

شاهدوا فيديوهات التدريب

أسئلة شائعة

هل يشترط فريق مطورين لإنشاء موقع مثل Yemeksepeti؟

لا. ببرمجية سوق متعدد البائعين جاهزة يمكن ضبط لوحة بائع المطعم، والقائمة والتنوعات، واعتماد الطلب، والدفع والمستحقات، وتعريفات منطقة التوصيل من اللوحة. تظهر الحاجة إلى مطور في بنود مثل توجيه مسار المندوب المخصّص، أو تكامل شاشة المطبخ (KDS)، أو محرك حملات خاص. الحاسم ليس الفريق بل نطاق MVP واضح وقواعد عمولة مكتوبة.

كم تبلغ تكلفة إنشاء موقع مثل Yemeksepeti؟

البرمجيات ليست البند الوحيد الذي يحدّد التكلفة. هل تبنون تطبيق مطعم واحد أم سوقاً متعدد المطاعم، ومن ينفّذ التوصيل المطعم أم المنصة، والحاجة إلى تطبيق جوّال، وتكاملات الدفع — كلها تغيّر الميزانية مباشرة. يبدأ التطوير من الصفر بمئات الآلاف من الليرات، بينما تتيح البنية الجاهزة اختبار السوق في حيّ واحد بميزانية بداية أدنى بكثير.

هل تطبيق المطعم الواحد وموقع مثل Yemeksepeti الشيء نفسه؟

لا، وهذا الخلط من أغلى الأخطاء. تطبيق المطعم الواحد قناة تأخذ بها المنشأة الطلب مباشرة من عميلها؛ لا تدفع عمولة لكنها مضطرة لتوسيع قاعدة العملاء وحدها. أما إنشاء موقع مثل Yemeksepeti فسوق مطاعم تتنافس فيه عشرات المطاعم في واجهة واحدة، وتضع المنصة قواعد العمولة والتوصيل. احتياجات البرمجيات والتشغيل مختلفة.

لإنشاء تطبيق مثل Yemeksepeti هل التطبيق الجوّال شرط؟

التجربة الجوّالة حاسمة على المدى الطويل: أعلنت Yemeksepeti في بياناتها أنه اعتباراً من 2025 جاءت 96% من الطلبات من التطبيق الجوّال. ومع ذلك فإن تكليف تطوير iOS وAndroid أصليين في الإصدار الأول ترتيب خاطئ في معظم المشاريع. البدء بموقع متوافق مع الجوّال أو PWA ثم الاستثمار في التطبيق بعد تشكّل معدل إعادة الطلب أقل مخاطرة.

ماذا يجب أن تغطي لوحة بائع المطعم في الإصدار الأول؟

القائمة والسعر، وخيارات المنتج (حار، قليل النضج، إضافة مكوّن)، والفتح/الإغلاق وساعات العمل، وقبول/رفض الطلب، ومدة التجهيز، وتعليم غير المتوفر، وكشف المستحقات. ومن زاوية تنظيم الشفافية في 2026 يجب التفكير منذ البداية في أن يرى المطعم بنود العمولة والمندوب والإعلان بنداً بنداً من اللوحة.

هل ينفّذ التوصيل المطعم أم المنصة؟

أسهل طريق لـ MVP أن تنفّذ التوصيل مطاعم تملك مندوباً خاصاً. مجموعة مندوبي المنصة (من نوع Yemeksepeti Express) بعد تشكّل الكثافة توحّد المدة وتتيح إدخال منشآت بلا مندوب. النموذج الهجين يتطلّب برمجية تدير الاثنين معاً: يجب أن يظهر في كل سجل بأي نوع مندوب ذهب الطلب.

كيف أحدّد نسبة العمولة؟

لا توجد «نسبة صحيحة» ثابتة؛ تتغيّر حسب من ينفّذ التوصيل، ومن يموّل الحملة، وقيمة السلة. في شكاوى عكسها الرأي العام ادُعي أن العمولة والنقل معاً بلغتا نطاق 30%، وارتفعت أكثر ببنود إضافية؛ لا تعاملوها كتعرفة رسمية. واعتباراً من 1 نيسان/أبريل 2026 صار عرض المنصات كل الرسوم بنداً بنداً في لوحة البائع وعدم إجبار المطعم على الحملة جزءاً من تنظيم وزارة التجارة. ويجب أن تحمل برمجياتكم هذه الشفافية منذ البداية.

هل إنشاء موقع مثل Getir للطعام ونموذج Yemeksepeti الشيء نفسه؟

كلاهما توصيل طعام لكن التشغيل مختلف. نواة Yemeksepeti سوق تجميع يربط مطبخ المطعم وقائمته بالمنصة بوصفه بائعاً. وفي التوصيل السريع من نوع Getir تُقاس المدة بالدقائق؛ ويبرز عند من يكون المخزون وتجميع المنتجات. يمكن بناؤهما على النواة البرمجية نفسها؛ أما تدفق الطلب ومدة تجهيز المطبخ ووعد التوصيل فيجب تصميمها منفصلة.

كيف تنافس منصة جديدة وYemeksepeti موجودة؟

ليس بسباق مع 81 ولاية ومئات الآلاف من الشركاء. الطريق الواقعي: البدء في منطقة ضيقة (بضعة أحياء)، وواجهة خاصة بمطبخ تلك المنطقة، وعمولة أكثر شفافية، ومدة توصيل يمكن الوفاء بها. وعد «20 دقيقة» لا يُحترَم يخسر من العملاء أكثر من 40–50 دقيقة تُقال بصراحة. الهدف الأول ليس عدد المدن بل معدل إعادة الطلب في ذلك الحي.

أي بنية دفع يمكن استخدامها وكيف تعمل مستحقات المطعم؟

في تركيا تدعم بنى مثل iyzico وPayTR وPaynet توزيع مستحقات البائعين الفرعيين بما يناسب نموذج السوق. وفي طلب الطعام ما يزال النقد أو POS عند الباب شائعاً؛ إغلاقه من اليوم الأول يفقد التحويل. المهم أن تكون العمولة وتقاسم التوصيل ومقاصة الإلغاء والإرجاع مكتوبة، وأن يرى المطعم رصيده بشفافية من اللوحة.

لمزيد من الأسئلة يمكنكم أيضاً زيارة صفحة الأسئلة الشائعة.

أي باقة تناسبكم؟

لهذا النموذج في هذه الصفحة مساران رئيسان. يمكنكم مقارنة الباقات وفق عدد مناطقكم وعدد مطاعمكم وحجم الطلبات المستهدف والبدء بالنطاق الصحيح.

باقات مستوى البداية

لمشاريع تريد انطلاقة سريعة في منطقة واحدة ومطاعم محدودة.

  • التثبيت وتدفق الطلب الأساسي
  • إدخال أوائل المطاعم إلى اللوحة
  • توسيع التشغيل خطوة بخطوة
استعراض الباقات

باقات المستوى المتقدم

لمشاريع متعددة المناطق وعالية الحجم وذات حاجة إلى تكاملات.

  • عمليات وتكاملات متقدمة
  • تقارير وتدقيق تفصيليان
  • أهداف حجم طلبات مرتفع
استعراض الباقات

مع برمجية Softomi للأسواق يمكن إنشاء موقع طلب طعام من دون كتابة أكواد وإدارة تشغيل المطاعم من اللوحة. بعد اختيار الباقة يسير المسار: التثبيت، إعداد اللوحات، منطقة التوصيل، إدماج المطاعم وتكامل الدفع. لبحث مشروعكم يمكنكم ترك طلب عرض تجريبي أو التواصل هاتفياً مباشرة.

تواصل معنا الآن لمزيد من المعلومات

دعنا نحقق مشروع السوق الخاص بك معًا

تجريبي