لوحة تحكم التاجر للعروض: النشر والحدود والأرقام الواضحة

ما الذي يجب أن تفعله لوحة عروض التاجر

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

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

في T-CODE، تطبيق العروض الذي صمّمته FLUIDS وبنته، توجد أدوات التاجر في تطبيق الجوال نفسه الذي يستخدمه المتسوّق: تطبيق واحد للطرفين. ينشئ التاجر ملف متجره، وينشر عروضًا محددة المدة أو محدودة بعدد أكواد، ويؤكّد الاستخدام بكود الاسترداد، ويتابع النتائج في لوحة تحكم. ويتناول هذا الدليل كل جزء والقرارات التي تقف خلفه.

انضمام التاجر: الطلب والمراجعة والموافقة

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

ويفصل T-CODE بين طلب الانضمام وتشغيل المتجر. فنموذج التاجر فيه يميّز بين طلب قيد الانتظار، وطلب مرفوض، وموافقة لم يتبعها إنشاء متجر بعد، ومالك لديه متجر جاهز للإدارة. ولكل حالة خطوتها التالية، ويمكن تصميمها على النحو الآتي:

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

نشر العرض: الحقول التي تهمّ

مسار النشر الجيد لا يطلب إلا ما يحتاجه المتسوّق ليقرر، وما يحتاجه النظام ليفرض القواعد. ففي T-CODE ينشئ التاجر العرض، ويحدد السعر والمدة والفرع، ويختار بين عرض محدد المدة وعرض محدود بعدد أكواد، ثم يتابع حالة كل عرض.

والترتيب العملي للنموذج هو:

1. ما العرض: عنوان قصير وصورة ووصف واضح لما يحصل عليه المتسوّق.
2. الشروط: السعر أو نسبة الخصم، وأي شروط مثل حد أدنى للشراء أو منتجات مستثناة.
3. أين: الفرع أو الفروع التي ستقبله، ولا يُختار منها إلا الظاهر.
4. الحد: تاريخ انتهاء، أو عدد أكواد، أو كلاهما.
5. المعاينة: العرض كما سيراه المتسوّق قبل نشره.

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

تعديل العرض المنشور دون الإخلال بالوعود

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

وبعض التعديلات آمن وبعضها ليس كذلك:

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

وتستحق الحدود عناية خاصة. ففي T-CODE يُطبَّق الحد فعلًا لا استرشادًا، وينبغي أن تحترم التعديلات المبدأ نفسه: فالحد الذي يستطيع التاجر الالتفاف عليه بهدوء بعد صرف الأكواد ليس حدًا. ويشرح دليلنا عن أكواد استخدام الكوبونات كيف يفرض الخادم الحدود والصلاحية.

ما الأرقام التي يجب أن تعرضها لوحة التاجر

ينبغي أن تعرض لوحة التاجر عددًا قليلًا من الأرقام، لكل منها تعريف واحد دقيق. وتجمع لوحة T-CODE الفروع والعروض والمشاهدات والمتابعين والأكواد المستخدمة ومعدل التحويل في شاشة واحدة، فلا يبقى أداء العرض تخمينًا. وأيًّا كان ما تضمّنه في لوحتك، فعرّفه:

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

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

بناء اللوحة: داخل التطبيق أم على الويب أم كلاهما

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

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

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

تصمّم FLUIDS وتبني المنتجات ذات الطرفين بوصفها منصات أسواق وبرمجيات مخصصة، ومنها أعمال في التجارة الإلكترونية والتجزئة. وتعرض دراسة مشروع T-CODE أدوات التاجر في سياقها. ويُتفق على النطاق والسعر والمدة في عرض مكتوب قبل التطوير.