תפסיקו להתווכח על נטישת עגלות: קבלו אישור לתיקוני קופה

תקציר

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

רוב העצות על נטישת עגלות נכתבות עבור אנשים שכבר יכולים לשנות את הקופה שלהם. הן אומרות לכם לפשט את הטופס, להוסיף קופת אורחים, להציג עלויות משלוח לפני השלב האחרון, כאילו הדבר היחיד שעומד ביניכם לבין שיעור המרה טוב יותר הוא לדעת מה לעשות. אם אתם בצוות שיווק פנימי קטן, זו רק לעתים נדירות הבעיה. אתם כבר יודעים מהם התיקונים. הבעיה היא שכל תיקון צריך לעבור שיחה עם בוס לא טכני שרוצה הוכחות, לוח זמנים והערכת עלויות לפני שמרשים לכם לגעת במשהו.

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

המאמר הזה עובר על חמש ההתנגדויות שעוצרות את רוב תיקוני הקופה, עם דוגמה רצה, ומסתיים בטבלה שתוכלו להביא לפגישת התקציב הבאה. הקו המנחה פשוט: המהלך הטוב ביותר של CRO שתוכלו לעשות ברבעון הזה הוא לא עיצוב מחדש. זה להפוך את השינוי הבא לקטן מספיק כך שהבוס שלכם יוכל להגיד כן בלי להרגיש שהוא מהמר.

"תראה לי את הנתונים" פירושו תראה לי את המשפך

נניח שאתם עובדים בחברת ציוד שטח קטנה. הבוסית שלכם הרגע אמרה לכם שעלויות המשלוח הורגות הזמנות. היא נשענת לאחור ואומרת, "זו טענה חזקה. יש לנו נתונים?" אין לכם כלי שמראה איפה הקונים נושרים. אתם מתחילים לדבר על הקלטות סשן ומעקב אירועים, והעיניים שלה מזוגגות. הפרויקט מת בפגישה.

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

הנה מה שעושים עם זה. פתחו חלון גלישה בסתר ועברו לדף המוצר שלכם. הוסיפו תרמיל גב לסל. עכשיו גללו לאט, צלמו מסך בכל שלב. מתי הלקוח רואה לראשונה את העלות הכוללת, כולל משלוח? ספרו את המסכים בין "הוספה לסל" לבין "יחויבו במספר הזה". נסו לבצע קופה בלי ליצור חשבון ושימו לב לרגע המדויק שבו אתם נחסמים. מצאו את מדיניות ההחזרות ושימו לב כמה לחיצות נדרשות כדי לקרוא אותה. עשו את כל זה שוב בטלפון, שם הפריסה תמיד מתנהגת אחרת.

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

פרט אחד שהופך את הבדיקה לחדה יותר: עשו אותה עם קולגה שמעולם לא ראה את האתר שלכם. תופתעו ממה שאתם מפספסים כשאתם רגילים למערכת. בקשו ממנו לדבר בקול רם בזמן שהוא מנסה לקנות משהו. אתם לא מנהלים מעבדת שימושיות; אתם מקשיבים לרגעים שבהם אדם רגיל אומר "רגע, מה?" אלה הרגעים שבהם חיים הגורמים לנטישה.

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

העיקרון הכללי: לפני שאתם מבקשים שינוי, תנו למנהל שלכם משהו שהוא יכול לראות ולאמת, לא טענה שצריך לקחת באמונה. צילום מסך שווה יותר מתחזית. בדיקה כזו גם עוזרת לכם להימנע מתקלת הכישלון הנפוצה ביותר של CRO בצוות קטן—הצעת תיקון לבעיה שלא באמת אישרתם שקיימת. אם אתם תוהים אם הבעיה היא הקופה עצמה או משהו מוקדם יותר במשפך, מאמר קודם על אבחון הסיבה האמיתית לנטישה הוא שלב הבא שימושי.

"אין לנו זמן פיתוח" בדרך כלל אומר שלא הפרדתם הגדרות מקוד

הבוס שלכם שומע "אופטימיזציית קופה" ומדמיין מפתח שעובד שבועיים. אתם יודעים שתור הפיתוח ארוך בשלושה חודשים, אז אפילו לא טורחים לשאול. אבל רוב התיקונים ברשימת הנטישה הסטנדרטית לא דורשים מפתח כלל.

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

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

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

קטגוריה נוספת: דף אישור ההזמנה והמייל. אם האישור הוא גנרי או לא מציב ציפיות למשלוח, זה עוד משטח שבבעלות השיווק. אפשר לשכתב אותו בלי לגעת במערכת ההזמנות. לקוחות שיודעים מה יקרה הלאה נוטים פחות לפנות לתמיכה, ונפח מיילי התמיכה הוא מדד שהבוס שלכם יבין.

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

