Fireberry (Powerlink) ואוטומציה - חיבור לוואטסאפ, לחשבונית ולמערכות חיצוניות

קודם כל: מה כבר יש לכם בפנים

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

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

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

מתי כן צריך כלי חיצוני

עבודה מול הממשק

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

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

המלכודת המרכזית: שמות ומזהים

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

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

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

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

חיבור לוואטסאפ

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

רשמי מול לא רשמי

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

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

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

מה שצריך לבנות מעבר לשליחה

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

חיבור להפקת חשבוניות

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

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

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

מה כדאי לסגור לפני שמתחילים

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

מה לבנות בפנים ומה בחוץ

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

מה לסדר במערכת לפני שמחברים

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

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

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

השורה התחתונה

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

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