מעבר ל‑Mumble מ‑BSP אחר: מדריך הגירה מלא

תקציר

מעבר ל‑Mumble מספק WhatsApp Business API אחר נעשה דרך תהליך רשמי של Meta שנקרא Migration via Embedded Signup. המספר העסקי, שם התצוגה, דירוג האיכות של המספר, סטטוס Official Business Account וההודעות המוכנות המאושרות באיכות גבוהה עוברים יחד עם ההגירה. הלקוחות, הרשימות, הצ’אטבוט, האוטומציות והאינטגרציות לא עוברים, וצריך לבנות אותם מחדש ב‑Mumble.

רקע: איך עוברים בין BSPs

WhatsApp Business API לא מאפשר לפעול עם שני ספקים על אותו מספר בו‑זמנית. כל מספר עסקי משויך לחשבון WABA (WhatsApp Business Account) אחד, וכל WABA מקושר ל‑BSP אחד. הגירה היא תהליך שבו Meta מעבירה את המספר מ‑WABA אחד ל‑WABA חדש אצל ספק אחר, ושומרת על הנכסים שניתן להעביר.

Meta ממליצה על שתי שיטות. השיטה הראשונה, Migration via Embedded Signup, היא הדרך הסטנדרטית: הלקוח מתחיל את התהליך ממסך ההתחברות של Mumble, ויצירת ה‑WABA, הענקת ההרשאות ושכפול ההודעות המוכנות קורים אוטומטית. השיטה השנייה, Programmatic Migration, מיועדת רק למקרים שבהם ה‑BSP מחזיק בבעלות על ה‑WABA במודל On‑Behalf‑Of, וזה לא רלוונטי לרוב הלקוחות.

מה עובר ומה לא עובר בהגירה

זו ההפרדה החשובה בתכנון. כל מה שנמצא בצד של Meta עובר אוטומטית. כל מה שנמצא בצד של ה‑BSP הקודם לא עובר.

עובר אוטומטית (צד Meta)

שתי הסתייגויות חשובות לגבי הודעות מוכנות שעוברות. ראשית, דירוג האיכות שלהן לא נשמר. כל ההודעות המשוכפלות מתחילות ב‑UNKNOWN ב‑24 השעות הראשונות, ולאחר מכן Meta מחשבת דירוג חדש על סמך התנהגות הנמענים. שנית, Meta בודקת מחדש את הסיווג של כל הודעה לאחר השכפול. חלק מההודעות עלולות להפוך לסטטוס REJECTED אם הסיווג נחשב לא תואם להנחיות החדשות.

תקרת ההודעות לכל WABA. WABA יכול להחזיק עד 250 הודעות מוכנות. אם בחשבון הקודם יש יותר מ‑250 הודעות מאושרות באיכות גבוהה, Meta תשכפל כמה שאפשר עד התקרה, והשאר ייצרו מחדש ידנית.

אותו חשבון Meta Business. שכפול ההודעות עובד רק בין WABAs שמוחזקים תחת אותו Meta Business Account. ההגירה דרך Embedded Signup ממילא יוצרת את ה‑WABA החדש בתוך אותו חשבון Business, אבל זו עוד סיבה לוודא ש‑Embedded Signup רץ מול חשבון ה‑Business הקיים, ולא יוצר חשבון חדש.

לא עובר וצריך לבנות מחדש ב‑Mumble

כל מה שנמצא במערכת של ה‑BSP הקודם הוא מוצר שלהם ולא נכס של Meta, ולכן לא ניתן להעביר אותו אוטומטית.