"כבר ניסינו פישוט" פירושו שתיקנתם את הגורם הלא נכון

לפני חצי שנה, מישהו בצוות שלכם הסיר שלושה שדות מטופס הקופה. הבוס הצביע על כך כראיה ש"כבר ניסינו CRO." ההזמנות לא השתנו. עכשיו אתם מציעים תיקון שקשור לאמון, והבוס אומר, "למה שזה יהיה שונה?"

הסיבה שזה יהיה שונה היא שפישוט טופס ובניית אמון פותרים בעיות שונות. מחקר וניסיון יומיומי מצביעים על כך שאנשים נוטשים עגלות כשהם לא סומכים על החנות—כשמדיניות ההחזרות לא ברורה, אפשרויות התשלום נראות דלות, או התחום נראה לא מוכר. אם זו הסיבה השורשית, טופס קצר יותר לא עוזר. דמיינו שקונים תרמיל גב יקר מחנות שמעולם לא שמעתם עליה. הקופה היא שלושה שדות, נקיים ככל האפשר. אתם עדיין מהססים, כי הסיכון הוא לא הטופס—אלא אם הדבר יגיע, והאם תוכלו להחזיר אותו אם לא. ההיסוס הזה הוא לא בעיית UX; זו בעיית שכנוע.

איך יודעים אם אמון הוא הגורם? בוחנים את הפרטים. האם המוצרים שלכם יקרים יחסית לסיכון שלקוח אימפולסיבי היה לוקח? האם החנות שלכם חדשה או שהתחום נראה יוצא דופן? האם אין מדיניות החזרות ליד כפתור הקנייה? האם אין ביקורות או יש מעט מאוד? אם עניתם כן לכמה מהשאלות, סביר שאמון הוא גורם גדול יותר מאורך הטופס. אם הטופס שלכם באמת ארוך—עשרה שדות ויותר, עם שדות אופציונליים שלא רלוונטיים—אז מורכבות עשויה להיות הבעיה. הנקודה היא שצריך לבדוק, לא לנחש.

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

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

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

"אנחנו צריכים תוכנית קודם" הוא בעצם בקשה לתהליך

הבוס שלכם אומר, "בסדר, שכנעת אותי שיש בעיה. עכשיו תכתוב לי תוכנית." אתם קופאים, כי אתם מדמיינים תוכנית ניסויים בת שנה עם מובהקות סטטיסטית ומפת דרכים. אתם יודעים שאין לכם את התנועה או התקציב לזה, אז אתם נתקעים.

תוכנית לא חייבת להיות שאפתנית. היא יכולה להיות לולאה אחת: לבחור גורם אחד מרשימת הנטישה, למצוא את המסך שבו הוא נכשל, לבצע שינוי אחד, ולעקוב אחר מדד אחד. ואז לעבור לגורם הבא.

בואו נעשה את זה קונקרטי עם חברת ציוד השטח. הבדיקה שלכם מצאה שמשלוח מפתיע אנשים בדף התשלום. התוכנית שלכם לחודש הזה היא: להוסיף שורה לדף הסל שאומרת שהמשלוח מחושב בקופה ושתמיד תציגו אותו לפני התשלום. המדד שאתם עוקבים אחריו הוא מספר מיילי התמיכה ששואלים על משלוח, בתוספת מבט פשוט לפני ואחרי בכמה אנשים שמגיעים לדף התשלום באמת משלימים את ההזמנה. זהו. אם מיילי התמיכה יורדים והשלמת הקופה לא יורדת, שיפרתם את החוויה. בחודש הבא תעלו את הקישור למדיניות ההחזרות. בחודש שאחריו, אם הפלטפורמה מאפשרת, תפעילו קופת אורחים. זו תוכנית.

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

הסייג כאן הוא על אי-שינוי של יותר מדי דברים בבת אחת. באתר קטן, אתם צריכים לדעת איזה שינוי הביא לתוצאה. שינוי אחד בשבוע או בחודש הוא איטי להתרברבות אבל מהיר ללמידה. מבחני A/B הם מותרות; עבור כשל ברור, מבט לפני ואחרי במדד שחשוב לכם הוא לעתים קרובות מספיק כדי להצדיק את הצעד הבא. אם אתם רוצים גרסה פורמלית יותר של הלולאה הזו, המדריך שלנו לבניית תהליך CRO שאפשר לחזור עליו עבור לקוחות מסחר אלקטרוני פורש את השלבים.

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

"זה לא התפקיד של השיווק" נעלם כשאתם הבעלים של המסר

