تنقسم منصات بطاقات المحفظة الرقمية إلى ثلاث فئات: أدوات البطاقات المستقلة، ومنصات الولاء التي تتضمن المحفظة، ومنصات تفاعل العملاء (CEP) ذات المحفظة الأصلية. الأداة المستقلة تكفي عندما تكون البطاقة هي البرنامج كله. أما عندما يجب أن تعمل البطاقة مع الإشعارات الفورية والبريد الإلكتروني والشرائح والرحلات، فالمنصة التي تحمل ملف العميل أصلاً هي التي تفوز عادة.
أولاً، مشكلة في التسمية. Apple PassKit هو إطار عمل Apple لبطاقات Wallet، وكل مزوّد بطاقات يبني عليه. أما PassKit Inc. فشركة تبيع منصة بطاقات. عندما يبحث الناس عن «بديل PassKit» فهم يقصدون الشركة، وهذا ما تغطيه هذه المقارنة، إلى جانب موقع بطاقات المحفظة في Pushwoosh بينها. ونكتبها لفرق التجارة الإلكترونية والتكنولوجيا المالية والخدمات الحكومية في السعودية والإمارات ومصر، حيث تعمل المحفظة غالباً إلى جانب قنوات أخرى لا بمفردها.
ثلاث فئات من أدوات بطاقات المحفظة
أدوات البطاقات المستقلة. تركّز PassKit وPasscreator وPassSlot وPass2U على البطاقة نفسها. تجمع PassKit بين منشئ بدون كود وAPI لـ Apple Wallet وGoogle Wallet، وPassSlot منشئ متخصص لـ Apple Wallet يُستخدم غالباً في التجزئة والفعاليات، وPass2U منشئ بدون كود للمنصتين موجّه للشركات الصغيرة.
منصات الولاء التي تتضمن المحفظة. مزوّدو الولاء مثل Antavo وYotpo يديرون منطق البرنامج (النقاط والمستويات والمكافآت) ويقدّمون المحفظة كإحدى طرق عرض البطاقة.
منصات التفاعل ذات المحفظة الأصلية. منصات تفاعل العملاء مثل Pushwoosh وAirship تُصدر البطاقات بشكل أصلي، على الملف نفسه الذي تعمل عليه الإشعارات الفورية والرسائل داخل التطبيق والبريد الإلكتروني وSMS. ومنصات تفاعل أخرى تضيف المحفظة عبر شركاء. Braze مثلاً تعمل مع مزوّدي بطاقات مثل PassKit.
جدول المقارنة
| المعيار | أداة بطاقات مستقلة | منصة ولاء مع محفظة | CEP مع محفظة عبر شريك | CEP مع محفظة أصلية |
|---|---|---|---|---|
| بطاقات Apple وGoogle | أصلية، وبعض الأدوات لـ Apple فقط | يختلف | عبر أداة الشريك | أصلية |
| منشئ مرئي | نعم | يختلف | في أداة الشريك | نعم |
| API | يختلف | نعم | واجهتا API | نعم |
| التحديثات الحية | نعم | نعم | نعم، عبر المزامنة | نعم |
| الشرائح من بيانات العملاء | مقتصرة على بيانات البطاقة | بيانات الولاء | عبر المزامنة | الملف نفسه |
| رحلات عبر القنوات | لا | محدودة | أداتان | رحلة واحدة |
| الإشعارات الفورية والبريد وSMS في الأداة نفسها | لا | يختلف | نعم، والمحفظة منفصلة | نعم |
اقرأ الجدول صفاً صفاً، لا عموداً عموداً. الصفوف الأهم لفرق الاحتفاظ بالعملاء هي الشرائح والرحلات والقنوات. هناك تختلف الفئات. أما في إصدار البطاقات فهي متقاربة.
كيف تسعّر الأدوات المستقلة
الأسعار تتغير، لذا راجع صفحة الأسعار الحالية لكل مزوّد قبل القرار وسجّل تاريخ مراجعتك. واسأل هل يحتسب المزوّد البطاقات الصادرة أم البطاقات النشطة على الهواتف: البرنامج نفسه قد يكلف مبالغ مختلفة جداً وفق النموذجين. وقارن ذلك أيضاً بما تدفعه اليوم لمزوّدي الرسائل القصيرة المحليين، الذين يحتسبون تكلفة على كل رسالة.
للاطلاع على النماذج كلها والتكاليف الخفية، راجع دليل الأسعار.
متى تكفي الأداة المستقلة
تناسب أداة البطاقات المستقلة الحالات التي تكون فيها المحفظة هي البرنامج، لا قناة واحدة ضمنه. حالات نموذجية:
- منظّم فعاليات يُصدر التذاكر، دون تطبيق ودون مراسلة مستمرة.
- نشاط تجاري صغير يدير بطاقة أختام دون أي نظام CRM آخر.
- حملة لمرة واحدة: قسيمة، أو شارة مؤتمر، أو بطاقة موسمية لرمضان أو اليوم الوطني.
هنا يغطي مصمم المزوّد وAPI الخاص به المهمة. وإضافة منصة تفاعل كاملة ستكون أداة أكبر من حاجتك، وهذا ما نقوله لأي شخص يسأل.
متى تحتاج إلى منصة تفاعل
تتغير الصورة حين يجب أن تتفاعل البطاقة مع بيانات العميل وتعمل مع قنوات أخرى. تكون قد تجاوزت الأداة المستقلة عندما:
- تريد إصدار البطاقات من أحداث في التطبيق أو الموقع، مثل التسجيل أو أول طلب.
- تقسّم حاملي البطاقات إلى شرائح حسب سلوك يعيش في منصة بيانات العملاء (CDP) أو منصة التفاعل.
- لحظة واحدة، مثل نقاط توشك على الانتهاء، تحتاج إلى تحديث للبطاقة وإشعار فوري ورسالة بريد معاً.
- تزامن قاعدتَي بيانات وتبني الرحلة نفسها مرتين.
وتظهر هذه الحالات بوضوح في مواسم التسوق بالمنطقة. في سوق تقوده تطبيقات تسوق مثل Noon وNamshi، تصبح الجمعة البيضاء ورمضان والعيد لحظات يحتاج فيها المتجر إلى قسيمة في المحفظة وإشعار فوري ورسالة بريد في الرحلة نفسها. وإذا كانت كل قناة في أداة مختلفة، فالتنسيق بينها يتكرر مع كل موسم.
عند هذه النقطة يصبح السؤال: هل تربط أداة بطاقات بمنصتك الحالية، أم تنتقل إلى منصة ذات محفظة أصلية؟
أين يقع Pushwoosh
Pushwoosh منصة تفاعل عملاء متعددة القنوات تُصدر بطاقات Apple Wallet وGoogle Wallet بشكل أصلي، دون شريك في المنتصف. تُصدر البطاقات حسب معرّف المستخدم (User ID) وتعيش في منصة بيانات العملاء والشرائح وCustomer Journey (رحلة العميل) نفسها التي تعمل عليها الإشعارات الفورية والرسائل داخل التطبيق والبريد الإلكتروني وSMS وWhatsApp. وفي الرحلات خطوة مخصصة اسمها Issue Wallet Pass.
تحصل على منشئ مرئي للمنصتين وREST API وتحديثات حية. في Apple تكون التحديثات صامتة ما لم يكن للحقل رسالة تغيير، وعندها يرى العميل تنبيهاً على شاشة القفل. وفي Google تُزامَن التغييرات مع كل جهاز حُفظت عليه البطاقة. وبما أن Android يتجاوز 70% من الهواتف في منطقة الشرق الأوسط وشمال أفريقيا، فدعم Google Wallet الأصلي ليس تفصيلاً ثانوياً. وتُستضاف البيانات على بنية Pushwoosh الخاصة في ألمانيا والولايات المتحدة، مع شهادتي ISO 27001:2022 وSOC 2 Type 2 والتوافق مع GDPR.
ولنكن واضحين بشأن الحدود: لا يقدّم Pushwoosh بطاقات NFC مثل بطاقات النقل باللمس أو مفاتيح غرف الفنادق. وعلى أي منصة، لا تسمح Apple وGoogle إلا بالإشعارات المتعلقة بالبطاقة.
وفي المنطقة يبدأ كثير من الفرق من خليط مختلف: Firebase Cloud Messaging للإرسال فقط، ومزوّد رسائل قصيرة محلي يحتسب كل رسالة، ثم أداة بطاقات ثالثة. وهو مسار تسلكه تطبيقات مالية في الخليج وهي تنقل تنبيهات المعاملات من SMS إلى الإشعارات الفورية. في Pushwoosh تجتمع الإشعارات والبريد وSMS والمحفظة على ملف واحد، فتنتقل تدريجياً دون أن تضيف أداة جديدة.
قلّل تعدد الأدوات مع Pushwoosh
إذا كانت المحفظة قناة واحدة ضمن برنامج احتفاظ أكبر، يضعها Pushwoosh بجوار الإشعارات الفورية والرسائل داخل التطبيق والبريد الإلكتروني وSMS وWhatsApp على ملف عميل واحد. منشئ واحد، وAPI واحد، ورحلة واحدة لكل القنوات.
منصة المحفظة المناسبة ليست صاحبة أكبر عدد من قوالب البطاقات. إنها الأقرب إلى المكان الذي تعيش فيه بيانات عملائك أصلاً.