• בסיס הלקוחות. שמות, מספרי טלפון, אימיילים, שדות מותאמים, סטטוסים. ייצוא ל‑CSV מהספק הקודם, ייבוא ל‑Mumble.
• רשימות (Labels / Lists). חלוקת לקוחות לפילוחים. ב‑Mumble אפשר ליצור רשימות דרך עמודת label_name בייבוא ה‑CSV.
• שדות מותאמים אישית. Mumble תומכת בעד 15 שדות לחשבון, לכן כדאי לתכנן מראש איזה שדות חיוניים.
• היסטוריית שיחות והודעות. לא מועברת. במקרים מסוימים אפשר לייצא ארכיון מהספק הקודם, אבל הוא לא ייכנס לצ’אט של Mumble.
• סוכנים, צוותים והרשאות. צריך להזמין מחדש את כל הצוות וליצור צוותים ומחלקות מאפס.
• צ’אטבוט. תהליכים של בוטים לא ניתנים לייבוא בין BSPs. צריך לבנות מחדש בקנבס של Mumble.
• אוטומציות (When / If / Then). חוקים שהוגדרו אצל הספק הקודם לא יחולו ב‑Mumble.
• אינטגרציות חיצוניות. חיבורים ל‑Make, Zapier, HubSpot, Shopify וכו’ עובדים מול ה‑API ו‑וובהוקים של הספק הקודם. צריך להחליף את מפתח ה‑API ואת ה‑URLs בכל אינטגרציה לערכי Mumble.
• וובהוק קבלת הודעות לשרת חיצוני. Mumble מאפשרת להגדיר וובהוק חדש בפרופיל הטכני, אבל הכתובת מוגדרת מחדש על ידי הלקוח.
• פרופיל עסקי. השם, האודות, הכתובת, האתר, התמונה ושעות הפעילות. חלקם מסונכרנים מ‑WhatsApp, אבל כדאי לעבור עליהם ב‑Mumble אחרי החיבור.
• היסטוריית קמפיינים ודוחות. נתוני שליחה היסטוריים נשארים אצל הספק הקודם.

דרישות מקדימות לפני התחלת ההגירה

Meta דורשת שכל התנאים הבאים יתקיימו לפני שתהליך ההגירה יושלם. אי עמידה באחד מהם תגרום לכישלון של Embedded Signup, לעיתים בלי הודעת שגיאה ברורה.

1. חשבון Meta Business במצב Verified. אם החשבון לא עבר אימות עסק (Business Verification), צריך להשלים את התהליך לפני ההגירה. בודקים זאת ב‑Meta Business Manager תחת Business Settings ולאחר מכן Business Info.
2. ה‑WABA הקיים במצב Approved. חשבון WhatsApp Business Account פעיל, לא מושעה ולא בבדיקה.
3. אמצעי תשלום תקין ב‑Meta. אצל הספק הנוכחי, בפרופיל ה‑WABA תחת Payment Settings. גם אם הספק הקודם גובה במודל אחר, Meta דורשת שיהיה אמצעי תשלום מקושר.
4. אימות דו‑שלבי מבוטל על המספר. זו הדרישה שמפילה הכי הרבה הגירות. צריך לבטל את ה‑Two‑Step Verification על המספר העסקי ב‑WhatsApp Manager של Meta. אם הספק הקודם הפעיל את האימות והלקוח לא יכול לבטל אותו עצמאית, צריך לפתוח קריאה אצל הספק הקודם ולבקש ביטול. אי אפשר להמשיך בלי שזה מבוטל.
5. שם תצוגה מאושר וללא בקשת שינוי תלויה. name_status חייב להיות APPROVED, ולא יכולה להיות בקשת שינוי שם פתוחה.
6. המספר אינו Test Number. מספרי בדיקה (Test Business Phone Numbers) שמסופקים על ידי WhatsApp לא ניתנים להגירה.
7. המספר אינו במצב Coexistence. מספרים שמשתמשים ב‑WhatsApp Coexistence (כלומר עובדים גם דרך אפליקציית WhatsApp Business וגם דרך Cloud API) לא ניתנים להגירה בין BSPs. צריך לסיים את ה‑Coexistence לפני ההגירה.

תהליך ההגירה צעד אחר צעד

שלב 1: ייצוא הנתונים מהספק הקודם

לפני שמתחילים את ההגירה ב‑Meta, ייצאו מהספק הקודם כל מה שאפשר. הקבצים יחכו לעלייה ל‑Mumble אחרי שהמספר יחובר.

• קובץ CSV של כל הלקוחות. שמות, טלפונים בפורמט בינלאומי בלי + ובלי 0 מקדים (לדוגמה 972501234567), אימיילים, ושדות מותאמים.
• רשימה של כל ה‑Labels / Lists עם שמותיהם, כדי לתכנן אילו רשימות נדרשות ב‑Mumble.
• תיעוד של תהליכי הצ’אטבוט. צילומי מסך או תרשים זרימה לשחזור מהיר.
• רשימת אינטגרציות פעילות (Make, Zapier, CRM, חנות) ומה כל אחת מהן עושה.
• תוכן ההודעות המוכנות. גם אם הן ישוכפלו אוטומטית, כדאי לשמור עותק לבטיחות, ובמיוחד הודעות שאינן במצב APPROVED ולא יעברו.

שלב 2: ביטול אימות דו‑שלבי