בפגישה, המפתח אומר שהקופה בסדר. איש המוצר אומר שזו בעיית זרימת עבודה. הבוס שלכם אומר שמישהו צריך לקחת בעלות, וכולם מסתכלים על הרצפה. אתם דואגים שלשיווק אין סמכות על הקופה, אז אתם שותקים.

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

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

יש גרסה עמוקה יותר של ההתנגדות הזו שראוי להזכיר. אם החברה שלכם מתייחסת ל-CRO כאל משהו שמומחה עושה, הצוות הפנימי הקטן מרגיש פעמים רבות לא מוסמך. אבל אתם לא צריכים להיות סטטיסטיקאים כדי לתפוס כשל מסרים. אתם צריכים להיות האנשים ששמים לב שדף הסל מבטיח דבר אחד ודף התשלום מספק אחר. זה כישור שיווקי, לא תואר במדעי הנתונים. אם אתם לחוצים לגבי התהליך, התחילו עם המאמר על הדליפה הנסתרת, שנכתב עבור צוותים בדיוק במצב הזה.

טבלת עזר לפגישת התקציב הבאה

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

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

"מה אם זה יחמיר את המצב?" ראוי לתשובה ישירה

ההתנגדות האחרונה היא זו שעוצרת אנשים באמצע הדרך כי היא חכמה. הבוס שלכם אומר, "אם נפעיל קופת אורחים, נאבד את כל הלקוחות החוזרים שלנו." אתם מרגישים בפינה כי זו תוצאה סבירה.

התשובה הכנה היא שקופת אורחים היא לא הכל או כלום. המחיר הוא אמיתי, אבל אפשר לתכנן סביבו: תנו לאנשים לבצע קופה כאורחים, ואז בקשו מהם ליצור חשבון אחרי ההזמנה עם הטבה שהם באמת מעריכים—מעקב הזמנות, הזמנה חוזרת מהירה, נקודות נאמנות. כך תוכלו לשמור על רוב התועלת בהמרה ועדיין לתת ללקוחות סיבה להירשם.

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

הנקודה העמוקה יותר היא שכל תיקון המרה הוא עסקת חליפין, והחליפין תלויים במודל העסקי שלכם. אם אתם מנהלים שירות מנויים שתלוי בחשבונות, קופת אורחים גורפת עלולה באמת להזיק לכם. השאלה הנכונה היא לא "האם קופת אורחים טובה?" אלא "מה אנחנו מוכנים להחליף ומה אנחנו יכולים לעשות במקום?" זה הניואנס שרשימות עם שיטות מומלצות גנריות מפספסות, וזו הסיבה שהשיקול של צוות קטן חשוב יותר מרשימת בדיקה.

אותו היגיון חליפין חל על אמצעי תשלום. אפשרויות תשלום מוגבלות הן סיבה נפוצה לנטישה—אבל הוספת אפשרויות נוספות לא עולה בחינם. כל אמצעי נוסף מוסיף התקנה, עמלות, סיכון הונאה ושאלות תמיכה. אם רוב הלקוחות שלכם כבר משלמים בדרך אחת, רשימה ארוכה של לוגואים אולי תיראה מרשימה בלי לשנות התנהגות. המהלך הוא לבדוק מה הלקוחות שלכם באמת משתמשים בו, לא לשקף את החנות הגדולה ביותר שתמצאו.

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

סיכום: הפכו את השינוי הבא לקטן מספיק כדי להגיד כן

התמודדות עם התנגדויות היא לא מיומנות רכה. זה תעדוף. כשהבוס שלכם מבקש נתונים, הוא אומר לכם שהפרויקט מופשט מדי. כשהוא אומר שאין זמן מפתח, הוא אומר לכם שהפרויקט נשמע גדול מדי. כשהוא אומר שזה לא עבד לפני, הוא אומר לכם שהגורם מעולם לא אושר. כינו את החוסם האמיתי, והפתרון נהיה קטן יותר, גלוי יותר והפיך יותר.

בדיקה של עמוד אחד, משפט אחד בדף הסל, קופת אורחים כהגדרה, קישור למדיניות החזרות שהוזז לחיצה אחת קרוב יותר להחלטה—אף אחד מאלה לא יגרום לכם להרגיש שאתם עושים CRO "אמיתי". אבל הם השינויים שישרדו שיחה עם בוס לא טכני, כי הם עולים מעט, לוקחים ימים, ואפשר לבטל אותם אם הם לא עובדים. התחילו עם הדליפה האחת שאתם כבר יודעים עליה, תנו לבוס שלכם משהו ללחוץ עליו, ותנו לתוצאה לשאת את הוויכוח הבא.

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