עלייה לאוויר מרגישה לעיתים כמו קו הסיום של פרויקט האתר. לאחר חודשים של אפיון, כתיבה, עיצוב, פיתוח והזנת תוכן, האתר פועל, העמודים נגישים ואפשר להתחיל להפנות אליו לקוחות. בפועל, העלייה לאוויר היא רק המעבר משלב ההקמה לשלב שבו האתר מתחיל להתמודד עם משתמשים אמיתיים, מידע משתנה, קמפיינים, עדכוני מערכת ויעדים עסקיים חדשים.
גם אתר שנבנה היטב לא ימשיך לשרת את העסק ללא ניהול. עמודים מתיישנים, טפסים עלולים להפסיק לפעול, שירותים משתנים, קישורים נשברים ונקודות חיכוך מתגלות רק לאחר שמצטברים נתונים. אתר שאינו מטופל יכול להיראות תקין מבחוץ, אך בהדרגה להפוך לפחות מדויק, פחות אמין ופחות אפקטיבי.
הניהול שאחרי ההשקה אינו מורכב רק מתחזוקה טכנית. הוא כולל בדיקת ביצועים, עדכון תוכן, שיפור מסלולי משתמש, טיפול במשימות, תכנון פעילויות והבנת הדרך שבה האתר תורם לעסק. תהליך מקצועי של ניהול אתר אינטרנט הופך את האתר מפרויקט שהסתיים לנכס שממשיך להתפתח.
להגדיר מי אחראי על האתר מרגע ההשקה
אחת הבעיות הנפוצות לאחר עליית אתר חדש היא שלא ברור מי מנהל אותו. חברת הפיתוח סיימה את הפרויקט, אנשי השיווק מתחילים להפנות אליו תנועה, צוות המכירות מזהה פערים ושירות הלקוחות מקבל שאלות, אך אין אדם אחד שמרכז את התמונה.
ללא בעל אחריות ברור, בקשות מתחילות לעבור בין גורמים. שינוי תוכן נשלח לכותב, תקלה למפתח, בקשת עיצוב למעצבת ודוח ביצועים לאיש השיווק. כל אחד מטפל בחלקו, אך איש אינו בודק כיצד הפעולות מתחברות זו לזו ואם המשימה הושלמה באתר הפעיל.
מנהל האתר אינו חייב לבצע בעצמו כל פעולה. תפקידו לוודא שהאתר מתוחזק, שהמשימות מתועדות, שהספקים מקבלים בריפים ברורים ושהשינויים נבדקים לאחר הפרסום. הוא צריך להבין את היעדים העסקיים ואת המבנה הדיגיטלי גם כאשר העבודה הטכנית מבוצעת על ידי גורמים אחרים.
כדאי להגדיר כבר בשלב ההשקה:
- מי רשאי לעדכן תוכן.
- מי מאשר שינויים בעמודים מרכזיים.
- מי מטפל בתקלות.
- מי עוקב אחר הנתונים.
- מי אחראי על אבטחה, גיבויים ועדכונים.
- מי מנהל את הקשר עם ספקי הפיתוח, העיצוב והתוכן.
ככל שהאחריות ברורה יותר, כך קטן הסיכון שמשימה חשובה תישאר בין כמה גורמים בלי שאיש יקדם אותה.
להתייחס לחודש הראשון כתקופת בקרה
הימים הראשונים לאחר ההשקה חשובים במיוחד. גם לאחר בדיקות מקיפות בסביבת הפיתוח, שימוש אמיתי באתר יכול לחשוף תרחישים שלא נבדקו, מכשירים שלא נלקחו בחשבון ופערים בין התכנון לבין התנהגות המשתמשים.
במהלך החודש הראשון כדאי לעקוב בתדירות גבוהה אחר המסלולים המרכזיים. באתר לידים יש לבדוק טפסים, מספרי טלפון, קישורי וואטסאפ, הודעות אישור והעברת הפניות למערכת ניהול הלקוחות. באתר מכירות יש לבדוק מוצרים, וריאציות, מלאי, סל, משלוחים, קופונים וסליקה.
חשוב לבצע את הבדיקות כמו משתמש ולא רק מתוך מערכת הניהול. יש להיכנס לאתר ממכשירים שונים, להגיע דרך תוצאות חיפוש וקמפיינים, למלא טפסים ולבצע הזמנות ניסיון. כך ניתן לבדוק לא רק אם הרכיב קיים, אלא אם התהליך כולו ברור ופועל.
כדאי גם להקשיב לצוותים שפוגשים את הלקוחות. אם אנשי המכירות מקבלים שאלות חוזרות על מידע שאמור להופיע באתר, ייתכן שהוא אינו ברור או אינו נמצא במקום הנכון. אם שירות הלקוחות מקבל דיווחים על תקלה במובייל, יש לבדוק אם מדובר במקרה בודד או בדפוס.
תקופת הבקרה אינה צריכה להפוך לרצף של שינויים יומיים המבוססים על כל תגובה. מטרתה היא לאסוף מידע, לזהות בעיות משמעותיות ולתקן במהירות את החסמים הברורים.
לוודא שהמדידה עובדת
אתר יכול לעלות לאוויר כשהוא נראה מצוין, אך בלי מדידה תקינה יהיה קשה להבין מה המשתמשים עושים ומה צריך לשפר.
כבר בימים הראשונים צריך לוודא שמערכות האנליטיקה מתעדות כניסות, מקורות תנועה, עמודי נחיתה והפעולות המרכזיות. באתר לידים יש למדוד שליחת טפסים, לחיצות על טלפון, וואטסאפ וקביעת פגישה. באתר איקומרס יש לבדוק צפייה במוצר, הוספה לסל, התחלת תשלום ורכישה.
חשוב להשוות בין הנתונים הדיגיטליים לבין הפעילות בפועל. אם האתר מציג עשר המרות אך העסק קיבל רק שש פניות, ייתכן שהאירוע מופעל גם כאשר הטופס אינו נשלח. אם התקבלו הזמנות אך הן אינן מופיעות בדוחות, ייתכן שחיבור הרכישה אינו תקין.
כדאי גם לתעד את נקודת ההתחלה. כמה תנועה מגיעה, מהו יחס ההמרה, אילו עמודים מקבלים חשיפה ומהם מקורות הפניות? נתוני הבסיס מאפשרים למדוד בעתיד את ההשפעה של שינויים ולזהות חריגות.
המדריך איך לקבל החלטות באתר לפי נתונים? מסביר כיצד להתחיל משאלה עסקית, לחבר בין מקורות מידע ולהימנע מהסקת מסקנות על בסיס נתון בודד.
לבנות שגרת בדיקות שבועית
ניהול אתר אינו מחייב לעבור מדי יום על כל עמוד, אך יש פעולות שחשוב לבצע בקביעות. בדיקה שבועית קצרה יכולה לזהות תקלה לפני שהיא פוגעת במשך זמן רב בפניות, במכירות או באמון.
בכל שבוע כדאי לעבור על העמודים המרכזיים, לשלוח טופס, לבדוק את דרכי יצירת הקשר ולוודא שהאתר פועל היטב במובייל. באתר מכירות יש לבצע מדי פעם הזמנת ניסיון ולבדוק סליקה, קופונים ומשלוחים.
יש לעבור גם על שינויים שהתבצעו במהלך השבוע. אם פורסם עמוד חדש, צריך לוודא שהוא נגיש, מקושר ומוצג נכון. אם הוחלף באנר, יש לבדוק את הקישור ואת תצוגת המובייל. אם נוסף מוצר, צריך לבדוק מחיר, מלאי, וריאציות ותמונות.
הבדיקה אינה צריכה להסתמך על זיכרון. אפשר להשתמש ברשימה קבועה ולהוסיף סעיפים בהתאם למערכות ולפעילויות של האתר. המדריך מה צריך לבדוק באתר אינטרנט פעם בשבוע? מציג שגרה מעשית שמחברת בין תקינות, תוכן, מובייל ומדידה.
המטרה אינה להבטיח שלעולם לא תהיה תקלה, אלא לקצר את הזמן שבו היא נשארת פעילה.
לתכנן גם בדיקה חודשית רחבה
הבדיקה השבועית מתמקדת בעיקר בתפקוד השוטף. אחת לחודש צריך להתרחק מעט מהמשימות היומיות ולבחון את התמונה הרחבה.
בבדיקה החודשית כדאי לבחון את התוצאות העסקיות, מקורות התנועה, עמודי הנחיתה, התוכן, הביצועים במובייל ובעיות שחזרו במהלך התקופה. זהו הזמן לזהות מגמות ולא רק תקלות.
אפשר לשאול:
- האם מספר הפניות או המכירות השתנה?
- אילו עמודים התחזקו?
- אילו עמודים חשובים נחלשו?
- האם השירותים והמסרים עדיין מעודכנים?
- אילו שאלות חזרו אצל לקוחות?
- אילו משימות הושלמו ומה הייתה התוצאה שלהן?
- אילו אזורים דורשים טיפול בחודש הבא?
המאמר צ’ק ליסט חודשי לניהול אתר עסקי מספק מסגרת מלאה לבדיקה כזו. תוצר הבדיקה צריך להיות תכנית עבודה קצרה ומדורגת, ולא רק דוח שנשמר בתיקייה.
לעדכן את התוכן בהתאם לעסק
העסק אינו נשאר זהה לאחר העלאת האתר. שירותים משתנים, הצוות מתרחב, תהליכים מתעדכנים ומוצרים נכנסים ויוצאים. אם האתר אינו משתנה יחד עם העסק, נוצר פער בין מה שהלקוח קורא לבין מה שהוא מקבל בפועל.
כדאי לבדוק באופן קבוע את עמוד הבית, עמודי השירות, האודות, פרטי הצוות, המחירים, המדיניות, זמני האספקה ופרטי ההתקשרות. מידע ישן עלול לייצר פניות לא מתאימות או לגרום ללקוח לפקפק באמינות האתר.
עדכון תוכן אינו מחייב שכתוב מלא. לעיתים צריך לשנות פתיח, להוסיף תשובה לשאלה שחוזרת, להסיר שירות שכבר אינו מוצע או לעדכן את שלבי העבודה. במקרים אחרים, נתוני החיפוש מראים שהעמוד מקבל חשיפות על שאלות שאינן מקבלות בו מענה מספק.
כדאי גם להבחין בין תוכן שוטף לבין תוכן אסטרטגי. פרסום חדשות ועדכונים יכול להראות שהאתר פעיל, אך אינו מחליף עבודה על עמודי השירות, הקטגוריות והתכנים שמחזקים את תחומי הליבה.
המדריך איך לשפר עמוד קיים באתר בלי לכתוב אותו מחדש? מפרט כיצד לשמור על החלקים שעובדים ולשפר באופן ממוקד את המבנה, התשובות והקריאות לפעולה.
לא לפרסם תוכן בלי תכנית הטמעה
כתיבת מאמר או עמוד חדש היא רק חלק מהעבודה. כדי שהתוכן ימלא תפקיד באתר, צריך לשלב אותו במבנה הקיים.
לפני הפרסום כדאי להחליט לאיזה אשכול הוא שייך, מאילו עמודים יקשרו אליו ולאן הוא יוביל את המשתמש. עמוד חדש שאינו מופיע בתפריט, בקטגוריה, במאמרים קיימים או בעמוד מרכזי יכול להפוך לעמוד יתום שאיש כמעט אינו מגיע אליו.
יש לבדוק גם את רכיבי ה-SEO הבסיסיים: כותרת, מטא דסקריפשן, כתובת, כותרת ראשית, תמונות וקישורים פנימיים. לאחר הפרסום צריך לפתוח את העמוד במובייל, לבדוק את הקישורים ולוודא שהוא מופיע במפת האתר ובמקומות המתאימים.
המדריך איך לנהל קישורים פנימיים באתר בצורה נכונה? מסביר כיצד לחבר בין עמודי ליבה, מדריכים ותכנים תומכים כך שהאתר יתפתח כמערכת ולא כאוסף עמודים מבודדים.
לעקוב אחר התנהגות המשתמשים
האתר שאופיין לפני ההשקה מבוסס על השערות מקצועיות. רק לאחר העלייה לאוויר ניתן לראות כיצד משתמשים אמיתיים מתנהגים.
הם עשויים להגיע לעמודים שלא נחשבו מרכזיים, להתעלם מאזורים שקיבלו מקום בולט או לנסות ללחוץ על אלמנטים שלא תוכננו ככפתורים. חלקם יתקשו להבין את התפריט, אחרים יחפשו מידע שאינו מוצג במיקום הצפוי.
אפשר ללמוד על ההתנהגות באמצעות נתוני גלישה, הקלטות משתמשים, מפות חום, חיפוש פנימי ופניות לשירות. אין צורך להגיב לכל תנועה חריגה. כדאי לחפש דפוסים שחוזרים אצל מספר משתמשים ומתחברים לנתונים נוספים.
לדוגמה, אם משתמשים רבים מגיעים לעמוד שירות אך כמעט אינם ממשיכים לטופס, צריך לבדוק אם הקריאה לפעולה ברורה, אם המידע מספק ואם קיימים חששות שלא מקבלים מענה. אם משתמשים עוברים בין כמה עמודי מוצר וחוזרים לקטגוריה, ייתכן שקשה להם להבין את ההבדלים.
המידע צריך להפוך להשערה ולמשימה ממוקדת, לא להוביל לעיצוב מחדש של האתר בכל חודש.
לנהל משימות במקום לפעול מתוך הודעות
לאחר ההשקה מתחילות להגיע בקשות מכל כיוון: שינוי טקסט, הוספת עמוד, תיקון תמונה, פיתוח חדש, המלצה של ספק ורעיון שעלה בישיבה. כאשר הבקשות נשארות במיילים ובהודעות, קשה לדעת מה הושלם ומה עדיין פתוח.
כדאי לרכז את כל המשימות במערכת אחת. לכל משימה יש להגדיר מה נדרש, באיזה עמוד, מי אחראי, מהי העדיפות ומתי היא נחשבת גמורה.
חשוב להפריד בין תקלות, שיפורים ורעיונות. תקלה בטופס דורשת טיפול שונה מרעיון להוסיף מחשבון. שיפור עמוד מרכזי צריך לקבל עדיפות לפי הנתונים והחשיבות העסקית, ולא לפי האדם שביקש אותו.
המאמר איך מנהלים משימות באתר בלי ללכת לאיבוד? מציג תהליך לריכוז בקשות, חלוקת אחריות, שימוש בסטטוסים ובדיקת כל שינוי לפני סגירתו.
לתעדף במקום לנסות לבצע הכול
העובדה שמשימה נכנסה למערכת אינה אומרת שהיא צריכה להתבצע מיד. כמעט תמיד יהיו יותר רעיונות וצרכים מזמן ותקציב זמינים.
כדאי לתעדף לפי השפעה עסקית, דחיפות, רמת ודאות, מאמץ וסיכון. תקלה שמשפיעה על כל הפניות או הרכישות תקבל קדימות גבוהה. שינוי עיצובי בעמוד שכמעט אינו נצפה יכול להמתין, גם אם הוא פשוט לביצוע.
יש להיזהר מהתמקדות במשימות הקלות בלבד. סגירת תיקונים קטנים יוצרת תחושת התקדמות, אך אם פרויקטים משמעותיים נדחים שוב ושוב, האתר אינו מתקדם בנושאים החשובים.
מנגד, לא נכון להפוך כל שינוי לפרויקט גדול. לעיתים תיקון תוכן, שינוי מיקום של כפתור או הוספת מידע חסר יכולים להשפיע יותר מפיתוח מורכב.
תיעדוף טוב יוצר שילוב בין תחזוקה, שיפורים מהירים ועבודה אסטרטגית ארוכת טווח.
לבצע QA לאחר כל שינוי משמעותי
משימה אינה מסתיימת כאשר הכותב מסר טקסט, המעצב הכין קובץ או המפתח העלה שינוי. צריך לבדוק את התוצאה באתר הפעיל.
בבדיקת QA יש לחזור לבריף ולוודא שכל הדרישות בוצעו. לאחר מכן צריך לבחון את השינוי בהקשר הרחב: האם הוא נראה טוב במחשב ובטלפון? האם הקישורים עובדים? האם הטופס נשלח? האם השינוי השפיע על עמודים נוספים?
באתר איקומרס יש לבדוק גם מחיר, מלאי, וריאציות, סל ותשלום. שינוי קטן בעמוד מוצר יכול להשפיע על תהליך הרכישה או על החיבור למערכת המלאי.
חשוב שהבדיקה תתבצע גם על ידי גורם שלא ביצע את העבודה כאשר הדבר אפשרי. מי שפיתח או כתב את השינוי מכיר את הכוונה ועלול לפספס פער שמשתמש חדש יזהה מיד.
רק לאחר שהשינוי פורסם, נבדק ונמצא תקין אפשר לסגור את המשימה.
לתחזק את המערכת הטכנית
ניהול אתר כולל גם את התשתית שעליה הוא פועל. מערכות ניהול תוכן, תוספים, ספריות, שירותי אחסון וחיבורים חיצוניים ממשיכים להתעדכן לאחר ההשקה.
עדכונים חשובים לאבטחה, ליציבות ולהתאמה למערכות חדשות, אך לא נכון להתקין כל עדכון באופן אוטומטי באתר הפעיל בלי בדיקה. שינוי בתוסף או בתבנית יכול להשפיע על טפסים, עיצוב, סליקה או רכיבים אחרים.
לפני עדכון משמעותי צריך לוודא שקיים גיבוי תקין, להבין מה משתנה ולהגדיר אילו מסלולים ייבדקו לאחר מכן. באתר מורכב רצוי להשתמש בסביבת בדיקות לפני הפרסום.
כדאי לעקוב גם אחר ביצועי האחסון, תעודת האבטחה, תוקף הדומיין, שגיאות שרת ונפח האחסון. חלק מהבעיות האלה אינן נראות בשימוש היומיומי עד שהן הופכות להשבתה.
ניהול התחזוקה צריך להיות מתועד. יש לדעת מי ביצע עדכון, מתי, מה נבדק ומה הייתה התוצאה. כך קל יותר לזהות את מקור הבעיה אם תקלה מופיעה לאחר שינוי.
לבדוק גיבויים ולא רק להפעיל אותם
עסקים רבים מניחים שקיים גיבוי מפני שהאחסון או התוסף מציגים הודעה שהפעולה הצליחה. גיבוי שימושי רק אם הוא כולל את המידע הנדרש וניתן לשחזר אותו בזמן סביר.
כדאי לוודא שהגיבוי כולל את קבצי האתר, בסיס הנתונים ותכנים שהועלו. יש לבדוק היכן הוא נשמר, כמה גרסאות נשמרות ומי יכול לגשת אליו.
רצוי לשמור עותק במקום נפרד מהשרת הראשי. אם התקלה פוגעת גם באחסון, גיבוי שנמצא באותה סביבה עלול לא להיות זמין.
מדי פעם צריך לבצע בדיקת שחזור בסביבה בטוחה. אין צורך להחזיר את האתר הפעיל לגרסה ישנה, אך חשוב לדעת שהקבצים תקינים ושהתהליך מוכר לצוות.
גם תדירות הגיבוי צריכה להתאים לאופי האתר. אתר תדמית שמתעדכן פעם בחודש אינו דומה לחנות שבה מתקבלות הזמנות בכל שעה.
לנהל הרשאות ואבטחה
לאחר השקת האתר מצטברים משתמשים במערכת: עובדים, ספקים, מפתחים, אנשי תוכן וחברות שיווק. לעיתים ההרשאות נשארות פעילות גם לאחר שהעבודה הסתיימה.
כדאי לבדוק אחת לתקופה מי מחזיק בגישה ולהסיר חשבונות שאינם נדרשים. כל משתמש צריך לקבל את רמת ההרשאה המינימלית הדרושה לתפקידו. כותב תוכן אינו צריך בהכרח גישה להגדרות מערכת, וספק חיצוני אינו צריך להישאר מנהל לאחר סיום הפרויקט.
מומלץ להשתמש בחשבונות אישיים ולא בחשבון משותף לכל הצוות. כך ניתן לדעת מי ביצע שינוי ולבטל גישה של אדם מסוים בלי להחליף סיסמה לכולם.
אימות דו־שלבי, סיסמאות חזקות ועדכון מערכות הם חלק מההגנה הבסיסית. כדאי גם לוודא שטפסים ואזורי מידע אישי מטופלים בהתאם למדיניות הפרטיות של העסק.
אבטחה אינה אירוע חד־פעמי שמסתיים לפני ההשקה. היא תהליך מתמשך שמשתנה יחד עם המשתמשים, המערכות והסיכונים.
לשמור על ביצועי האתר
עם הזמן מתווספים לאתר תמונות, סרטונים, כלי מדידה, פופאפים, מערכות צ’אט ותוספים שיווקיים. כל רכיב בפני עצמו יכול להיראות קטן, אך יחד הם עלולים להאט את האתר ולפגוע בחוויית המשתמש.
כדאי לבדוק באופן תקופתי את מהירות העמודים המרכזיים, במיוחד במובייל. יש לשים לב לזמן שבו התוכן המרכזי מופיע, לקפיצות של רכיבים ולכפתורים שמגיבים באיחור.
תמונות הן מקור נפוץ להכבדה. לפני העלאה צריך להתאים את הגודל, לדחוס את הקובץ ולבחור פורמט מתאים. אין צורך להעלות תמונה ברזולוציה עצומה כדי להציג אותה בכרטיס קטן.
גם כלים חיצוניים צריכים להיבחן. אם מערכת מסוימת כמעט אינה בשימוש אך מוסיפה קוד כבד לכל עמוד, ייתכן שכדאי להסיר אותה או להפעיל אותה רק באזורים הנדרשים.
המטרה אינה לרדוף אחרי ציון מושלם בכל כלי בדיקה, אלא לוודא שהאתר נטען במהירות סבירה ופועל בצורה יציבה בתנאים שבהם משתמש הקהל האמיתי.
להמשיך לנהל את ה-SEO לאחר ההשקה
עבודת SEO אינה מסתיימת כאשר מגדירים כותרות ומעלים מפת אתר. לאחר העלייה לאוויר צריך לוודא שמנועי החיפוש מצליחים לסרוק ולאנדקס את העמודים הנכונים.
כדאי לבדוק אם עמודים מרכזיים מופיעים באינדקס, אם קיימות שגיאות סריקה ואם הכתובות הקנוניות וההפניות פועלות. אם האתר החליף אתר קודם, צריך לעקוב אחר ההפניות ולוודא שכתובות חשובות אינן נופלות לעמודי 404.
יש לעקוב גם אחר ביצועי החיפוש: קליקים, חשיפות, שאילתות ועמודים. ירידה זמנית יכולה להתרחש לאחר מעבר, אך ירידה ממושכת בעמודים מרכזיים דורשת בדיקה.
ככל שהאתר גדל, צריך לשמור על מבנה קישורים ברור, למנוע כפילויות ולוודא שתוכן חדש משתלב בנושאים המרכזיים. אתר שממשיך לפרסם בלי לנהל את המבנה עלול לצבור עמודים חופפים, חלשים או מנותקים.
לנהל אתר איקומרס כמערכת תפעולית
באתר מכירות, הניהול לאחר ההשקה מורכב במיוחד משום שהאתר מחובר למלאי, סליקה, משלוחים, חשבוניות ומערכות נוספות. תקלה באחד החיבורים יכולה לפגוע בהזמנות גם כאשר העמודים עצמם נראים תקינים.
צריך לעקוב אחר מוצרים שחסרים במלאי, מחירים, וריאציות, קופונים, שיטות משלוח ותהליך התשלום. יש לבצע התאמות בין מספר ההזמנות באתר לבין מערכת הסליקה והמערכות התפעוליות.
כדאי לעבור על דוחות מוצרים וקטגוריות כדי להבין מה מקבל חשיפה, מה נוסף לסל ומה באמת נרכש. מוצר בעל הרבה צפיות ומעט הוספות לסל דורש בדיקה שונה ממוצר שנוסף לסל אך ננטש בתשלום.
המאמר תקלות נפוצות באתרי איקומרס ואיך מזהים אותן בזמן מציג את נקודות הכשל המרכזיות, מסליקה ומלאי ועד מיילים אוטומטיים ומדידה.
באתר מכירות חשוב גם לבנות תכנית חודשית שמחברת בין קטלוג, מסחור, מבצעים, תוכן ו-CRO. ללא תכנון כזה, רוב הזמן מוקדש להעלאות דחופות ולתקלות, והשיפור האסטרטגי נדחה.
לא לשנות את האתר רק משום שאפשר
לאחר שהאתר עולה, כל הערה יכולה להפוך לבקשת שינוי. מנהל אחד מעדיף צבע אחר, איש מכירות רוצה להוסיף מידע, ומישהו ראה רכיב מעניין באתר מתחרה. אם כל רעיון מיושם מיד, האתר מאבד עקביות והתוצאה קשה למדידה.
לפני שמבצעים שינוי כדאי להגדיר את הבעיה. מה אינו עובד? מי מושפע? אילו נתונים או משובים תומכים בכך? מה צפוי להשתפר לאחר השינוי?
כאשר אין בעיה ברורה, אפשר לשמור את הרעיון במאגר ולבחון אותו בהמשך. ייתכן שהוא יהפוך לרלוונטי כאשר יצטברו נתונים או כאשר יתחבר ליעד עסקי.
גם שינוי מוצלח באתר אחר אינו בהכרח מתאים לקהל, למוצרים ולמבנה שלכם. יש לבחון אותו בתוך ההקשר המקומי ולא להעתיק פתרון רק משום שהוא נראה מתקדם.
לא לחכות לירידה גדולה כדי לשפר
הצד השני של שינוי יתר הוא הזנחה. יש אתרים שאינם מקבלים תשומת לב כל עוד אין תקלה חמורה. רק כאשר הפניות יורדות או שהמכירות נפגעות מתחילים לבדוק מה קרה.
ניהול נכון הוא הדרגתי. בכל חודש ניתן לבחור מספר עמודים, מסלולים או תהליכים ולשפר אותם. כך האתר צובר שינויים מדודים במקום לעבור פרויקט גדול אחת לכמה שנים.
אפשר לזהות הזדמנויות לפני שהן הופכות לבעיה: עמוד שמקבל יותר חשיפות אך שיעור ההקלקה שלו נמוך, קטגוריה בצמיחה, שאלות חדשות של לקוחות או פער בביצועי המובייל.
שיפור מתמשך בדרך כלל פחות מסוכן משינוי רחב שמתבצע לאחר תקופה ארוכה של הזנחה. הוא מאפשר למדוד, ללמוד ולשמור על חלקי האתר שכבר עובדים.
לקבוע תקציב קבוע לניהול ולשיפור
עסקים רבים מקצים תקציב לבניית האתר אך אינם מתכננים עלויות לאחר ההשקה. בפועל, אתר פעיל דורש זמן עבודה, תחזוקה, תוכן, פיתוח ולעיתים שירותים חיצוניים.
כדאי לקבוע תקציב חודשי או רבעוני שמכסה את התחומים המרכזיים:
- תחזוקה ועדכונים.
- בדיקות ותיקוני תקלות.
- תוכן ועדכון עמודים.
- שיפור חוויית משתמש והמרות.
- מדידה ואנליטיקה.
- פיתוחים קטנים.
- גיבויים, אבטחה ושירותים חיצוניים.
התקציב אינו חייב להיות זהה בכל חודש. אפשר לשמור בסיס קבוע ולתכנן השקעות נוספות לפני עונות מכירה, השקות או פרויקטים משמעותיים.
חשוב גם להבחין בין תחזוקה לבין פיתוח. חבילת תחזוקה שמכסה עדכוני מערכת אינה בהכרח כוללת כתיבת עמודים, שיפור משפך או בניית רכיבים חדשים. הגדרה ברורה מונעת ציפיות לא מתואמות מול הספקים.
לתעד שינויים והחלטות
ככל שהאתר פעיל יותר זמן, קשה לזכור מדוע בוצע כל שינוי. כותרת הוחלפה, עמוד הועבר, טופס קוצר או קופון הוגדר בצורה מסוימת, אך חודשים לאחר מכן איש אינו זוכר מה הייתה הסיבה.
כדאי לשמור תיעוד בסיסי של שינויים משמעותיים:
- מה הייתה הבעיה.
- מה הוחלט לשנות.
- מי אישר.
- מתי השינוי פורסם.
- אילו עמודים ומערכות הושפעו.
- מה היה מדד ההצלחה.
- מה הייתה התוצאה.
התיעוד מסייע כאשר מופיעה ירידה או תקלה. במקום לנחש, ניתן לבדוק אילו פעולות בוצעו בסמוך לשינוי בנתונים.
הוא גם מונע חזרה על ניסויים שכבר נוסו ומאפשר לעובדים וספקים חדשים להבין את ההיסטוריה של האתר.
למדוד שינויים לאחר הפרסום
שינוי באתר אינו הצלחה רק משום שהוא פורסם בזמן ונראה טוב. צריך לבדוק אם הוא פתר את הבעיה שבגללה בוצע.
לפני השינוי כדאי לתעד את הנתונים הרלוונטיים. לאחר תקופה מתאימה חוזרים אליהם ובוחנים מה השתנה. בעמוד שירות ניתן לבדוק פניות, בעמוד מוצר הוספות לסל ורכישות, ובקטגוריה מעבר למוצרים ושימוש בפילטרים.
חשוב להגן גם על מדדים אחרים. קיצור טופס יכול להגדיל את מספר הפניות אך להוריד את איכותן. מבצע יכול להגדיל הכנסות אך לפגוע ברווחיות. תיאור מוצר משכנע יותר יכול להגדיל רכישות אך גם החזרות אם הוא יוצר ציפייה לא מדויקת.
לא כל שינוי יצליח. תוצאה חלשה אינה בהכרח כישלון אם היא מספקת מידע שמאפשר לבחור כיוון טוב יותר בהמשך.
לבנות תכנית רבעונית ולא רק להגיב לחודש הנוכחי
לצד השגרה השבועית והחודשית, כדאי לתכנן אחת לרבעון את הכיוונים הגדולים יותר. זהו טווח זמן שמאפשר לעבוד על פרויקטים שלא ניתן להשלים בתוך שבוע, אך עדיין נשאר מחובר לצרכים הנוכחיים של העסק.
בתכנון הרבעוני אפשר לבחור נושאים כמו:
- שיפור תחום שירות שלם.
- בניית אשכול תוכן.
- חיזוק קטגוריה מרכזית.
- שיפור תהליך הרכישה.
- עדכון עמודי מוצר מובילים.
- שדרוג תשתית המדידה.
- טיפול בביצועים ובנגישות.
- בניית אינטגרציה חדשה.
היעדים הרבעוניים צריכים להתפרק למשימות חודשיות. כך הם אינם נשארים כרעיונות גדולים שנדחים מפני שהעבודה השוטפת תמיד דחופה יותר.
מתי נדרש שדרוג רחב יותר?
ניהול שוטף יכול לשפר אתר לאורך זמן, אך קיימים מצבים שבהם עדכונים נקודתיים כבר אינם מספיקים.
אם המערכת אינה מאפשרת לבצע פעולות בסיסיות, האתר סובל מתקלות חוזרות, התשתית אינה נתמכת או שהמבנה אינו מתאים עוד לעסק, ייתכן שנדרש שדרוג משמעותי. גם חוויית משתמש מיושנת מאוד, ביצועים חלשים או קושי להתחבר למערכות עסקיות יכולים להצדיק פרויקט רחב.
עם זאת, לא כל אתר ותיק צריך להיבנות מחדש. לעיתים הבעיה נובעת מתוכן לא מעודכן, סדר עדיפויות חלש או חוסר בניהול, ולא מהמערכת עצמה. לפני שמחליטים על בנייה חדשה, כדאי לבדוק מה אפשר לשפר בתשתית הקיימת ומהו החסם האמיתי.
פרויקט חדש ללא תהליך ניהול לאחר ההשקה עלול להגיע לאותו מצב בתוך כמה שנים. לכן גם כאשר מחליפים את האתר, צריך לבנות מראש את שגרת העבודה שתתחיל ביום שבו הוא יעלה.
אתר מצליח אינו אתר שסיימו לבנות
עליית האתר לאוויר היא רגע חשוב, אך היא אינה מבטיחה תוצאות לאורך זמן. האתר מתחיל לפעול בתוך סביבה שמשתנה כל הזמן: לקוחות שואלים שאלות חדשות, שירותים מתפתחים, מערכות מתעדכנות והמתחרים ממשיכים לשפר את הנוכחות שלהם.
ניהול נכון מחבר בין ארבע שכבות: תקינות, תוכן, ביצועים והתפתחות. האתר צריך לעבוד ללא תקלות, להציג מידע מדויק, למדוד את הפעולות החשובות ולהשתפר בהתאם לנתונים ולצורכי העסק.
אין צורך לבצע בכל חודש שינוי גדול. דווקא שגרה של בדיקות, עדכונים ושיפורים ממוקדים מאפשרת לשמור על האתר יעיל לאורך זמן. כל פעולה מתועדת, מקבלת עדיפות, נבדקת לאחר הפרסום ומזינה את תכנית העבודה הבאה.
כאשר האתר מנוהל בצורה כזו, הוא אינו נשאר צילום של העסק ביום שבו הושק. הוא ממשיך להשתנות יחד איתו, לתמוך בלקוחות ולייצר ערך גם הרבה אחרי שהפרויקט הראשוני הסתיים.