במסך ה‑WhatsApp Manager של Meta, לחצו על המספר העסקי, היכנסו ל‑Two‑Step Verification ולחצו על Disable. אם הכפתור לא פעיל או הגישה למסך חסומה, סימן שלספק הקודם יש בעלות מלאה על ה‑WABA. במקרה כזה צריך לפנות אליהם בכתב (אימייל או טיקט) ולבקש ביטול אימות דו‑שלבי לצורך הגירה. כדאי לשמור את האישור בכתב.

תיעוד מלא: Disabling Two‑Step Verification ב‑Meta Developer Docs.

שלב 3 (אופציונלי אך מומלץ): הקדמת שכפול ההודעות המוכנות

בעבר Meta דיווחה על תקלות חוזרות שגרמו לכך שהודעות מוכנות לא שוכפלו אוטומטית במהלך ההגירה. Meta ממליצה לבצע את שכפול ההודעות לפני רישום המספר. בפועל זה אפשרי דרך נקודת הקצה POST /<DESTINATION_WABA_ID>/migrate_message_templates של Meta Graph API. צוות ההטמעה של Mumble יכול לבצע את זה במידת הצורך. השלב הזה לא חובה, אבל הוא מקטין את הסיכון לחלון השבתה בקמפיינים.

שלב 4: התחלת ההצטרפות ל‑Mumble

היכנסו ל‑app.mumble.co.il וצרו חשבון חדש. בחשבון קיים, היכנסו לפרופיל הטכני ולחצו על “לחצו כאן כדי לחבר את חשבון הוואטסאפ ביזנס החדש”. תהליך החיבור פותח חלון Embedded Signup רשמי של Meta בתוך הסביבה של Mumble.

במסכי Embedded Signup:

• התחברו עם חשבון ה‑Facebook שמנהל את העסק.
• בחרו את חשבון ה‑Meta Business הקיים, ולא חשבון חדש.
• הזינו את אותו מספר הטלפון העסקי שמופעל אצל הספק הקודם.
• אם Meta מזהה שהמספר רשום ב‑WABA אחר, היא תציע תהליך הגירה. אשרו.
• Meta תיצור אוטומטית WABA חדש בתוך חשבון ה‑Business, תקצה ל‑Mumble גישה אליו, ותעביר את המספר.

שלב 5: שכפול הודעות מוכנות ורישום המספר

בו‑זמנית עם רישום המספר, Meta מתחילה לשכפל את ההודעות המוכנות (אם לא הוקדמו בשלב 3). השכפול עצמו לוקח זמן, ובמהלכו ההודעות לא זמינות לשליחה. רישום המספר עצמו ל‑Cloud API מיידי ולא יוצר הפסקה בקבלה ושליחה של הודעות בחלון שיחה פתוח.

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

שלב 6: הוספת אמצעי תשלום ב‑Meta

ה‑WABA החדש זקוק לאמצעי תשלום נפרד ב‑Meta. מנוי Mumble מכסה את הפלטפורמה בלבד, ו‑Meta גובה בנפרד עבור שליחת ההודעות עצמן לפי קטגוריה ומדינת נמען. במאמבל, בפרופיל האישי שבהגדרות, תופיע ההודעה “לאחר השלמת החיבור למטא על מנת להתחיל לשלוח הודעות, אנא הוסיפו פרטי תשלום למטא” עם קישור ישיר. הוסיפו כרטיס אשראי ב‑Meta Business Manager לפני הקמפיין הראשון.

שלב 7: בניית הסביבה ב‑Mumble

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

1. שדות מותאמים אישית. הגדירו בעמוד לקוחות, שדות מותאמים אישית עד 15 שדות שיתאימו לעמודות בקובץ ה‑CSV. ראו ייבוא והעלאת אנשי קשר.
2. ייבוא לקוחות. הורידו את קובץ הדוגמה ב‑Mumble כדי לראות את שמות העמודות המדויקים. התאימו את ה‑CSV מהספק הקודם וייבאו. רשימות חדשות ייווצרו אוטומטית לפי הערך בעמודת label_name.
3. סוכנים וצוותים. הזמינו את הסוכנים, הגדירו תפקידים (סוכן, מנהל צוות, מנהל מחלקה, אדמין), וצרו צוותים ומחלקות. ראו ניהול נציגים וצוותים.
4. פרופיל עסקי ושעות פעילות. בהגדרות, פרופיל עסקי, ודאו ששם העסק, האודות, הכתובת, האימייל, האתר והתיאור תקינים. הגדירו שעות פעילות והודעה לזמני סגירה.
5. צ’אטבוט ואוטומציות. בנו מחדש את התהליכים בקנבס הצ’אטבוט, והגדירו אוטומציות שמחקות את הלוגיקה מהספק הקודם.
6. אינטגרציות ו‑וובהוקים. בפרופיל הטכני, העתיקו את מפתח ה‑API החדש והגדירו את כתובת ה‑Webhook. עדכנו ב‑Make, Zapier ובמערכת ה‑CRM את נקודות הקצה החדשות.
7. הודעות מוכנות חסרות. הודעות שלא עברו (לא היו מאושרות באיכות גבוהה, או חרגו מתקרת 250 ההודעות), צרו מחדש בעמוד הודעות מוכנות והגישו ל‑Meta לאישור.

