למה לקוחות נוטשים בדיוק בעמוד התשלום בחנות שלכם?
בדוח נטישת עגלה כל הנוטשים נראים אותו דבר. מישהו הגיע לעמוד התשלום ולא סיים, וזהו. אבל מאחורי המספר האחיד הזה מסתתרים שני אנשים שונים לגמרי: אחד שראה את דמי המשלוח והחליט שלא, ואחד שלחץ על כפתור התשלום וקיבל מסך שנתקע. הראשון קיבל החלטה, ואפשר להשפיע עליה בשינוי מסחרי. השני נתקל בתקלה, והוא היה משלם. הבעיה היא שבמסך אחד הם נראים זהים, ולכן חנויות מבזבזות חודשים על שיפור נראות הכפתור כשהתשלום עצמו נופל שקט אצל חלק מהלקוחות. יש דרך פשוטה להפריד ביניהם, והיא נמצאת בתוך מסך ההזמנות שלכם כבר עכשיו. במאמר הזה תמצאו איך מודדים איזה מהשניים קורה אצלכם, אילו תקלות שקטות עוצרות תשלומים בלי לייצר שום הודעת שגיאה גלויה, למה מטמון בעמוד התשלום הוא חשוד קבוע, ואיזו סדרת הזמנות מבחן חושפת את רוב המקרים בשעה אחת.
תוכן העניינים 8 פרקים
שתי נטישות שנראות זהות בדוח
נטישה מסחרית היא לקוח שהבין משהו חדש ושינה את דעתו. דמי משלוח שהתגלו רק בסוף, זמן אספקה שלא מתאים, דרישה לפתוח חשבון, או פשוט התלבטות שנדחתה למחר. הכלים לטיפול בה הם מסחריים: לתמחר משלוח בשקיפות מוקדם יותר, לאפשר רכישה בלי הרשמה, להוסיף אמצעי תשלום מקובל.
נטישה טכנית היא לקוח שרצה לשלם ולא הצליח. הכפתור לא הגיב, המסך חזר לעגלה, ההודעה שהתקבלה הייתה כללית וחסרת פשר, או שהחיוב עבר אבל האישור לא הגיע והוא לא ידע אם שילם. אין כאן שום שיקול מסחרי. יש רק כשל.
ההבדל המעשי גדול. חנות שמנסה לפתור בעיה טכנית בכלים מסחריים תשקיע בעיצוב, בהנחה ובתזכורות, והמספרים לא יזוזו. ולהיפך, חנות שמנסה לפתור בעיה מסחרית בבדיקות טכניות תבזבז ימים על מערכת שעובדת בסדר גמור. לכן זו השאלה הראשונה, לא השנייה.
הזמנות שנתקעו בהמתנה הן הראיה הכי טובה שיש
הנה הנקודה שמסבירה את כל השאר. כשלקוח לוחץ על כפתור ההזמנה, WooCommerce יוצר רשומת הזמנה עוד לפני שהתשובה חוזרת מחברת הסליקה, ומסמן אותה כממתינה לתשלום. רק כשמגיעה תשובה מהסליקה היא עוברת למצב אחר: התקבל תשלום, נכשל, או בוטל.
מכאן נגזרת בדיקה שאפשר לעשות בחמש דקות בלי שום כלי חיצוני. פתחו את רשימת ההזמנות של החודש האחרון וספרו לפי מצב:
- אין רשומה בכלל עבור מבקר שהגיע לעמוד התשלום ולא סיים: הוא עזב לפני שלחץ. זו נטישה מסחרית או בעיה בטופס עצמו.
- הזמנות רבות שנשארו בהמתנה לתשלום ולא זזו יותר: הלקוח לחץ, הגיע לסליקה, ומשם משהו לא חזר. זו תקלה טכנית עד שהוכח אחרת.
- הזמנות שנכשלו בכמות חריגה: לרוב סירוב מצד חברת האשראי, אבל גם תצורה שגויה של חשבון הסליקה נראית כך.
- פער בין מספר העסקאות בממשק חברת הסליקה לבין ההזמנות ששולמו באתר באותו יום: זהו הדגל האדום הברור ביותר, והוא מצביע כמעט תמיד על הודעת עדכון מהסליקה שלא מגיעה לאתר.
המקרה האחרון הוא היקר ביותר, כי הלקוח שילם ולא קיבל אישור. חלק מהלקוחות ינסו שוב וייווצר חיוב כפול, וחלק ידרשו החזר ולא יחזרו. פתחו הזמנה אחת כזאת והסתכלו על הערות ההזמנה שלה. WooCommerce כותב שם את התשובות שהתקבלו מהסליקה, וההערה הזאת חוסכת שעות ניחושים.
התקלות השקטות שעוצרות תשלום
| מה הלקוח חווה | מה זה בדרך כלל | איפה בודקים |
|---|---|---|
| שילם, לא קיבל מייל אישור, ההזמנה נשארה בהמתנה | הודעת העדכון מהסליקה נחסמת לפני שהיא מגיעה לאתר, לרוב על ידי חומת אש או תוסף אבטחה | הערות ההזמנה, ולוג החסימות של שכבת האבטחה באותה שעה |
| לוחץ לשלם והמסך חוזר לעגלה ריקה | איבוד הפעלה, לרוב מטמון על עמודי הקופה או בעיית עוגיות בין הדומיין לגרסה עם www | האם עמודי העגלה, הקופה והחשבון מוחרגים ממטמון |
| הודעה כללית שלא ניתן היה לעבד את ההזמנה, נסו שוב | אסימון האבטחה של הטופס פג, כמעט תמיד תוצאה של עמוד ששמור במטמון | אותה בדיקה, ובנוסף שכבת מטמון בצד השרת או ברשת המסירה |
| אין אף אמצעי משלוח לבחירה | אזור משלוח שלא מכסה את הכתובת, או כלל מחיר שמחזיר ריק | הגדרות אזורי המשלוח מול כתובת אמיתית מאותו אזור |
| הכל עובד במחשב ונופל בנייד | מעבר לדף סליקה חיצוני מתוך דפדפן פנימי של אפליקציה, שמאבד את ההפעלה | בדיקה מקישור בפרסום ברשת חברתית, לא מדפדפן רגיל |
| הכפתור לא מגיב בכלל | סקריפט של הסליקה נחסם, לעיתים בגלל רכיב שנטען בלי הצפנה או תוסף כיווץ קבצים | לשונית הקונסולה בכלי הפיתוח, בזמן ניסיון תשלום אמיתי |
| נופל רק בעגלות גדולות | מגבלת זיכרון או זמן ריצה בשרת בעת יצירת הזמנה ארוכה | לוג שגיאות השרת בשעת הניסיון |
| שגיאה רק כשמזינים קופון | התנגשות בין תוסף הקופונים לתוסף מחירים או מע״מ | ניסיון אותה הזמנה בדיוק בלי קופון |
שימו לב לחוט המשותף. אף אחת מהתקלות האלה לא מייצרת התראה יזומה. החנות ממשיכה להיראות תקינה מבפנים, המכירות פשוט נמוכות ממה שהן היו אמורות להיות. לכן תיקון תקלות בקופה של WooCommerce מתחיל אצלי תמיד באבחון ולא בתיקון, והוא מתומחר מ-₪650 לתקלה, לפני מע״מ.
מטמון בעמוד התשלום, והשגיאה שהוא מייצר
זו התקלה שאני פוגש הכי הרבה, והיא כמעט תמיד תוצאה של כוונה טובה. מישהו רצה לזרז את החנות, התקין תוסף האצה, והפעיל אותו על כל האתר. הבעיה היא שעמודי העגלה, הקופה והחשבון האישי הם עמודים אישיים לכל מבקר, ולכן הם לא אמורים להישמר.
המנגנון: טופס ההזמנה מכיל אסימון אבטחה חד-פעמי עם תוקף מוגבל. כשעמוד שמור מוגש למבקר חדש, האסימון שבו כבר לא בתוקף עבורו, והשרת דוחה את ההזמנה. ההודעה שהלקוח מקבל היא כללית ולא מסבירה כלום, ולכן קשה לקשר בינה לבין המטמון.
מה לבדוק בפועל: שכל ארבעת העמודים האישיים מוחרגים מהמטמון, שהחרגה זהה קיימת גם בשכבת המטמון של השרת אם יש כזאת, וגם ברשת מסירת התוכן אם משתמשים בכזאת. חנויות רבות מחריגות בתוסף ושוכחות את שתי השכבות האחרות, והתסמין נשאר. סימן זיהוי טוב: התקלה מופיעה אצל מבקרים חדשים ולא אצלכם, כי אתם מחוברים והמטמון עוקף אתכם בכלל.
כשחישוב המשלוח לא מחזיר שום אפשרות
מסך הקופה שמציג הודעה שאין אמצעי משלוח זמין הוא עצירה מוחלטת. הלקוח לא יכול להמשיך גם אם הוא רוצה, והוא כמעט אף פעם לא יתקשר לספר לכם.
המקור כמעט תמיד בהגדרת אזורי המשלוח. אזור שמוגדר לפי רשימת ערים לא יזהה כתובת בעיר שלא ברשימה, אזור שמוגדר לפי מיקוד ייפול כשהלקוח לא הזין מיקוד או הזין אותו בפורמט אחר, וכלל מחיר שמותנה בסכום מינימלי לא יחזיר כלום מתחת לסכום. מספיק שאחד מהם לא מכוסה, ואין ברירת מחדל.
הפתרון המעשי הוא להגדיר אזור אחד רחב שמכסה את כל שאר המדינה, עם אמצעי משלוח בסיסי, ולתת לו לתפוס את כל מה שנופל בין הכיסאות. שווה גם לבדוק ידנית כתובת אמיתית מכל אזור שאתם מוכרים אליו, כולל יישוב קטן בפריפריה, ולא רק את הכתובת של המשרד. אם החנות משתמשת בחישוב מול חברת שילוח בזמן אמת, הוסיפו בדיקה שנייה: מה קורה כשהשירות של חברת השילוח לא זמין באותו רגע. חנות מתוכננת היטב נופלת אז לתעריף גיבוי, ולא למסך ריק.
הנטישות שהן החלטה ולא תקלה
אחרי שהצד הטכני נקי, נשאר החלק שהוא באמת שיקול של הלקוח. אין מספר קסם שאומר כמה נטישה נורמלית, וכל מי שנוקב באחוז מדויק עבור החנות שלכם עושה את זה בלי לדעת. מה שכן ידוע הוא איפה אנשים נעצרים:
- עלות משלוח שנחשפת רק בשלב האחרון. אם היא ידועה מראש, מדובר בהחלטה מוקדמת ולא באכזבה בסוף.
- חובת פתיחת חשבון לפני רכישה. אפשרות רכישה כאורח מסירה חיכוך אמיתי.
- היעדר אמצעי התשלום שהלקוח רגיל אליו.
- זמן אספקה שלא מופיע בשום מקום עד אחרי התשלום.
- טופס ארוך מדי, בעיקר בנייד, עם שדות שאינם באמת נחוצים.
- מדיניות החזרות שלא נמצאת במקום שרואים בזמן ההחלטה.
הרשימה הזאת היא עבודה של עיצוב ותכנון קופה, לא של תיקון תקלה. אם אחרי בדיקה טכנית מלאה מתברר שהקופה עובדת אבל התהליך עצמו מסורבל, זה כבר שיפור חנות. בניית חנות WooCommerce אצלי היא ₪5,800-₪22,000 חד-פעמי לפני מע״מ, כולל חיבור לסליקה ישראלית, חישוב משלוחים ואישורי הזמנה. לחנויות עם מלאי מורכב, חיבור לחברות שילוח והשוואת מוצרים, המסגרת היא חנות וירטואלית מתקדמת בטווח ₪5,800-₪35,000 חד-פעמי, גם כן לפני מע״מ.
שש הזמנות מבחן שחושפות את הרוב
זו הבדיקה שאני מריץ בכל חנות חדשה שמגיעה אליי, והיא לוקחת פחות משעה. השתמשו בסכום נמוך אמיתי, ובכרטיס אמיתי, כי סביבת בדיקה של חברת סליקה לא תמיד מתנהגת כמו הסביבה החיה.
- הזמנה רגילה במחשב, מדפדפן שבו אתם לא מחוברים לניהול.
- אותה הזמנה בטלפון, ברשת סלולרית ולא ברשת המשרד.
- הזמנה שנפתחת מקישור בפרסום ברשת חברתית, כדי לעבור דרך הדפדפן הפנימי של האפליקציה.
- הזמנה עם קופון.
- הזמנה לכתובת ביישוב מרוחק, לבדיקת אזורי המשלוח.
- הזמנה שנזנחת בכוונה בדף הסליקה, כדי לראות באיזה מצב היא נשארת במערכת.
אחרי כל אחת מהשש בדקו שלושה דברים: האם ההזמנה נוצרה, באיזה מצב היא, והאם המייל הגיע ללקוח וגם אליכם. אם אחת מהשש נכשלה, קיבלתם מקרה בדיקה שאפשר לשחזר, וזה כבר רוב האבחון. תעדו הכול בזמן אמת, כולל שעה, כי לוגים מתאימים לפי שעה.
לתקן תקלה או לבנות את הקופה מחדש
שאלה שכדאי לענות עליה במפורש, כי היא ההבדל בין הוצאה של מאות שקלים לבין פרויקט. תיקון מתאים כשהתסמין ממוקד וניתן לשחזור: אמצעי משלוח שנעלם, אישורים שלא נשלחים, סליקה שלא מעדכנת. אלה מקרים סגורים עם התחלה וסוף.
בנייה מחדש מתאימה כשהתשובה לשאלה מה שבור היא הכול קצת. חנות שנבנתה בשכבות על ידי כמה אנשים לאורך שנים, עם שלושה תוספים שמנסים לנהל את אותה קופה, מגיעה למצב שבו כל תיקון פותח תקלה אחרת. שם התיקון הממוקד מפסיק להיות כלכלי.
מבחן ההכרעה שאני משתמש בו פשוט: אם בשלושת החודשים האחרונים תיקנתם באותה קופה שלוש תקלות שונות, אתם כבר משלמים על בנייה מחדש בתשלומים, רק בלי לקבל אותה.
אם אתם חושדים שיש אצלכם נטישה טכנית ולא מסחרית, יש דרך מהירה לבדוק את זה: ספרו כמה הזמנות נשארו בהמתנה לתשלום החודש, והשוו למספר העסקאות בממשק חברת הסליקה. אם המספרים לא נפגשים, שלחו לי צילום מסך של שניהם ואומר לכם מה כנראה קורה. אבחון ותיקון של תקלת קופה הוא עבודה שאני מנהל מקצה לקצה, מול חברת הסליקה ומול האחסון אם צריך. הכי מהיר להשיג אותי בWhatsApp, ואם מדובר בחנות פעילה שמאבדת הזמנות כרגע, כתבו לי את זה בשורה הראשונה. דברו איתי בוואטסאפ ←
