تصميم متجر إلكتروني في اسطنبول

لنتحدث في هذا أولًا

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

وسبب الانتقال إلى التطوير المخصص عادةً ليس الحجم بل القواعد: سعر مختلف للموزع، وحساب حسب المقاس، وربط بنظام ⁨ERP⁩. فإن لم يوجد واحد من هذه فلا تستعجل.

رحلة طلب واحد

صحة المتجر يبيّنها سير طلب واحد من أوله إلى آخره دون انقطاع. وفي الإنشاء نختبر هذا المسار خطوة خطوة.

1. 01

   العثور

   يصل الزائر إلى المنتج من البحث أو التصنيف أو الإعلان. الصفحة يجب أن تفتح بسرعة، والسعر والمخزون أن يكونا واضحين.

2. 02

   السلة

   تكلفة الشحن ومدة التسليم مكانهما هنا. وأكثر أسباب ترك السلة شيوعًا مبلغ مفاجئ يظهر في خطوة الدفع.

3. 03

   الدفع

   بيانات البطاقة تُدخَل داخل إطار المزوّد ولا تصل إلينا. ومسار ⁨3D Secure⁩ يُجرَّب ببطاقة حقيقية.

4. 04

   التأكيد

   يُفتح سجل الطلب، ويصل إشعار إلى الطرفين، ويُخصم من المخزون.

5. 05

   الشحن

   يفتح الربط مع شركة الشحن الإرسالية، ويُلحَق رقم التتبع بالطلب ويصل إلى العميل.

6. 06

   الإرجاع

   مدة العدول وشروط الإرجاع تسير وفق التنظيم القانوني، والطلب يُتابَع من اللوحة.

مثال يعمل فعلًا: ⁨pekerox.com⁩

متجر يبيع كيماويات تنظيف للقوارب والمنشآت الصناعية ومحطات الطاقة الشمسية. يمكنك فتحه والتجول فيه؛ كل ما وصفناه هنا يعمل هناك.

المسألة الحقيقية في هذا العمل لم تكن عدد المنتجات. فالمنتج نفسه يُباع لصاحب القارب باسم «منظّف مياه القاع»، وللمنشأة الصناعية باسم «مزيل زيوت ثقيل». وحين حُشر في شجرة تصنيف واحدة لم يعد أي من المشترين الثلاثة يجد ما يبحث عنه. فبنينا التصنيف حسب مجال الاستخدام، وصار المنتج يظهر في أكثر من مجال.

وفي الكيماويات يكون مجال الاستخدام والجرعة جزءًا من قرار الشراء. لذلك وُضعت المعلومة التقنية بجانب السعر، لا في أسفل صفحة الكتالوج.

• التصنيف والمنتج والسلة والشحن والدفع تعمل من أولها إلى آخرها
• أشرطة المميّزة والوارد حديثًا والمخفَّضة تُدار من اللوحة
• مبني بـ ⁨Next.js⁩، وإدارة المتجر من لوحة منفصلة

الالتزامات القانونية عند البيع داخل تركيا

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

هذا الجدول للإعلام لا للاستشارة القانونية. نحن لسنا محامين؛ والنصوص يجب أن يقرأها محاميك أو مستشارك المالي قبل نشرها.

كيف تُختار بنية الدفع؟

هناك طريقان: أن تأخذ بوابة دفع من بنكك، أو أن تستخدم بنية مزوّد خدمات دفع. عمولة البنك أقل عادةً وطلبها يستغرق وقتًا أطول. ومع مزوّد الدفع يكون الأمر معكوسًا.

وفي الحالتين لا تنزل بيانات البطاقة على خادمنا. فصفحة الدفع تُفتح داخل إطار المزوّد أو عبر تحويل إليه، وهذا يترك الجزء الأكبر من التزامات ⁨PCI-DSS⁩ عند المزوّد.

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

أكبر بند في العمل: بيانات المنتجات

المشاريع تتأخر بسبب البيانات لا بسبب البرمجة. فالمنتج الذي لا صورة له، ووصفه في كتالوج ⁨PDF⁩ ممسوح ضوئيًا، وجدول مقاساته في ملفات ⁨Excel⁩ مبعثرة، لا يُعد جاهزًا للنشر.

• لكل منتج: الاسم، والرمز، والتصنيف، ووصف قصير وآخر طويل، وصورة واحدة على الأقل
• للمنتجات ذات المتغيّرات: جدول مقاسات وألوان، مطابق لرموز المخزون
• الوزن والوزن الحجمي، لحساب الشحن
• الأوصاف بلغة العميل لا بلغة الكتالوج
• جدول مطابقة الحقول، إن كان النقل سيتم من نظام ⁨ERP⁩

لماذا يختلف جانب البحث في المتاجر؟

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

• إدارة ⁨canonical⁩ في عناوين التصفية والترتيب
• عرض بدائل للمنتج الذي نفد بدل حذف صفحته
• نص وصف قصير لكنه حقيقي في صفحات التصنيف
• بيانات منظَّمة للمنتج والعرض، مع السعر وحالة التوافر
• ترميز التقييمات فقط حيث توجد تقييمات عملاء حقيقية