تكلفة تطبيق توصيل الطلبات في الإمارات: من تطبيق العميل إلى لوحة تحكم فريقك

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

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

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

ذات صلة:تكلفة تصميم تطبيق جوال في الإمارات

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

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

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

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

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

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

وتتعلق الميزة الثالثة بالدفع. فالدفع بالبطاقة يمر عبر بوابة دفع، ويجب أن يتعامل التطبيق مع استرداد المبالغ والدفعات المرفوضة كما يتعامل مع الدفعات الناجحة. ولا يزال كثير من العملاء في الإمارات يفضلون الدفع عند الاستلام، وهذا يضيف عملًا تغفله أغلب العروض: فتطبيق المندوب يحفظ المبلغ الذي استلمه في كل طلب، ولوحة التحكم تعرض ما على كل مندوب من نقد في نهاية ورديته.

وتتراكم الميزات الصغيرة أيضًا، مثل مواعيد التوصيل، وإثبات التسليم بصورة أو برمز.

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

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

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

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

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

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

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

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

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

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

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

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

ذات صلة:تطبيقات الموبايل