تعتمد تكلفة تطبيق توصيل في السعودية على نموذج التشغيل وأدوار المستخدمين وطريقة إسناد الطلبات. تبدأ باقات تطبيقات الجوال العامة لدى تكنوستاك، كما في أكتوبر 2026، من 20,000 و40,000 و70,000 ريال قبل الضريبة حيث تنطبق. هذه أسعار بداية لنطاقات محددة؛ يحتاج تطبيق التوصيل إلى تقييم مستقل قبل تحديد سعره، خصوصًا إذا جمع مطاعم متعددة ومندوبين وتسويات مالية.
ابدأ بوصف الطلب من لحظة اختياره حتى تسليمه. حدّد من يقبل الطلب، ومن يتواصل مع العميل عند التأخير، ومن يعتمد الاسترداد. بهذه التفاصيل تستطيع مقارنة عروض تتناول العمل نفسه، بدل مقارنة أسماء باقات تخفي وراءها مسؤوليات مختلفة.
استخدم سعر الباقة مرجعًا لنطاق البداية، ثم اطلب تحديد الإضافات التي يحتاجها مشروعك. يوضح كتالوج تكنوستاك وتفاصيل خدمة الجوال الحدود التالية كما في أكتوبر 2026. الأسعار لمشروعات تطبيقات عامة، ولا تمثل عرضًا جاهزًا لسوق مطاعم أو منظومة توصيل كاملة.
| الباقة العامة | سعر البداية قبل الضريبة حيث تنطبق | حدود تساعدك على مقارنة النطاق |
|---|---|---|
| التطبيق المركّز | 20,000 ريال | حتى 10 شاشات، ودور مستخدم واحد، وربطان مع واجهات موثقة قائمة |
| التطبيق متعدد المنصات | 40,000 ريال | حتى 25 شاشة بلغتين، ولوحة إدارة لثلاثة أنواع سجلات كحد أقصى، وحتى 3 تكاملات |
| المنتج المتكامل | 70,000 ريال | حتى 25 شاشة بلغتين، وحتى 3 أدوار مستخدمين و6 تكاملات موثقة |
تشمل الباقات iOS وAndroid بالعربية والإنجليزية. وتسمح التفاصيل الحالية بتحويل نموذج الحجز أو التواصل المشمول إلى نموذج طلب، ضمن الحصة نفسها. لكن نموذج الطلب لا يحدد وحده إدارة المطاعم أو عمل المندوب أو قواعد الإسناد. اطلب وصف كل رحلة تريدها وحدودها داخل العرض.
لمناقشة تكلفة تطبيق توصيل في السعودية، جهّز قائمة الأدوار والعمليات حتى نراجع ما يدخل في النطاق وما يحتاج تقديرًا منفصلًا. يمكنك الرجوع إلى كتالوج أسعار المشروعات المنشور، وإلى دليل ميزانية التطبيق وحدود باقاته لفهم قرار التطوير العام. أما هنا فنركّز على الطلب والتشغيل والتسليم.
حدّد الجهة التي تبيع الطعام وتتحكم في القائمة قبل اعتماد التصميم. إذا كان التطبيق لمطعمك، فقد تختار في الإصدار الأول قائمة واحدة وفريق تجهيز واحد ومنطقة توصيل محددة. اكتب كيف يوقف الموظف استقبال الطلبات وكيف يحدّث توفر الأصناف، ومن يقرر رفض طلب يتعذر تنفيذه. هذا مثال لنطاق مقترح، وليس وصفًا لباقة جاهزة.
إذا أردت منصة مطاعم، فأضف إلى الطلب طريقة تسجيل المطعم وصلاحيات موظفيه وإدارة قائمته. حدّد من يستقبل أموال العميل وكيف يراجع فريقك المالي مستحقات كل مطعم. اطلب من مزود الدفع تأكيد ترتيب الحسابات والتسويات المناسب قبل اعتماد أي وظيفة لتحويل المستحقات ضمن المشروع.
أما سلسلة الفروع فتحتاج قرارًا آخر: هل يختار العميل الفرع، أم يوجّه النظام الطلب وفق قواعد تتفق عليها؟ اذكر إن كانت الأسعار والأصناف وساعات العمل مشتركة بين الفروع. ثم صف ما يحدث إذا أغلق الفرع بعد أن بدأ العميل تجهيز سلته، ومن يستطيع نقل الطلب أو إلغاءه.
قد تسمع طلبًا مثل «أريد تطبيقًا مثل هنقرستيشن». حوّله إلى قائمة عمليات تخص مشروعك: اختيار الطعام، قبول المطعم، الدفع، الإسناد، ثم التسليم. حدّد الوظائف التي ستؤجلها، واطلب توثيقها ضمن الاستثناءات. لا تفترض أن ذكر اسم تطبيق معروف يحدد حجم العمل أو يمنحك سعرًا قابلًا للمقارنة.
قسّم عرض البرمجة حسب من يستخدم النظام وما يفعله. يمكنك دمج بعض الواجهات أو إبقاء إجراء يدويًا خلال البداية، لكن سمّ المسؤول عنه. الجدول التالي يساعد على كتابة الطلب؛ ولا يعني أن أي باقة تشمل أربعة تطبيقات مستقلة.
| مجال العمل | ما تكتبه في الطلب | مثال على اختبار القبول |
|---|---|---|
| واجهة العميل | القائمة والإضافات والسلة والعنوان والدفع والحالة | يرى العميل الأصناف المقبولة وعنوان التسليم الصحيح |
| عمل المطعم | قبول الطلب أو رفضه والتجهيز وتوفر الأصناف | يرفض الموظف صنفًا غير متاح وفق السياسة المعتمدة |
| عمل المندوب | إسناد المهمة والاستلام والتسليم والمحاولة المتعذرة | يعرف المشرف من يتولى الطلب النشط |
| الإدارة | الصلاحيات والإلغاء والاسترداد والتقارير | يستطيع الموظف المخوّل تتبع سجل الطلب والدفع |
| النظام الخلفي | حالات الطلب والربط وسجل التعديلات | تعرض الواجهات الحالة المؤكدة نفسها للطلب |
اطلب من المورد توضيح ما يشترك فيه تطبيق العميل ولوحة المطعم. إذا اعتمدا خدمة طلبات واحدة، فليشرح حدودها ومن يستطيع تعديل بياناتها. سجّل عدد الشاشات والأدوار والتكاملات كلًا على حدة، واسأل كيف يحسب المورد طلبات التغيير بعد اعتماد التصميم.
أدرج في التقدير حالات الانتظار والفشل والبيانات الفارغة. راجع شاشة رفض الدفع وشاشة العنوان خارج منطقة الخدمة، وحدّد الرسالة التي يقرؤها العميل عندما ينتظر قبول المطعم. بهذه المراجعة تستطيع اعتماد سلوك واضح قبل بدء البرمجة، وتعرف ما الذي ستختبره عند التسليم.
اختر طريقة إسناد الطلبات أولًا ثم اطلب تقديرها. في تجربة أولى مقترحة يمكن للمشرف توزيع الطلبات يدويًا. إذا احتجت إسنادًا تلقائيًا، فاكتب قواعد التوفر والمنطقة وإعادة الإسناد، وما يحدث عندما لا يقبل أي مندوب المهمة. لا تكتفِ ببند عام عنوانه «توزيع ذكي» دون شرح الحالات المطلوبة.
افصل عرض عنوان على الخريطة عن تتبع حركة المندوب باستمرار. بحسب تفاصيل خدمة تكنوستاك في أكتوبر 2026، تشمل الباقتان الأكبر عرض آخر موقع معروف لمستخدم وافق على مشاركته، مع تحديث عند الطلب وضمن حدود الباقة؛ أما تتبع الأسطول المستمر فيحتاج نطاقًا منفصلًا. لذلك اطلب تحديد المقصود بكلمة تتبع داخل العرض.
اطلب تجربة انقطاع الاتصال ورفض إذن الموقع وعودة المندوب إلى التطبيق بعد تشغيله في الخلفية. اتفق على ما يراه العميل إذا لم تصل إشارة موقع حديثة، وعلى من يتابع الحالة داخل فريق التشغيل. وراجع من يستطيع الاطلاع على سجل المواقع والمدة التي يحتاجها عملك للاحتفاظ به، ثم أدخل هذه القرارات في مراجعة الخصوصية والتصميم.
إذا كنت تفاضل بين نسخة تعمل في المتصفح وتطبيق مثبت، اقرأ مقارنة قدرات الأجهزة قبل اختيار نوع التطبيق. اطلب اختبار رحلة المندوب على الأجهزة المستهدفة، بما فيها شاشة صغيرة واتصال ضعيف، قبل اعتماد التقنية على أساس عرض مرئي وحده.
اكتب حالة الدفع بجانب حالة الطلب. حدّد متى يدفع العميل ومتى يقبل المطعم، ومن يملك الإلغاء في كل مرحلة. اطلب من المطور شرح ما يحدث إذا نجح الدفع وانقطع اتصال العميل، أو إذا رفض المطعم الطلب بعد تحصيل المبلغ. اعتمد الإجراء والرسالة التي ستظهر للعميل قبل التنفيذ.
أضف تكرار إشعار مزود الدفع وإعادة المحاولة إلى اختبارات القبول. اطلب إثباتًا أن استقبال الإشعار نفسه مرة أخرى لا ينشئ طلبًا إضافيًا ولا يكرر أمر التجهيز. يراجع المطور وثائق المزود المختار عند تحديد التنفيذ؛ لا يفترض هذا الدليل بوابة بعينها أو رسمًا ماليًا غير موثق.
حدّد سياسة الاسترداد الكامل والجزئي وصلاحية اعتماد كل منهما. سجّل كيف يتأكد الموظف من اكتمال العملية، وما الذي يظهر في لوحة الإدارة والتقرير المالي. إذا كنت تجمع مدفوعات لعدة مطاعم، فاطلب موافقة المزود على ترتيب الحساب والتسويات قبل إدراج التحويل الآلي في قائمة التسليم.
اكتب طرق الدفع المطلوبة، مثل مدى أو أبل باي (Apple Pay)، واطلب تأكيد دعمها واعتماد الحساب من الجهة المختارة. تفصل شروط تكنوستاك الحالية رسوم المزودين عن أتعاب التطوير، وتترك موافقة حساب التاجر للمزود. لذلك افصل بند برمجة الربط عن الاتفاق التجاري الذي تعقده مع شركة الدفع.
افصل أتعاب الفريق عن فواتير الخدمات التي يستخدمها التطبيق. جهّز ورقة للاستضافة والخرائط والرسائل والدفع وحسابات المتاجر والصيانة. اكتب أمام كل خدمة مالك الحساب وعملة الفاتورة ووحدة الاستخدام وموعد التجديد. اترك السعر غير المؤكد فارغًا حتى تتلقى عرضًا حديثًا، بدل ملئه برقم متداول في مقالة أخرى.
كما في أكتوبر 2026، تشرح وثائق تسعير منصة خرائط جوجل احتساب الاستخدام بحسب الخدمة والحدث القابل للفوترة في نظام الدفع حسب الاستخدام، وتعرض خيارات اشتراك أيضًا. اسأل المطور عن خدمات الخرائط والمسارات التي سيستدعيها تطبيقك. لا تعتمد على عدد الطلبات المكتملة وحده لتقدير الفاتورة؛ راجع الأحداث التي يحاسب عليها المزود في التنفيذ المقترح.
اطلب تقدير استخدام لتجربة البداية وآخر لحالة نشاط أعلى. سمّ الأرقام افتراضات تخطيطية وحدّد مصدر كل افتراض، ولا تعرضها كتوقع مضمون للطلبات. راجع ما إذا كان العميل يستدعي خدمة مدفوعة خلال البحث أو تعديل العنوان قبل إتمام الشراء، وما إذا كانت لوحة التشغيل تضيف استخدامًا آخر.
للعمل الهندسي المستمر، راجع ورقة تقدير الدعم بعد إطلاق التطبيق، فهي تفصل الإصلاحات عن تحديثات التوافق والميزات الجديدة. وأضف في ميزانيتك الداخلية مسؤوليات استقبال المطاعم وخدمة العملاء والتوصيل. اسأل عن صاحب كل بند، ولا تفترض دخوله ضمن سعر بناء التطبيق.
اعتمد رحلة طلب كاملة مع الحالات التي قد تتعطل فيها. استخدم قائمة تجريبية وحسابات اختبار والطريقة التي يعتمدها مزود الدفع للتجربة. اكتب النتيجة المتوقعة واسم المراجع والدليل المطلوب لكل حالة، حتى يستطيع صاحب المطعم مراجعة التسليم دون الاعتماد على وصف المطور وحده.
اختبر قبول المطعم ورفضه، وإلغاء التوصيل، وتعذر العثور على مندوب، والاسترداد. أضف تغيير العنوان في المرحلة التي تسمح بها سياستك. اطلب من موظفين تنفيذ إجراءين على الطلب نفسه، ثم راجع الحالة النهائية وسجل التعديل. حدّد من يحسم التعارض عندما يحاول أحدهما القبول ويحاول الآخر الإلغاء.
راجع القائمة والإضافات ورسائل التأكيد بالعربية والإنجليزية باستخدام النصوص التي اعتمدتها. جرّب أسماء أطباق طويلة وتكبير الخط وحقول العنوان من اليمين إلى اليسار. دع موظف المطعم يجرب المهام على الجهاز الذي سيستخدمه أثناء العمل، ودوّن الخطوات التي تحتاج شرحًا أو صلاحية غير متاحة.
حدّد منطقة تجربة البداية وساعاتها ومسؤول الدعم وشروط إيقاف الطلبات. اتفق على من يوقف استقبال طلب جديد إذا تعذر على فريقك تنفيذه. تساعدك قرارات حدود الإصدار الأول ومسؤوليات تشغيله على ربط هذه الاختبارات بخطة إطلاق واضحة دون وعود غير مثبتة عن تحمل أعداد ضخمة.
أرسل وصفًا لنموذج المطاعم ومنطقة البداية والمنصات واللغات وأدوار المستخدمين. أرفق قائمة طعام نموذجية وحالات الطلب وقواعد الإسناد ومتطلبات الدفع والأنظمة القائمة. اذكر واجهات API المتاحة ومن يستطيع توفير وثائقها، وأشر إلى الإجراءات التي ستبقى يدوية في الإصدار الأول.
اطلب من الموردين التفصيل نفسه: التصميم، وواجهة العميل، وأدوات المطعم، وعمل المندوب، والنظام الخلفي، والتكاملات، والاختبار، ثم التسليم. راجع الافتراضات والاستثناءات والفواتير المتكررة إلى جانب الإجمالي. اطلب جدولًا يعتمد على اعتماد التصميم وجاهزية المزودين، واسأل كيف يؤثر تأخر حساب الدفع أو النصوص في موعد المشروع.
في التسليم حدّد مالك الكود وملفات التصميم وحسابات المتاجر والفوترة. اطلب تعليمات الإصدار وقائمة الصلاحيات ونطاق الدعم المتفق عليه. دوّن آلية تسعير التعديلات بعد اعتماد المتطلبات، ومن يوافق عليها داخل شركتك قبل أن يبدأ الفريق تنفيذها.
الخلاصة العملية: اختر نموذج التشغيل، ثم سعّر رحلة الطلب ومسؤوليات أصحابها، وافصل رسوم المزودين عن التطوير. بعد تجهيز هذه الورقة، أرسل لنا مسار التوصيل ونطاق الإصدار الأول لنراجع متطلبات عرضك.