זמנים וזמינות במהלך ההגירה

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

איך מקטינים את חלון ההשבתה. אם יש שליחת קמפיינים יומית שלא יכולה להפסיק לרגע, ניתן להקדים את שכפול ההודעות (שלב 3) לפני רישום המספר. כך כשהמספר נרשם ל‑Cloud API, ההודעות כבר מוכנות לשליחה ב‑WABA היעד.

חיוב במהלך ההגירה ואחריה

החיוב על שיחות WhatsApp הוא של Meta ונפרד מתשלום ל‑BSP. Meta מבדילה בין הודעות לפי תזמון השליחה, לא תזמון המסירה.

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

טיפול בבעיות נפוצות

Embedded Signup נכשל עם הודעה לא ברורה

הסיבה הנפוצה ביותר היא אימות דו‑שלבי שעדיין פעיל על המספר. סיבות נוספות: ה‑Business לא Verified, אמצעי תשלום חסר ב‑Meta, בקשת שינוי שם תצוגה תלויה, או שהמספר נמצא במצב Coexistence. בדקו את חמשת הסעיפים האלה לפני שמנסים שוב.

הודעות מוכנות שעברו מופיעות במצב נדחה (REJECTED)

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

הודעות מוכנות לא הופיעו כלל ב‑Mumble אחרי ההגירה

Meta דיווחה בעבר על תקלות חוזרות בשכפול הודעות. אם ההודעות לא הופיעו, פנו לתמיכת Mumble כדי שתפעיל את שכפול ההודעות ידנית דרך Meta Graph API. ההודעות יופיעו ב‑Mumble תוך פרק זמן קצר לאחר ההפעלה.

איכות ההודעות המוכנות מוצגת כ‑UNKNOWN

זו התנהגות צפויה ב‑24 השעות הראשונות לאחר ההגירה. Meta מחשבת מחדש את האיכות על סמך התנהגות הנמענים. אין מה לעשות. לאחר 24 שעות, אם נשלחו מספיק הודעות, יחושב דירוג חדש (Green, Yellow או Red).

הספק הקודם מציג שהמספר מנותק

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

קמפיינים שתוזמנו מראש אצל הספק הקודם לא נשלחים

תזמונים שמוגדרים בצד ה‑BSP לא עוברים. אם היו תזמונים פתוחים, צריך להגדיר אותם מחדש בעמוד הקמפיינים של Mumble.

אינטגרציות חיצוניות מפסיקות לעבוד מיד אחרי ההגירה

אינטגרציות שמדברות עם ה‑API של הספק הקודם פונות לנקודות קצה שכבר לא קשורות למספר. שנו את ה‑Base URL, מפתח ה‑API והוובהוקים בכל אינטגרציה לערכי Mumble. כל הערכים נמצאים בפרופיל הטכני.

קישורים קשורים

• חיבור מספר WhatsApp קיים ל‑Mumble
• ייבוא והעלאת אנשי קשר
• מדריך הודעות מוכנות WhatsApp
• סטטוסים וכללים להודעות מוכנות
• ניהול נציגים וצוותים
• תיעוד Meta: Migration via Embedded Signup

שורה תחתונה

הגירה ל‑Mumble שומרת על הנכסים שב‑Meta (מספר, שם תצוגה, איכות, OBA, והודעות מוכנות מאושרות באיכות גבוהה), אבל לא מעבירה את שכבת התפעול. תכננו את ההגירה בשני חלקים: החלק הטכני מול Meta, שהוא מהיר וברובו אוטומטי, ובניית הסביבה ב‑Mumble (לקוחות, צוות, צ’אטבוט, אוטומציות, אינטגרציות), שבה מושקע רוב הזמן.