כשמכירות נתקעות, ההצעה שעולה ראשונה כמעט תמיד היא לבנות אתר חדש בפלטפורמה אחרת. ההנחה מאחוריה היא שהמערכת הנוכחית מגבילה, בזמן שברוב המקרים המערכת בכלל לא מוצתה ומה שחסר הוא מבנה, תוכן וחווית קנייה. מעבר פלטפורמת איקומרס הוא מהלך יקר בזמן ומסוכן בקידום, ולכן הוא צריך להיות מסקנה של אבחון ולא נקודת פתיחה. השאלה האמיתית היא לא איזו מערכת טובה יותר, אלא מה בדיוק לא עובד היום ואם המערכת שלכם באמת חוסמת את התיקון.
להפריד בין בעיית פלטפורמה לבעיית תפעול
יש שני סוגי בעיות שנראות זהות מבחוץ. בעיית פלטפורמה היא כשהמערכת פיזית לא יודעת לעשות משהו שהעסק חייב: סוג וריאציה שאין לו שדה, מודל תמחור שאין לו לוגיקה, ממשק לספק שלא קיים. בעיית תפעול היא כשהמערכת יודעת לעשות את זה, אבל אף אחד לא הגדיר, לא מילא ולא סידר.
מה שקורה בפועל הוא שרוב מה שמתויג כמגבלה של המערכת הוא פשוט משהו שלא הופעל. מודול שקיים בממשק ואף אחד לא הדליק, שדות תוכן שנשארו ריקים, עץ קטגוריות שנבנה פעם אחת בהקמה ולא נגעו בו מאז. זה אומר שהמערכת החדשה תקבל בדיוק את אותה חנות, רק בעיצוב אחר.
לפני שמדברים על החלפה, שווה לענות על שאלה אחת: אם מישהו היה מקדיש חודש לסידור החנות הקיימת, מה בדיוק היה נשאר שבור. התשובה לשאלה הזאת היא כל ההבדל בין שדרוג האתר הקיים לבין פרויקט הקמה מחדש.
לרשום מה בדיוק לא עובד היום
הבעיה מתחילה כשהאבחון נשאר ברמת התחושה. האתר מיושן, המכירות לא מספיקות, המתחרים נראים טוב יותר. אלה לא ממצאים, אלה רגשות, ואי אפשר לבחור מערכת על בסיס רגשות.
ממצא הוא משהו שאפשר להצביע עליו במסך. זה סוג הרשימה שצריכה להיות על השולחן לפני כל דיון על פלטפורמה:
- אין כפתורי קנייה בקוביית המוצר, רק בבאובר, ולכן במובייל הם לא מופיעים בכלל
- שורת החיפוש סגורה מאחורי אייקון קטן במובייל
- אין דף מקשר בין קטגוריה ראשית לבין מאות מוצרים
- הדרופ מציג רשימת טקסטים בלי תמונות צרובות
- המפרט הטכני מוצג כפסקה רצה ולא בטבלה
- אין גוגל טייטל ודיסקריפשיין ייחודיים למחלקות ולתתי מחלקות
- זמן טעינה מעל 5 שניות בעמודי קטגוריה
כשהרשימה הזאת מונחת מולכם ההחלטה משתנה. שבעה סעיפים כאלה זה לא פרויקט הגירה, זה כמה שבועות של עבודה מסודרת במערכת שכבר יש לכם.
לבדוק אילו יכולות המערכת מאפשרת ולא מומשו
כל פלטפורמת סחר בוגרת מגיעה עם הרבה יותר יכולות ממה שחנות ממוצעת משתמשת בהן. בקונימבו למשל יש שכבה שלמה של מודולים שיושבת בממשק ומחכה: סרגל אייקונים, דרופ עם תמונה, מודול קטגוריות, דף יצרן, דף מקשר, חיפוש פתוח, מבט מהיר, וישליסט, קוביית גריד, מודול וואטסאפ ואמצעי תשלום נוספים כמו ביט והעברה בנקאית.
בגדול, המצב הרגיל הוא שחנות מפעילה שליש מזה. אחרי 10 שנים ומעל 60 חנויות, הדפוס חוזר על עצמו כמעט תמיד: החנות עלתה לאוויר עם הגדרות ברירת מחדל, המכירות התחילו, ואף אחד לא חזר לממשק כדי לראות מה עוד יש שם.
הסיבה לזה פשוטה ולא קשורה לעצלות. מי שמנהל חנות עסוק בהזמנות, במלאי ובספקים, ולא בסריקת מסכי הגדרות. מודול שלא הופעל בהקמה נשאר כבוי לנצח, כי אין רגע בשגרה שבו מישהו עוצר ובודק מה עוד המערכת יודעת לעשות.
לפני שמכריזים שהמערכת מגבילה צריך מיפוי מלא של מה היא מציעה מול מה שמופעל בפועל. פער גדול בין השניים אומר שהבעיה היא לא המערכת. פער קטן, כלומר מערכת שמוצתה עד הסוף ועדיין לא מספיקה, זה כבר ממצא אמיתי שמצדיק דיון על החלפה.
להעריך את גודל הקטלוג ואת מורכבות הווריאציות
גודל הקטלוג הוא הגורם שהכי מזלזלים בו והכי קובע. חנות עם 200 מוצרים פשוטים היא פרויקט אחד. חנות כלי עבודה עם 2,000 מק"טים, וריאציות, ברקודי EAN, שיוך למחלקות ראשיות ומשניות ומפרט טכני מלא לכל פריט, היא עולם אחר לגמרי.
מה שקורה בפועל בהעברת קטלוג גדול הוא שהנתונים עוברים והתוכן נשאר מאחור. שדות שלא קיימים במערכת היעד נופלים בשקט, וריאציות מתמזגות לפריט אחד, ותמונות מגיעות בלי ALTים. בקטלוג של אלפי פריטים אף אחד לא מגלה את זה ביום ההשקה.
לפני החלטה כדאי למפות את המבנה של הקטלוג שלכם:
- כמה מק"טים פעילים באמת ולא כמה שורות יש בקובץ הייצוא
- אילו מוצרים מחזיקים וריאציות וכמה גרסאות לכל אחד
- אילו שדות מותאמים אישית נמצאים בשימוש
- כמה עומק יש בעץ הקטגוריות וכמה שיוכים משניים קיימים
- איפה יושב המפרט הטכני ובאיזה פורמט
המיפוי הזה הוא גם הבסיס להערכת העבודה וגם הבדיקה הראשונה שהמערכת החדשה בכלל יודעת להחזיק את מה שיש לכם.
בכל מקרה, ככל שהקטלוג גדול יותר כך מאזן הסיכון נוטה נגד המעבר. בחנות קטנה אפשר לעבור על כל המוצרים ידנית אחרי ההעברה ולתקן מה שנשבר. בחנות עם אלפי פריטים אין שום סיכוי לעשות את זה, ולכן כל טעות במיפוי השדות מכפילה את עצמה על פני כל הקטלוג ונשארת שם.
להשוות מערכות לפי מה שהחנות צריכה
השוואת פלטפורמות ברשת מגיעה כמעט תמיד כטבלה של סימני וי. הבעיה בטבלה הזאת היא שהיא נכתבת בלי להכיר את החנות שלכם, ולכן היא נותנת משקל זהה ליכולת שתשתמשו בה כל יום וליכולת שלא תיגעו בה לעולם.
השוואה שימושית עובדת הפוך. קודם כל לוקחים את חמש הפעולות שהעסק מבצע הכי הרבה, ואז בודקים כמה קליקים כל אחת מהן דורשת בכל מערכת. אם רוב הזמן שלכם הולך על עדכון מלאי ומחירים והוספת מוצרים, מערכת עם ממשק ייבוא וייצוא נוח שווה יותר מכל רשימת פיצרים ארוכה.
מה שכן, יש הבדל בין מה שאני יודע ממקור ראשון לבין מה שאני מכיר מהצד. אני עובד בעיקר עם קונימבו ואישופ, ובקונימבו הרקע שלי הוא מבפנים, מהתקופה שעבדתי בחברה עצמה. על Wix ועל Shopify אני יכול להגיד שאלה פלטפורמות רציניות, אבל אני לא מנהל עליהן חנויות ביום יום ולכן לא אתיימר להשוות אותן ברמת התפעול. אם המועמדת שלכם היא מערכת כזאת, כדאי שהצד השני של ההשוואה יגיע ממישהו שחי בתוכה.
לחשב את העלות האמיתית של מעבר
העלות שמדברים עליה בשיחת המכירה היא בניית האתר. העלות האמיתית מורכבת מכמה שכבות שאף אחת מהן לא מופיעה בהצעה הראשונה.
אלה הקטגוריות שצריך להניח על השולחן לפני שמחליטים:
- זמן ניהולי שלכם ושל הצוות לאורך כל הפרויקט, לא רק בישיבות
- העברת תוכן וכתיבה מחדש של כל מה שלא עובר בייצוא
- הגדרות מערכת: משלוחים, סליקה, מיסים, מועדון לקוחות, אזורי שירות
- בדיקות קבלה לפני העלייה לאוויר ותיקונים אחריה
- ירידה זמנית בתנועה ובהזמנות בתקופת ההתייצבות
- הכשרה מחדש של מי שמתפעל את החנות בפועל
אני לא נותן כאן מספרים כי הם משתנים לגמרי לפי גודל הקטלוג ולפי מצב התוכן הקיים. הנקודה היא אחרת: כשמניחים את שש השכבות זו לצד זו, המעבר מפסיק להיראות כמו פרויקט טכני ומתחיל להיראות כמו מה שהוא באמת, פרויקט שנוגע בכל חלק בעסק.
להעריך את הסיכון הקידומי במעבר פלטפורמת איקומרס
כאן נכנס החלק שהכי קשה לתקן בדיעבד. אתר שדורג שנים בונה נכס שלא מופיע בשום קובץ ייצוא: היסטוריה של כתובות, אמון של גוגל, קישורים חיצוניים שמצביעים על דפים ספציפיים, ודפי קטגוריה שצברו מיקום על ביטויים מסחריים.
מעבר פלטפורמת איקומרס מטלטל את כל אלה בבת אחת. גם כשהכל נעשה נכון יש תקופת התייצבות שבה גוגל סורק מחדש ומעריך מחדש את האתר. כשמשהו נעשה לא נכון, וזה קורה הרבה, התוצאה היא צניחה שלוקח חודשים לתקן, ולפעמים חלק ממנה לא חוזר.
מה שקורה בפועל הוא שהצניחה מגיעה בדיוק כשהעסק הכי פגיע. שילמתם על אתר חדש, אתם מצפים לקפיצה, ובמקום זה ההזמנות האורגניות יורדות ואתם מכסים את הפער בתקציב פרסום. זה אומר שהמעבר ממשיך לעלות לכם גם חודשים אחרי שהפרויקט הוכרז כגמור.
מי שמציע לכם מעבר בלי לדבר על הסיכון הזה מראש, ובלי תוכנית מסודרת להפניות, מוכר לכם רק את החלק הכיפי של הפרויקט.
לתכנן מיפוי כתובות ישנות לחדשות
מיפוי כתובות הוא לא משימה טכנית שעושים בסוף, הוא המסמך המרכזי של כל מעבר. הוא מתחיל מייצוא של כל הכתובות הקיימות באתר, לא רק דפי מוצר: קטגוריות, תתי קטגוריות, דפי תוכן, דפי מותג, וכל מה שנבנה לאורך השנים ונשכח.
מול הרשימה הזאת שמים את מבנה הכתובות במערכת החדשה, ולכל שורה קובעים יעד. שלוש מלכודות חוזרות בשלב הזה:
- דפים שנמחקו כי אף אחד לא זיהה שהם מדורגים
- מוצרים שאוחדו במערכת החדשה בלי להחליט לאן הכתובות הישנות מצביעות
- מבנה קטגוריות חדש שמייצר כתובות שונות לגמרי בלי מיפוי מלא
המסמך הזה צריך להיות מוכן ומאושר לפני שמתחילים לבנות, לא אחרי. מיפוי שנעשה בדיעבד הוא כבר ניסיון שיקום.
יש גם שיקול הפוך ששווה לשקול. לפעמים מבנה הכתובות הישן דווקא טוב, וכדאי לשמר אותו במערכת החדשה במקום להמציא מבנה חדש רק כי המערכת מציעה ברירת מחדל אחרת. ככל שפחות כתובות משתנות, כך פחות סיכון.
לבנות הפניות לכל דף שהיה מדורג
אחרי המיפוי מגיע הביצוע. כל כתובת ישנה צריכה הפניה קבועה ליעד המדויק שלה, לא לעמוד הבית. הפניה גורפת לעמוד הבית היא הדרך המהירה ביותר לאבד את כל מה שנבנה, כי מבחינת גוגל היא אומרת שהתוכן הישן פשוט לא קיים יותר.
סדר העדיפויות פשוט: קודם הדפים שמביאים תנועה בפועל לפי הסרץ קונסול, אחריהם הדפים עם קישורים חיצוניים, ואז השאר. אחרי העלייה בודקים שהכל עובד, סורקים את האתר לאיתור שרשראות הפניה, ועוקבים בסרץ קונסול אחרי שגיאות שצצות בשבועות הראשונים.
העבודה הזאת נמשכת חודשים אחרי ההשקה, והיא חלק מהותי מניהול האתר אחרי העלייה ולא משהו שנגמר ביום המעבר.
להעביר תוכן ולא רק נתונים
ההבדל בין נתונים לתוכן הוא ההבדל בין חנות שעובדת לחנות שמוכרת. נתונים זה שם, מחיר, מלאי ותמונה. תוכן זה תיאור קצר שגורם למישהו להבין תוך שתי שניות למה הוא צריך את המוצר, תיאור מפורט, תכונות ויתרונות, מה כולל, שאלות ותשובות, מפרט בטבלה ו-ALT ייחודי לכל תמונה.
ייצוא סטנדרטי מעביר את הנתונים ומשאיר את התוכן מאחור. במקום להיאבק בזה אחרי המעבר, שווה להתייחס לתוכן כפרויקט נפרד מלכתחילה. זאת אומרת, להחליט מראש אילו מוצרים מקבלים תוכן מלא ואילו נשארים בסיסיים בשלב ראשון.
מה שכן, זו בדיוק הנקודה שמחזקת את הטענה מההתחלה. אם ממילא צריך להשקיע בתוכן, אפשר לעשות את זה בחנות הקיימת ולראות את ההשפעה בלי לגעת בכתובות. תוכן A+Master מייצר שיפור המרות של 15-30%, וזה קורה בדיוק אותו דבר בין אם המערכת ישנה או חדשה.
לא לאבד מידע שקיים בחנות הנוכחית
זה תמיד מה שנעלם. לא המוצרים ולא התמונות, אלא שכבת המידע התפעולי שנצברה לאורך שנים ואף פעם לא תועדה במקום אחד. היא יושבת בהגדרות המערכת, בדפי תוכן ישנים, ולפעמים רק בראש של מי שמנהל את החנות.
זו הרשימה שצריכה להיאסף ידנית לפני כל מעבר:
- תעריפי הובלה לפי אזור, משקל וסכום הזמנה
- תנאי הרכבה והתקנה ומי מבצע אותם בפועל
- מדיניות אחריות מלאה לפי קטגוריה או מותג
- אזורי שירות ואזורים שלא מגיעים אליהם
- חוקי מועדון לקוחות והטבות קיימות
- קופונים פעילים וכללי הנחה מיוחדים
- הגדרות מס וחשבוניות
המידע הזה נאסף ידנית, נשמר במסמך אחד, ומוזן למערכת החדשה כמשימה בפני עצמה. חנות שעולה לאוויר עם תעריפי הובלה שגויים מייצרת נזק תוך יום.
להריץ בדיקת קבלה לפני העלייה לאוויר
בדיקת קבלה היא לא לשבת ולהסתכל אם הכל נראה טוב. היא רשימה כתובה שעוברים עליה סעיף סעיף, במחשב ובמובייל, ומסמנים.
אלה הסעיפים שאסור לוותר עליהם:
- רכישה מלאה מקצה לקצה בכל אמצעי תשלום שמוגדר
- חישוב משלוח נכון לכמה אזורים ולכמה סכומי הזמנה
- מיילים אוטומטיים יוצאים ומגיעים לתיבה ולא לספאם
- מוצר עם וריאציות נבחר ונרכש נכון עם המק"ט הנכון
- חיפוש פנימי מחזיר תוצאות רלוונטיות
- מדגם של הפניות ישנות מוביל ליעד הנכון
- גוגל טייטל ודיסקריפשיין קיימים וייחודיים בדפים המרכזיים
הבדיקה צריכה להיעשות בידיים של מישהו שלא בנה את האתר. מי שבנה מכיר את הדרך הנכונה ללחוץ, ולכן הוא לא ייתקל בדיוק במקומות שבהם גולש רגיל נתקע. עדיף לתת את הרשימה למישהו מהצוות שרואה את המערכת בפעם הראשונה.
אותו עיקרון תקף גם אחרי ההשקה, בכל פעם שנוגעים במשהו. בדיקת איכות לפני פרסום שינויים היא ההרגל שמונע את רוב התקלות שמגיעות אליי בטלפון.
לשקול שדרוג במקום העברה
זאת העמדה שלי, והיא מגיעה מעשר שנים של עבודה על חנויות קיימות. ברוב המקרים שראיתי אפשר לחדש את האתר הקיים ברמה שהלקוח מרגיש שקיבל אתר חדש לגמרי, בלי לגעת בכתובות ובלי טלטלה בגוגל.
מבחינה מקצועית זה עדיף בגלל סיבה אחת פשוטה: אתם משנים את מה שהגולש רואה ואת מה שמייצר המרה, ומשאירים במקום את מה שגוגל כבר מכיר ובוטח בו. אין תקופת התייצבות, אין הפניות ואין סיכון של אובדן מיקומים.
מה נכנס לשדרוג כזה בפועל:
- עיצוב מחדש של דף הבית ושל ההדר עם היררכיה ברורה
- דרופ עם תמונות צרובות ודפי מקשר בין קטגוריה למוצרים
- חיפוש פתוח ומרכזי ובמיוחד במובייל
- כפתורי קנייה בקוביית המוצר וסלקטור כמות אחרי הוספה לעגלה
- תוכן מלא לדפי מוצר ולדפי קטגוריה
- מפרט טכני בטבלה ושאלות ותשובות עם סכמה
- סדר תצוגה בקטגוריות כדי שמוצרים לא ייעלמו בתחתית המדף הדיגיטלי
המהלך הזה עונה על רוב מה שנמצא ברשימת הממצאים מתחילת המאמר, ועושה את זה בלי לשלם את מחיר הסיכון של מעבר.
יש לזה גם יתרון תפעולי שקל לפספס. בשדרוג אפשר לעבוד בשלבים ולראות תוצאה אחרי כל שלב: קודם מסדרים את המובייל, אחר כך את עץ הקטגוריות, אחר כך את דפי המוצר. בהקמה מחדש הכל מגיע במכה אחת ביום ההשקה, ואם משהו לא עובד קשה לדעת מה מתוך מאה השינויים אחראי לזה.
לקבוע קריטריון החלטה מראש
ההחלטה הכי גרועה היא זו שנופלת באמצע התהליך, אחרי שכבר הושקעו זמן ורגש. לכן כדאי לקבוע את הקריטריון לפני שמתחילים לבדוק, כשעוד קל להיות אובייקטיביים.
קריטריון פשוט שעובד: מעבר מוצדק רק אם לפחות אחד מארבעת המצבים הבאים מתקיים.
- יכולת עסקית מרכזית שהמערכת פיזית לא יודעת לעשות ואין לה מעקף סביר
- מבנה הקטלוג שלכם לא נכנס לשדות של המערכת בשום צורה
- ההיקף העסקי חצה את מה שהמערכת מחזיקה בנוחות
- ספק המערכת לא מתחזק אותה יותר או שאין תמיכה אמיתית
אם אף אחד מארבעת אלה לא מתקיים, הבעיה שלכם היא מבנה, תוכן וחווית קנייה. במקום להחליף מערכת מסדרים את זו שיש, ואת התקציב מפנים למקום שבאמת מזיז את המכירות.
וכשאחד מהם כן מתקיים, הקריטריון עדיין עוזר. הוא ממקד את הפרויקט בדבר שבאמת חסם אתכם, במקום להפוך אותו לרשימת משאלות שמתנפחת עד שאף אחד כבר לא זוכר למה התחילו.
שאלות שחוזרות לפני החלטה על פלטפורמה
איך יודעים אם הבעיה היא הפלטפורמה או האתר עצמו
רושמים כל דבר שלא עובד כממצא קונקרטי שאפשר להצביע עליו במסך, ואז בודקים מול הממשק אילו מהם המערכת בכלל יודעת לפתור. אם רוב הממצאים ניתנים לתיקון בהגדרות, בתוכן או בעיצוב, זו בעיית תפעול ולא בעיית פלטפורמה.
כמה זמן לוקח להתאושש בגוגל אחרי מעבר פלטפורמת איקומרס
גם כשהמיפוי וההפניות נעשים נכון יש תקופת התייצבות שבה גוגל סורק ומעריך מחדש את האתר, והמיקומים זזים. כשההפניות חלקיות או מצביעות לעמוד הבית ההתאוששות ארוכה בהרבה, ולפעמים חלק מהמיקומים לא חוזר.
האם אפשר לשפר מכירות בלי לעבור פלטפורמה
ברוב החנויות שעברתי עליהן התשובה היא כן, כי מה שחוסם את המכירות הוא מבנה קטגוריות, חווית קנייה במובייל ותוכן מוצר חסר, ולא המערכת עצמה. שדרוג של אלה מייצר שיפור בלי לגעת בכתובות ובלי סיכון קידומי.
מה הכי נעלם במעבר בין מערכות
לא המוצרים ולא התמונות אלא שכבת המידע התפעולי: תעריפי הובלה לפי אזור, תנאי הרכבה, מדיניות אחריות, אזורי שירות וחוקי מועדון לקוחות. המידע הזה לא יושב בקובץ ייצוא ולכן צריך לאסוף אותו ידנית לפני המעבר.
איך משווים בין פלטפורמות בלי ליפול לרשימת פיצרים
לוקחים את חמש הפעולות שהעסק מבצע הכי הרבה, בודקים כמה קליקים כל אחת דורשת בכל מערכת, ומשקללים לפי גודל הקטלוג ומורכבות הווריאציות. רשימת פיצרים נותנת משקל זהה ליכולת יומיומית וליכולת שלא תיגעו בה לעולם.
החלטת פלטפורמה מתחילה באבחון ולא בקטלוג יכולות
מעבר פלטפורמת איקומרס הוא כלי, לא מטרה. הוא נכון כשיש חסם אמיתי במערכת, והוא בזבוז כשהחסם הוא מבנה ותוכן שאף אחד לא נגע בהם שנים. ההבדל בין שני המצבים לא מתגלה בטבלת השוואה, הוא מתגלה כשיושבים מול החנות ורושמים ממצא אחרי ממצא.
מי שמתחיל מאבחון מגלה בדרך כלל שהמערכת הקיימת מחזיקה הרבה יותר ממה שחשב, ושהתקציב שיועד להקמה מחדש מייצר תוצאה גדולה בהרבה כשהוא הולך לחווית קנייה ולתוכן.
בסופו של דבר, שאלת הפלטפורמה כמעט תמיד מגיעה במקום שאלה אחרת: למה החנות לא ממירה. ברגע שעונים על השאלה הנכונה מגלים שברוב המקרים אין צורך להחליף מערכת אלא למצות אותה. וכשבאמת יש חסם, האבחון הופך את המעבר למהלך מתוכנן עם מיפוי, הפניות ובדיקות, במקום הימור.
אם אתם מתלבטים בין מעבר לשדרוג, נתחיל מאבחון של החנות הקיימת דרך שירות שדרוג אתר איקומרס.
