متجر إلكتروني ينجح تشغيلياً: القرارات قبل البرمجة

نموذج البيع يحدد كل شيء بعده

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

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

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

• ●نوع البيع: مستهلك نهائي، أو منشآت، أو طلب عرض سعر
• ●عدد المنتجات المتوقع، ووجود خيارات متعددة لكل منتج من عدمه
• ●مصدر الحقيقة للمخزون والأسعار: المتجر أم نظام قائم لديكم
• ●سياسة الأسعار: سعر موحد، أم أسعار حسب العميل أو الكمية
• ●من يدير الكتالوج يومياً بعد التسليم، وبأي صلاحيات

الدفع والشحن: ما يُحسم مع مزوّديكم قبل التطوير

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

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

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

• ●مزوّد الدفع الذي تتعاقدون معه، وبلد تسجيل جهة التحصيل، وحالة الحساب لديه
• ●العملة والعرض السعري، وطريقة إظهار الضريبة في السلة
• ●قواعد تكلفة الشحن، والدفع عند الاستلام إن وُجد
• ●شركة الشحن ومدى توفر تكامل تقني لديها لتتبع الشحنات
• ●سياسة الإرجاع والاستبدال كما ستُطبَّق فعلياً لا كما تُكتب

المتطلبات المحلية تُحسم مع مستشاركم المحاسبي

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

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

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

ما بعد الإطلاق: السرعة على الجوال والربط بأنظمتكم

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

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

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

الأسئلة الشائعة