23 أكتوبر 2026 · 3 دقائق قراءة · الجزء 5
عايز تعمل تطبيق توصيل؟ جهز الحاجات دي الأول
قبل ما تبرمج تطبيق توصيل: التطبيقات التلاتة اللي محتاجها، الدفع والمحفظة، حسابات المتاجر، ونشر التطبيق على App Store وGoogle Play.
تطبيق التوصيل الحقيقي مش تطبيق واحد. هو تلات أنظمة: تطبيق للعميل يطلب ويدفع، وتطبيق للمندوب يستلم الطلبات ويحدث حالتها، ولوحة تحكم لفريقك يدير منها الأصناف والطلبات والمناديب، وكلهم شغالين على قاعدة بيانات واحدة. وقبل ما تبدأ برمجة، جهز بوابة الدفع، وحسابات المطورين على المتجرين باسم شركتك، وقائمة الأصناف بصورها.
الكلام هنا من تجربة حقيقية: بنيت Salwa لوحدي، منصة طلبات بقالة لمنطقة السالوة في الكويت: تطبيق العميل على App Store وGoogle Play، وتطبيق للمندوب، ولوحة تحكم للمحل.
الأنظمة التلاتة
| النظام | مين بيستخدمه | بيعمل إيه |
|---|---|---|
| تطبيق العميل | الزبون | يتصفح الأصناف، يضيف للسلة، يدفع أونلاين أو من المحفظة، ويتابع طلبه |
| تطبيق المندوب | المندوب | يشوف الطلبات المتوزعة عليه، ويحدث حالتها لحد ما توصل |
| لوحة التحكم | فريق المحل | الأصناف والمخزون، الطلبات، المستخدمين، المناديب، والتقارير |
ليه تطبيق المندوب منفصل؟
ممكن تحط الاتنين في تطبيق واحد بصلاحيات مختلفة، بس فصلهم أسهل على المدى الطويل. تطبيق العميل لازم يبقى سريع وبسيط وبيتحدث كتير علشان العروض والشكل. تطبيق المندوب شاشات قليلة وواضحة، ومينفعش تحديث في واجهة العميل يكسر شغل المناديب. في Salwa التطبيقين منفصلين، بس بيستخدموا نفس قاعدة البيانات، فأي تعديل من لوحة التحكم بيظهر في التطبيقين على طول.
الدفع والمحفظة
اختار بوابة الدفع اللي عملاءك متعودين عليها. في الكويت Salwa شغالة بـ MyFatoorah. ولو عايز محفظة (رصيد للعميل من المرتجعات أو العروض)، فيه قاعدة مهمة: الرصيد مايتغيرش غير من خلال عمليات محسوبة جوه قاعدة البيانات نفسها، كل إضافة وكل خصم ليه سجل. بالشكل ده الرصيد عمره ما يختلف عن تاريخ العمليات، حتى لو حصلت مشكلة في التطبيق أو النت قطع في نص عملية.
لوحة التحكم: اللي فريقك هيعيش فيها
- الأصناف والأسعار والصور، مع تحديث المخزون لأصناف كتير مرة واحدة.
- إخفاء صنف أو أرشفته من غير ما تمسحه، والتطبيق بيحترم ده في كل شاشة.
- الطلبات وحالتها، وتوزيعها على المناديب.
- المستخدمين بأدوار مختلفة: أدمن، موظف، مندوب، وكل واحد شايف اللي يخصه.
- تقارير تقدر تصدرها وتراجعها برا السيستم.
قبل ما تبدأ البرمجة، جهز دول
- حساب بوابة الدفع باسم الشركة، لأن الموافقة عليه بتاخد وقت.
- حسابات المطورين على Apple وGoogle باسم شركتك، مش باسم المبرمج. حساب الشركة على المتجرين بيحتاج رقم D-U-N-S، وده مجاني بس ممكن ياخد وقت (صفحة Apple عن D-U-N-S). ابدأ فيه بدري.
- قائمة الأصناف بأسمائها وأسعارها وصورها، في ملف Excel مرتب.
- مناطق التوصيل ورسومها.
- سياسة الخصوصية وصفحة تواصل، لأن المتجرين بيطلبوهم.
النشر على المتجرين
Apple وGoogle بيراجعوا التطبيق قبل ما ينزل، وأي تحديث كبير بيتراجع تاني. الرفض وارد ومش نهاية العالم: بيجي معاه سبب، بيتصلح، والتطبيق بيتبعت تاني. اللي بيفرق إن حد فاهم المراجعة يتابعها من أولها.
ونصيحة من تجربة: لو التطبيق اتنشر في الأول على حساب حد تاني، ينفع يتنقل لحساب شركتك. عملت ده فعلا مع Salwa ونقلت التطبيق بين حسابين مطورين. بس الأسهل من الأول إن الحساب يبقى باسمك.
التكلفة بتتحدد بإيه؟
عدد التطبيقات (عميل، مندوب، لوحة تحكم)، الدفع الأونلاين والمحفظة، متابعة المندوب على الخريطة، عدد الفروع، والتقارير اللي محتاجها. ممكن تبدأ بتطبيق العميل ولوحة التحكم، وتضيف تطبيق المندوب لما الطلبات تزيد.
أسئلة بتتسأل كتير
محتاج تطبيق للمندوب فعلا؟
لو عندك مندوب أو اتنين في الأول، ممكن يشتغلوا من لوحة التحكم. لما العدد يزيد، تطبيق المندوب بيوفر وقت ومكالمات كتير.
الحسابات على المتجرين تبقى باسم مين؟
باسم شركتك. التطبيق أصل من أصول الشركة، والمبرمج بيتضاف كمطور على الحساب.
ينفع أضيف المحفظة بعدين؟
ينفع، بس الأحسن إن قاعدة البيانات تتصمم من الأول وهي عاملة حسابها، حتى لو المحفظة نفسها هتظهر بعدين.
لو بتفكر في تطبيق توصيل، التفاصيل في صفحة تطبيق توصيل طلبات وصفحة برمجة تطبيقات موبايل، والمشروع كامل في دراسة حالة Salwa. ولو التطبيق محتاج يتربط بسيستم الشركة، اقرأ إزاي تختار مبرمج سيستم ERP أو CRM.