אין מחיר אחד ל-wallet passes. כמה שתשלמו תלוי במודל של הספק (לפי כרטיס, לפי כרטיס פעיל, תשלום קבוע, או חבילה בתוך פלטפורמת מעורבות לקוחות) ועוד כמה עלויות קבועות, כמו דמי המפתחים של Apple בסך $99. תמחור wallet pass לכרטיס עצמו זול. התקציב גדל בכלים שמסביבו.
לצוותים ישראליים, שבודקים כל שורה בחשבונית מול התועלת שלה, זה ההבדל בין תוכנית שמחזירה את עצמה לתוכנית שנתקעת בתקציב. אם אתם כבר משתמשים ב-Pushwoosh ל-push, אימייל או SMS, ה-wallet passes יושבים באותה פלטפורמה, ואפשר להשוות את האפשרויות זו לצד זו.
4 מודלי התמחור
ספקים מתמחרים wallet passes ב-4 דרכים עיקריות, וכל אחת מתגמלת סוג אחר של תוכנית.
| מודל | איך משלמים | מתאים ל | שימו לב |
|---|---|---|---|
| לפי כרטיס שהונפק | תשלום על כל כרטיס שנוצר | קופונים, כרטיסים לאירועים, כרטיסים חד-פעמיים | העלות גדלה עם כל קמפיין |
| לפי כרטיס פעיל | תשלום על כל כרטיס ששמור בטלפון, נספר חודשית | כרטיסי מועדון ומנויים | כרטיסים ארוכי חיים ממשיכים לעלות |
| מסלול קבוע או מדורג | תשלום חודשי לטווח של כרטיסים | תוכניות בינוניות וצפויות | קפיצות בגבולות המדרגות |
| חבילה בתוך CEP | חלק מהמסלול של פלטפורמת המעורבות | צוותים ששולחים גם push, אימייל ו-SMS | בדקו מה החבילה כוללת |
ספקים יכולים לשלב את המודלים האלה במסלול 1, למשל דמי פלטפורמה חודשיים ועוד תשלום לפי נפח. עמודי תמחור משתנים, אז בדקו את העמוד העדכני של כל ספק ורשמו את תאריך הבדיקה.
שימו לב לדפוס: אותם 10,000 כרטיסים יכולים לעלות סכומים שונים מאוד, תלוי אם הספק סופר את מה שאתם מנפיקים או את מה שנשאר בטלפונים.
עלויות קבועות שכל תוכנית משלמת
חלק מהעלויות מגיעות מ-Apple ומ-Google, לא מהכלי שלכם. משלמים אותן לא משנה מה בוחרים.
- חשבון Apple Developer: $99 לשנה. צריך אותו בשביל תעודת ה-Pass Type ID שחותמת על כרטיסי Apple. התעודה פגה, כך שהחידוש הוא משימה חוזרת ולא חד-פעמית.
- הגדרת issuer ב-Google. חשבון issuer ב-Google Pay & Wallet Console, שמוגדר פעם אחת לכל אפליקציה.
- עיצוב. לייאאוטים, לוגואים ותמונות hero בגדלים שכל פלטפורמה דורשת. בדרך כלל עבודה חד-פעמית לכל סוג כרטיס.
- אינטגרציה עם קופה או סורק. אם הצוות סורק כרטיסים בקופה או בשער, מישהו צריך לחבר את הברקוד למערכת הקופה או הכרטוס שלכם. זו גם העלות שהכי קל לשכוח בהצעת מחיר.
לזה כדאי להוסיף שורה שלא מופיעה בחשבונית של אף ספק wallet: הפצה. קישור ההתקנה צריך להגיע ללקוח בערוץ כלשהו, ובישראל זה לרוב WhatsApp, שמחליף במידה רבה את ה-SMS השיווקי. בדקו מראש אם הכלי שאתם בוחרים שולח את הקישור בעצמו, או שתצטרכו לשלם בנפרד על ערוץ ההפצה.
העלות הנסתרת של כלי שני
העלות הגדולה ביותר כמעט אף פעם לא מופיעה בחשבונית של ספק ה-wallet. היא נובעת מהפעלת ה-wallet בכלי נפרד, ליד הפלטפורמה שכבר מכירה את הלקוחות שלכם.
בסוף יש לכם 2 מסדי נתונים. פלטפורמת המעורבות מחזיקה פרופילים, אירועים ו-segments. כלי הכרטיסים מחזיק את מחזיקי הכרטיסים. הסנכרון ביניהם דורש webhooks, כלי אינטגרציה או זמן פיתוח, והוא אף פעם לא נגמר.
כל journey נבנה פעמיים. תזכורת על נקודות שעומדות לפוג יוצאת מכלי 1, עדכון הכרטיס מכלי אחר, ומישהו צריך לשמור על התיאום ביניהם. בישראל זה מוכר במיוחד למי שכבר מחזיק ספק SMS מקומי נפרד, עם עלות גבוהה להודעה ובלי personalization חכם.
אתם גם חותמים על 2 חוזים ועוברים 2 סקירות ספק. בדיקות אבטחה, GDPR ורכש נעשות לכל ספק בנפרד.
חלק מפלטפורמות המעורבות מוסיפות wallet דרך שותף. Braze, למשל, מחברת כלי wallet כמו PassKit דרך אינטגרציות שותפים, כך שמשלמים על שניהם ומתחזקים את החיבור ביניהם.
איך מחשבים עלות ל-1,000, 10,000 ו-100,000 מחזיקים
מחירי הספקים משתנים, אז בנו את המודל על נוסחאות והכניסו את התעריפים העדכניים מעמודי התמחור שאתם משווים.
עלות חודשית = דמי פלטפורמה + (כרטיסים פעילים ארוכי חיים × תעריף) + (כרטיסים חד-פעמיים שהונפקו × תעריף) + תקורת הכלי השני
אחר כך הריצו אותה ל-3 גדלים ובדקו איפה כל מודל נשבר.
| גודל התוכנית | מה בדרך כלל מכתיב את העלות |
|---|---|
| 1,000 מחזיקים | דמי פלטפורמה והקמה. התשלום לפי כרטיס קטן. |
| 10,000 מחזיקים | התשלום לפי כרטיס או לפי כרטיס פעיל מתחיל להשפיע. השוו מדרגות. |
| 100,000 מחזיקים | תשלומי נפח ותקורת הכלי השני. |
הפרידו בין כרטיסים ארוכי חיים לחד-פעמיים בשורות נפרדות. בית קפה עם 10,000 כרטיסיות חותמות ופסטיבל שמנפיק 10,000 כרטיסי כניסה יקבלו חשבונות שונים מאוד במודל לפי כרטיס פעיל, גם עם אותו מספר כרטיסים. כך גם קופון לעונת חגי תשרי מול כרטיס מועדון שנשאר בארנק כל השנה.
היו כנים לגבי שורת התקורה. ספרו את השעות בחודש שהולכות על סנכרון נתונים ועל בנייה מחדש של journeys בכלי שני, והכפילו במה שהזמן הזה עולה. לדעתנו זו השורה שהכי הרבה פעמים הופכת את ההחלטה.
לסטארטאפ בצמיחה, הריצו את הנוסחה לא רק על הגודל של היום, אלא גם על הגודל שאליו אתם מכוונים אחרי ההתרחבות לאירופה ולארה”ב. מודל שנראה זול בתוכנית קטנה יכול להתנהג אחרת לגמרי בתוכנית גדולה. עדיף לבחור עכשיו מודל שמחזיק גם בשלב הבא.
מה לשאול כל ספק
- המחיר לפי כרטיס שהונפק, לפי כרטיס פעיל, או קבוע? איך בדיוק אתם מגדירים “פעיל”?
- מה קורה לעלות כשכרטיסים פגים או כשלקוחות מוחקים אותם?
- עדכונים והתראות כלולים, או מחויבים בנפרד?
- גישה ל-API כלולה, ויש מגבלות?
- אתם מנפיקים כרטיסי Apple ו-Google נייטיב, או דרך שותף?
- איפה מאוחסנים נתוני הלקוחות, ואילו הסמכות יש לכם?
אם ספק לא יכול לענות על השאלה הראשונה במשפט 1, חשבו את החשבונית פעמיים.
ה-wallet בפלטפורמה 1 עם Pushwoosh
Pushwoosh מנפיקה כרטיסי Apple Wallet ו-Google Wallet נייטיב באותה פלטפורמה של ה-push, ה-in-app, האימייל, ה-SMS וה-WhatsApp שלכם. אין מסד נתונים שני לסנכרן ואין שותף באמצע. הכרטיסים חולקים User IDs, segments ו-journeys עם כל ערוץ אחר, והנתונים מעובדים על תשתית עם הסמכות SOC 2 Type 2 ו-ISO 27001:2022, בהתאמה ל-GDPR, עם מרכזי נתונים באיחוד האירופי ובארה”ב. ראו איך זה משתווה בעמוד Wallet passes.
עלויות wallet נמוכות כמעט אף פעם לא מגיעות מהתעריף הנמוך ביותר לכרטיס. הן מגיעות מזה שלא משלמים פעמיים על אותו לקוח.
