أريد إنشاء تطبيق وموقع مثل Getir

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

جدول زمني موجز من التأسيس حتى اليوم

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

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

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

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

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

هذا أهم أجزاء الدليل. فمعظم مشاريع التوصيل السريع لا تُغلق بسبب التسويق أو البرمجيات، بل لأنها اكتشفت متأخراً أنها تخسر في كل طلب. الجدول أدناه سيناريو نموذجي؛ صُمّم لتملؤوه بأرقامكم.

الفرق الوحيد بين عمودي الجدول هو الكثافة: المندوب نفسه ينفّذ 5 تسليمات في الساعة بدل 3. يرتفع هامش المساهمة لكل طلب من 2 TL إلى 18 TL. والكثافة لا تُصنع بميزانية تسويق بل بتضييق منطقة التوصيل. ثلاثة طلبات متجاورة في الحي نفسه أجدى بكثير من ثلاثة طلبات في ثلاث مناطق مختلفة.

• خذوا الحد الأدنى للسلة على محمل الجد. الطلب الذي لا يغطّي تكلفة المندوب يعني خسارة مع كل طلب يرد.
• اسعوا لرفع قيمة السلة. اقتراح المنتجات المكملة، والباقات الترويجية، وعتبة التوصيل المجاني أقوى الأدوات.
• أديروا ساعات الذروة. الطلب بين 18:00 و21:00 يحدّد تخطيط المندوبين بالكامل.
• قيسوا تكلفة الإلغاء. الطلب الملغى لأن المنتج غير موجود يخسّركم المندوب والعميل معاً.

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

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

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

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

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

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

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

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

في التوصيل السريع يأتي معظم الطلبات من عملاء متكررين، والعميل المتكرر يحب التطبيق الجوّال. ومع ذلك فإن تكليف تطوير تطبيق في الخطوة الأولى ترتيب خاطئ في معظم المشاريع.

توصيتنا واضحة: أطلقوا بموقع متوافق مع الجوّال، خذوا مئات الطلبات الأولى، وقيسوا معدل إعادة الطلب. استثمروا في التطبيق بعد رؤية هذه البيانات. هكذا تطوّرون التطبيق وأنتم تعلمون أن الطلب موجود، لا على أمل «ربما ينجح».

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

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

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

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

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

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

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

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

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

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