كيف تبني تطبيق كوبونات وعروض محلية

ما الذي يفعله تطبيق الكوبونات والعروض المحلية فعلًا؟

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

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

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

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

المزايا الأساسية للمتسوّق والتاجر

تنقسم المزايا الأساسية بوضوح بين الطرفين، وكل ميزة موجودة لأن أحد المستخدمَين لا يستطيع إتمام مهمته دونها:

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

قواعد العمل التي تُحسم قبل التصميم

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

1. من يحق له النشر. التجّار المعتمدون فقط، أم كل من يسجّل؟ وكثير من التطبيقات المحلية تراجع طلبات التجّار أولًا.
2. أين يسري العرض. في جميع الفروع أم في فرع محدد؟ يجب أن يعرف المتسوّق ذلك قبل أن يتحرك.
3. كيف يُحدّ العرض. بتاريخ انتهاء، أو بعدد أكواد، أو بهما معًا. وحدِّد هل يُحتسب الحد على الحجوزات أم على الاستخدامات المؤكدة فقط.
4. كم يبقى الحجز صالحًا. الحجز الذي لا ينتهي يتيح لشخص واحد تعطيل عرض محدود إلى أجل غير مسمّى.
5. من يؤكّد الاستخدام. ضغط المتسوّق على «تم الاستخدام» ليس دليلًا. ينبغي أن يؤكّد التاجر الاستخدام على كود محدد.
6. ما الذي تحتسبه التقارير. المشاهدات والحجوزات والاستخدامات المؤكدة ثلاثة أرقام مختلفة، ولا يجوز دمجها.

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

كيف يجمع T-CODE الطرفين في تطبيق واحد

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

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

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

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

المكوّنات التقنية

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

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

يعتمد T-CODE على Flutter لتطبيق الجوال وعلى Supabase للخادم، وهو مزيج يناسب قاعدة برمجية واحدة لنظامي iOS وAndroid مع قاعدة بيانات Postgres يمكن فرض قواعد العمل فيها عبر القيود مباشرة. وأيًّا كانت التقنية، صمّم الواجهة بالعربية أولًا بتخطيط صحيح من اليمين إلى اليسار إذا كان جمهورك في السعودية أو الخليج، واستعد لمراجعة متجري Apple App Store وGoogle Play، اللذين يدققان في استخدام الموقع وفي حذف الحساب.

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

ما الذي يدخل في الإصدار الأول

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

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

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

تعتمد التكلفة والمدة على عدد المسارات التي تدخل النطاق، وعدد الأدوار، ووجود لوحة إدارة منفصلة من عدمه، وحجم التقارير التي يتوقعها التجّار. وتؤكّد FLUIDS السعر والمدة في عرض مكتوب قبل التطوير؛ اطّلع على ما الذي يحدد تكلفة تطوير التطبيق ودليل تكلفة MVP. وللسياق الأوسع للمنتجات ذات الطرفين، اقرأ عن تطوير منصات الأسواق وعن عملنا في التجارة الإلكترونية والتجزئة.