איך לחבר וואטסאפ ל-CRM: מדריך ל-Fireberry, Monday ו-Pipedrive

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

נתחיל מהארכיטקטורה ואז נרד לפרטים של Fireberry, Monday ו-Pipedrive.

שלוש ארכיטקטורות חיבור

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

הבעיה האמיתית: מיפוי מספרי טלפון

זה מקור התקלות מספר אחת, והוא לא מרגש אבל הוא קריטי. וואטסאפ מזהה משתמש לפי מספר בפורמט בינלאומי בלי סימנים. רוב ה-CRM בישראל מלאים במספרים שהוקלדו ידנית לאורך שנים.

הפתרון הוא שדה נורמליזציה. מוסיפים ל-CRM שדה מחושב או שדה נוסף שמחזיק את המספר בפורמט E.164 - כלומר 972 ואחריו המספר בלי אפס מוביל ובלי סימנים - ומחפשים לפיו בלבד. את הנתונים הקיימים מנקים פעם אחת בסקריפט, ואת החדשים מנרמלים בכניסה.

1. 1הסירו כל תו שאינו ספרה: רווחים, מקפים, סוגריים, פלוס.
2. 2אם המספר מתחיל ב-0, הסירו את האפס והוסיפו 972 בתחילתו.
3. 3אם המספר כבר מתחיל ב-972, השאירו כפי שהוא.
4. 4אם המספר קצר מ-11 ספרות אחרי הטיפול, סמנו אותו כלא תקין ואל תשלחו - אל תנחשו.
5. 5שמרו גם את המספר המקורי בשדה נפרד, כדי שאנשים ימשיכו לראות מה שהם מכירים.

כל פרויקט וואטסאפ שנתקע חודש נתקע על מספרי טלפון, לא על API.

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

Fireberry

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

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

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

Monday

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

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

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

Pipedrive

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

• מבנה הנתונים מפריד בין Person, Organization ו-Deal. הודעה מתחברת ל-Person, אבל הלוגיקה העסקית לרוב תלויה ב-Deal הפתוח.
• ה-webhooks של Pipedrive נוחים ואמינים, ואפשר לטרגר על שינוי שלב בעסקה. זה הבסיס לרצפי מעקב אוטומטיים.
• שדות מותאמים מזוהים במזהה ייחודי ארוך ולא בשם. שמרו טבלת מיפוי במקום לחפש את השם בקוד - שינוי שם שדה בממשק לא ישבור, אבל מחיקה כן.
• מגבלת הקצב נמדדת בטוקנים לתקופה. פעולה כבדה כמו סנכרון היסטורי צריכה לרוץ בקצב מבוקר ולא בלולאה מהירה.

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

השוואה מהירה

מה לשמור ומה לא

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

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

אמינות - החלק שאף אחד לא מתקצב

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

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

שאלת הכיוון: מי מנצח כשיש סתירה

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

שלוש מדיניות אפשריות, וכולן לגיטימיות כל עוד בוחרים אחת במפורש:

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

סדר עבודה מומלץ

1. 1נקו את מספרי הטלפון הקיימים והוסיפו שדה בפורמט אחיד.
2. 2הגדירו בכתב מה קורה כשמספר לא נמצא, נמצא פעמיים, או שייך לרשומה סגורה.
3. 3הקימו כיוון אחד קודם - הודעות נכנסות אל ה-CRM. זה מספק ערך מיידי ולא מסוכן.
4. 4רק אחר כך הוסיפו את הכיוון השני - שליחה יזומה מתוך ה-CRM.
5. 5הריצו שבועיים על קבוצה מצומצמת ובדקו את הרשומות שנוצרו בעין אנושית.
6. 6הרחיבו, והגדירו סקירה רבעונית של כפילויות ותקלות.

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