למה "פשוט מייצאים ומייבאים" נכשל
ייצוא CSV מה-CRM הישן וייבוא שלו ל-GoHighLevel נשמע כמו המשימה הטכנית הקלה בכל התהליך. בפועל, שני דברים נשברים כאן באופן שקט ולא מודיע על עצמו. ראשית, כל שדה מותאם אישית (custom field) שאין לו שדה תואם שנוצר מראש ב-GoHighLevel - נופל בייבוא בלי הודעת שגיאה, פשוט נעלם. שנית, ואולי החשוב מכל: אוטומציות (Workflows) לא עוברות בייבוא בשום אופן - הן לוגיקה שקיימת רק במערכת המקור, וחייבים לבנות אותן מחדש אחת-אחת במערכת היעד. עסק שמתכנן "להעביר קובץ ולהמשיך לעבוד" בדרך כלל מגלה את שתי הבעיות האלה בשבוע הראשון אחרי המעבר, כשלידים חדשים לא מקבלים שום מענה אוטומטי.
לפני שמעתיקים משהו - מבצעים ביקורת על הנתונים
מסד נתונים של אנשי קשר לא נשאר מדויק עם הזמן. לפי כלי הסימולציה של HubSpot למדידת "ריקבון" מסדי נתונים, מסד דיוור ממוצע מתיישן בקצב של כ-22.5% בשנה - אנשים מחליפים מקום עבודה, מספרי טלפון וכתובות מייל, ונרשמים לרשימת "הסר רישום" (מקור: hubspot.com). המשמעות המעשית: ייבוא גורף של "כל מה שהיה אי פעם" במערכת הישנה לא מעביר רק לידים רלוונטיים - הוא מעביר גם רבע מהרשימה שכבר לא מדויק, ואז אתם מגלים את זה רק כשהודעת SMS חוזרת כ"מספר לא קיים" או מייל חוזר כ-bounce.
- קובעים חתך פעילות - למשל רק אנשי קשר עם אינטראקציה (שיחה, פתיחת מייל, ליד חדש) ב-12-24 החודשים האחרונים.
- מסמנים אנשי קשר ללא טלפון או מייל תקין לבדיקה נפרדת, לא לייבוא אוטומטי.
- לא מעתיקים תגים (tags) וסטטוסים ישנים "כמו שהם" - בודקים אם הם עדיין רלוונטיים למבנה הפייפליין החדש.
מה חובה למפות לפני הייבוא הראשון
כל שדה מותאם אישית במערכת הישנה צריך שדה תואם ב-GoHighLevel, עם סוג נתון תואם (טקסט, תאריך, בחירה יחידה), לפני שמעלים קובץ CSV אחד. שמות השלבים בפייפליין (pipeline stages) כדאי ליצור מראש בהתאם לשלבים במערכת המקור, כך שעסקאות פתוחות ממופות ישר לשלב הנכון ולא נופלות כולן ל"שלב ראשון" כברירת מחדל. שדות מסוג "בחירה מרובה" (multi-select) בדרך כלל עוברים טוב יותר כתגים נפרדים מאשר כשדה מותאם יחיד.
הרצת חפיפה - לא מעבר חד-פעמי
המעבר הבטוח ביותר הוא לא "סוגרים היום, פותחים מחר" - הוא חפיפה מתוכננת. מריצים את שתי המערכות זמן מה במקביל: לידים חדשים נכנסים לשתיהן, בודקים שהאוטומציות החדשות ב-GoHighLevel באמת מגיבות (SMS, מייל, שיחת מעקב), ורק אחרי שרואים התנהגות תקינה על נתונים אמיתיים - לא רק ברשומת בדיקה - סוגרים את הגישה למערכת הישנה. שבוע-שבועיים של חפיפה זול בהרבה מליד אחד שנעלם באמצע.
מה לא עובר אוטומטית, ולמה זה עולה כסף אם מתעלמים ממנו
- אוטומציות (Workflows) - חייבים לבנות מחדש; שום ייבוא לא מעביר לוגיקה.
- מספרי טלפון לשליחת SMS - אם עוברים מספק אחר, יש הליך רישום A2P 10DLC נפרד שצריך להסתדר לפני ההודעה האוטומטית הראשונה - בלי זה ההודעות נחסמות על ידי חברות הסלולר (ראו מאמר קשור למטה).
- תקינות שליחת מיילים - דומיין שליחה חדש או שינוי בתצורת ה-DNS יכול לפגוע בפועל ב-deliverability אם לא מגדירים SPF, DKIM ו-DMARC מראש.
- הסכמות שתועדו אצל ספק קודם - אם אין תיעוד הסכמה שהועבר אל המערכת החדשה, יש כאן גם שאלה של חובת תיעוד לפי GDPR/CCPA, לא רק שאלה טכנית.
רשימת בדיקה ליום המעבר (Cutover)
- כל הטפסים באתר מכוונים לכתובת ה-webhook/API הנכונה של המערכת החדשה.
- מספרי הטלפון וכתובות ה-WhatsApp Business מועברים ופעילים במערכת החדשה, לא רק "מוגדרים".
- המערכת הישנה נשארת זמינה לקריאה בלבד (לא נמחקת) לפחות 30-90 יום, למקרה שצריך לבדוק רשומה ישנה.
- הצוות יודע איפה בדיוק נכנס ליד חדש מעכשיו - בלי "הרגל" לבדוק גם במערכת הישנה.
מתכננים מעבר ל-GoHighLevel?
אנחנו בונים לעסקים תוכנית מעבר מסודרת - מיפוי שדות, פייפליין, ואוטומציות - כך שהחפיפה בין המערכות לא עולה אפילו ליד אחד.
מתחילים מכאן