הזמנה שנכנסת ככרטיס לקוח שווה יותר מהזמנה שיושבת בחנות.
חיבור החנות למערכת גורם לכך שכל הזמנה נכנסת ככרטיס לקוח — עם מה נקנה, מתי, ובכמה. מכאן אפשר לעשות דברים שהחנות לבדה לא עושה: לזהות לקוח חוזר, לפנות אחרי הקנייה, ולדעת איזה קמפיין הביא רכישה ולא רק ליד. החיבור נעשה דרך webhooks, ומה שקובע אם הוא אמין הוא כמה אירועים מוגדרים ולא רק אחד.
החנות מודיעה למערכת על אירועים; המערכת רושמת.
המנגנון עצמו פשוט. כשקורה משהו בחנות, היא שולחת הודעה לכתובת שהגדרתם, והמערכת שמאזינה שם רושמת את מה שקיבלה. זה קורה מיד, בלי שאיש ילחץ על כלום.
מה שחשוב להבין הוא שהחנות אינה מחכה לתשובה. היא ממשיכה כרגיל בין אם המערכת קיבלה ובין אם לא, ולכן הלקוח לא מרגיש דבר — וגם לא ידע אם משהו נכשל.
וזה מסביר למה הצד שמקבל צריך להיות זמין תמיד. הודעה שנשלחה לכתובת שלא ענתה עלולה פשוט להיעלם, ואין מי שיבקש אותה שוב.
מכאן שהחיבור אינו פרויקט אלא הגדרה: כתובת אחת בצד החנות, ואירועים שמסמנים מה לשלוח אליה. רוב העבודה היא להחליט מה בדיוק מוגדר, ולא איך מחברים.
וכדאי לבדוק את זה בפועל ולא להניח. הזמנת ניסיון היא הדרך הזולה ביותר לוודא שהכרטיס נוצר, ושמה שהגיע בו הוא מה שציפיתם.
אותה בדיקה שווה גם אחרי כל שינוי בחנות. תבנית שהוחלפה או תוסף שנוסף יכולים לשנות את מה שנשלח, ואף אחד לא יודיע על כך.
מי שמגדיר רק "הזמנה נוצרה" מקבל תמונה שקופאת. לקוח ששילם ימשיך להיחשב כמי שלא סיים, ותזכורת עגלה נטושה תישלח למי שכבר קנה. האירוע השני — עדכון הזמנה — הוא מה שסוגר את הלולאה.
האירוע הראשון קל להגדיר, והוא גם זה שנראה מספיק. הזמנה נוצרה, הכרטיס נרשם, הכל עובד — עד שמישהו משלם ואף אחד לא מודיע על כך.
מרגע זה המערכת מחזיקה תמונה מיושנת. היא יודעת שההזמנה קיימת ולא יודעת שהיא הושלמה, ולכן כל דבר שנשען על המצב שלה פועל לפי מידע שגוי.
וזה בדיוק מה שהופך תזכורת עגלה נטושה לאמינה או למביכה. עם האירוע השני היא נעצרת מעצמה כשההזמנה שולמה; בלעדיו היא תצא בכל מקרה.
אותו דבר נכון לביטולים והחזרים. לקוח שביטל וממשיך להיחשב כרוכש יקבל פנייה מיותרת, וגם הדוחות יספרו אותו.
ולכן הכלל הוא להגדיר את שני האירועים יחד מלכתחילה. אין כאן עבודה נוספת של ממש, ויש כאן את ההבדל בין מערכת שיודעת מה קורה לבין מערכת שיודעת מה קרה פעם.
יש גם דרך לגלות אם רק אחד מהם מוגדר: לבדוק אם יש הזמנות שנשארו לנצח באותו מצב. רשומה שלא זזה מיום היווצרותה היא רשומה שאיש לא עדכן.
וכשמוסיפים את האירוע השני מאוחר יותר, כדאי לזכור שהוא אינו מתקן אחורה. ההזמנות הישנות יישארו במצב שבו נתקעו.
מונה רכישות, סכום מצטבר, ומה נקנה.
| בחנות | בכרטיס הלקוח | |
|---|---|---|
| היסטוריית הזמנות | יש | יש |
| מונה רכישות | לא תמיד | יש |
| סכום מצטבר | לא תמיד | יש |
| פנייה יזומה | אין | אפשרית |
| מקור הפנייה | אין | נשמר |
מונה הרכישות הוא השדה שהכי משנה: הוא מפריד בין לקוח חדש לקיים. השניים דורשים פנייה שונה לגמרי, והחנות לבדה אינה מבדילה ביניהם.
הסכום המצטבר מוסיף את הממד השני. הוא אינו אומר לכם מי לקוח טוב, אבל הוא מאפשר להפריד בין מי שקנה פעם אחת בקטן לבין מי שחוזר ומוציא.
ומה שנקנה הוא מה שהופך פנייה עתידית לרלוונטית. המלצה שנובעת ממה שכבר נרכש נקראת אחרת מהודעה שנשלחה לכולם.
כדאי גם להחליט מראש מה נשמר ומה לא. שדות שנשמרים "ליתר ביטחון" ואיש אינו משתמש בהם מוסיפים רעש, ולפעמים גם מידע שעדיף שלא יישב אצלכם.
והכלל הוא לשמור את מה שישנה החלטה. מונה, סכום ומה נקנה עונים כמעט על כל שאלה שעסק קטן שואל על לקוח.
אותו אדם שקנה פעמיים צריך להיות כרטיס אחד. אחרת הוא יקבל כל הודעה פעמיים.
וזה לא רק מטרד. כרטיס מפוצל מאפס את המונה בכל רכישה, ולכן לקוח חוזר ייראה לנצח כמו לקוח חדש — וכל מה שבנוי על ההבחנה הזו יפעל הפוך.
קונה כאורח מול מחובר, מייל שהשתנה, והזמנה שנוצרה בטלפון ולא באתר.
רכישה כאורח היא המקרה הנפוץ. אין חשבון, ולכן אין מזהה קבוע — והזיהוי נשען על מה שהוקלד באותה הזמנה. מי שהקליד אחרת בפעם הבאה ייפתח ככרטיס חדש.
מייל שהשתנה עושה את אותו דבר בשקט. אדם שעבר מקום עבודה או פתח כתובת אחרת הוא מבחינת המערכת אדם אחר, גם אם הטלפון נשאר זהה.
ולכן שווה לבחור מראש לפי מה מזהים, ולהעדיף שדה שאנשים משנים פחות. אחידות בשמירה חשובה כאן יותר מהשדה עצמו — אותו ערך שנשמר באותה צורה בכל פעם.
המקרה השלישי הוא הזמנה שלא עברה דרך האתר בכלל. רכישה שנרשמה ידנית או שהתקבלה בטלפון אינה מפעילה שום אירוע, ולכן היא לא תגיע למערכת אלא אם מישהו יכניס אותה.
וכשמשהו כן נשבר, הסימן הוא בדרך כלל שקט. אין שגיאה ואין התראה — פשוט מפסיקים להיכנס כרטיסים, ומגלים את זה כשמישהו שואל למה אין הזמנות חדשות.
לכן שווה שיהיה סימן חיים כלשהו שמישהו מסתכל עליו. אפילו הרגל של מבט מהיר על הכרטיסים החדשים בסוף היום מגלה שקט חריג הרבה לפני שהוא הופך לשבוע חסר.
ומי שמחבר יותר מחנות אחת צריך גם לדעת מאיזו מהן הגיעה כל הזמנה. בלי סימון כזה, שקט בחנות אחת נבלע בתנועה של השנייה.
החיבור אינו מייבא לקוחות ישנים בעצמו, ואינו מחליף את החנות. הוא מוסיף שכבת קשר, לא שכבת מסחר.
האירועים מתחילים לפעול מרגע שהוגדרו, וכל מה שקרה לפני כן נשאר בחנות בלבד. ייבוא היסטוריה אפשרי, אבל הוא פעולה נפרדת שמישהו צריך להחליט עליה ולבצע.
וגם אחרי החיבור, החנות ממשיכה להיות המקום שבו מתבצעת המכירה. המלאי, המחירים, התשלום והמשלוח נשארים שם, והמערכת אינה יודעת עליהם ואינה מנהלת אותם.
מה שכן נוסף הוא כל מה שקורה סביב העסקה: מי הלקוח, מה הוא קנה קודם, מאיפה הוא הגיע, ומה נכון לשלוח לו אחר כך.
ובזכות זה אפשר גם לסגור את מעגל המדידה. רכישה שנרשמת במערכת יחד עם המקור שהביא אותה הופכת את השאלה "איזה קמפיין משתלם" לשאלה שיש לה תשובה.
ולכן שווה לגשת לזה בסדר הזה: קודם להגדיר את שני האירועים, אחר כך לוודא שהזיהוי החוזר עובד, ורק בסוף לבנות על זה אוטומציות. הפוך מזה מייצר אוטומציה שרצה על נתונים חלקיים.
וכדאי לזכור שהחיבור עצמו אינו המטרה. הוא מה שמאפשר את מה שבא אחריו, ואם אף אוטומציה אינה רצה עליו הוא רק מייצר רשומות שאיש אינו קורא.
ולכן שווה להתחיל מדבר אחד שרוצים שיקרה — תזכורת, פנייה אחרי הקנייה, או דוח לפי מקור — ולבנות את החיבור כך שישרת אותו.
ככה עושים את זה ידנית.
וככה זה נראה כשהמערכת עושה את זה בשבילך.