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

תקציר

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

איך אוטומציות שונות מכלים אחרים

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

שני ההבדלים החשובים של אוטומציות מפיצ’רים אחרים:

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

איפה מגדירים אוטומציות

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

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

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

שלושת המרכיבים של אוטומציה

כל אוטומציה בנויה משלושה חלקים בסדר הזה:

1. מתי זה קורה (הטריגר)

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

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

2. רק אם התנאים מתקיימים (התנאים)

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

כל תנאי בנוי משלושה חלקים:

1. איפה. השדה שרוצים לבדוק. תלוי בטריגר (לדוגמה, בטריגר “סטטוס שיחה השתנה” אפשר לבדוק מהסטטוס או לסטטוס).
2. שווה ל. אופרטור ההשוואה.
3. הערך. הערך הספציפי להשוואה.

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

אפשר להוסיף כמה תנאים. כולם חייבים להתקיים יחד (לוגיקת AND) כדי שהאוטומציה תרוץ.

3. בצע את הפעולות האלו (הפעולות)

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

הפעולה שלח Webhook פותחת אפשרויות לאינטגרציה עמוקה. מומלץ לקרוא את הסעיף הייעודי עליה בהמשך.

דוגמאות לאוטומציות שעובדות

דוגמה 1: סגירה אוטומטית של שיחות נטושות

• טריגר: שיחה לא פעילה (90 דקות)
• תנאים: סטטוס = בטיפול
• פעולות: שלח הודעה מוכנה (“עוד צריך עזרה?”) + שנה סטטוס ל‑סגורה
• מקסימום ליום: 500

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

דוגמה 2: ניתוב אוטומטי של לידים חמים

• טריגר: התווסף לרשימה
• תנאים: רשימה = “ליד חם”
• פעולות: ציוות צוות = צוות מכירות
• מקסימום ליום: 100

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

דוגמה 3: סנכרון לסיום שיחה למערכת חיצונית

• טריגר: סטטוס שיחה השתנה
• תנאים: לסטטוס = סגורה
• פעולות: שלח Webhook ל‑https://yourcrm.com/conversation-closed עם פרטי השיחה

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

דוגמה 4: אונבורדינג אוטומטי בטיפול ראשון

• טריגר: סטטוס שיחה השתנה
• תנאים: מסטטוס = חדשה, לסטטוס = בטיפול
• פעולות: הוסף לרשימה = “לקוחות פעילים” + ציוות בוט = בוט אונבורדינג

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

פעולת ה‑Webhook במעמיק

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

כתובת ה‑Webhook

שדה URL אחד. זה ה‑endpoint שמאמבל תשלח אליו את בקשת ה‑POST כשהאוטומציה תרוץ. ה‑placeholder הוא https://example.com/webhook, ואתם ממלאים את הכתובת של המערכת המקבלת.

נתוני ה‑Webhook (Payload)

חשוב מאוד: אתם מגדירים את מבנה ה‑payload בעצמכם. מאמבל לא כופה סכימת JSON קבועה. אתם בונים את הזוגות של מפתח/ערך לפי מה שהמערכת המקבלת מצפה.

כל שורה כוללת:

• מפתח. שם המפתח ב‑JSON, טקסט חופשי (לדוגמה phone, customer_email, conversation_status).
• ערך. הערך, יכול להיות אחד משניים:
  • טקסט חופשי. נשלח כמו שהוא לכל אירוע.
  • משתנה מערכת. נבחר מתפריט המשתנים (אייקון של שלוש פסים). המשתנה ייפתר בזמן ההפעלה לפי הלקוח האמיתי (שמו, מספרו, סטטוס השיחה).

זה אומר שלכל אוטומציה אתם בונים payload מותאם בדיוק לדרישות המערכת המקבלת. אם המערכת מצפה ל‑{ "phone": "...", "event": "conversation_closed", "label": "..." }, אתם בונים את זה בדיוק. הגמישות הזו היא יתרון אבל גם משמעותה שכל אוטומציה דורשת הגדרה משלה.

אם אתם זקוקים לחיבורים מורכבים יותר (לדוגמה, סנכרון דו‑כיווני, אימות מתקדם), כדאי לראות גם את חיבור Mumble ל‑Make.

מקסימום פעולות ליום

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

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

איך לבחור ערך:

• אוטומציה לאירוע נדיר (לידים חמים שנוצרים בקצב של כמה ביום), תקרה של 50‑100 בטוחה.
• אוטומציה לאירוע תכוף (כל שינוי סטטוס, כל הודעה נכנסת), שקלו תקרה של 100, ובדקו אם זה מספיק.
• אוטומציה ל‑Webhook חשוב שאסור שיחסר, הגדירו תקרה גבוהה (100) ועקבו שהיא לא מתמלאת.

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

תכניות ומגבלות חודשיות

חריגה: 0.0039 דולר להפעלה נוספת.

חשוב להבין: המספרים הם הפעלות, לא מספר אוטומציות. אוטומציה אחת שרצה 50 פעמים ביום = 1,500 הפעלות בחודש. תקרת תכנית Standard של 250 הפעלות בחודש מספיקה לעסקים קטנים עם תהליכים פשוטים, לא לחשבונות פעילים. תכנית Pro מתאימה לרוב.

שיטות עבודה מומלצות

• תנו לאוטומציות שמות ברורים. “אוטומציה 1” יבלבל אתכם בעוד חודשיים. שם כמו “סגירה אוטומטית אחרי 90 דקות” אומר את הכל.
• התחילו עם תקרה יומית נמוכה, ועלו לפי הצורך. אוטומציה חדשה עם תקרה של 10 ביום מאפשרת לראות איך היא מתנהגת לפני שהיא מטפלת בכל החשבון.
• אל תנסו לבנות הכל באוטומציה אחת. אוטומציה אחת לכל מטרה. כשיש 5 פעולות ב‑3 תנאים, קל לעשות טעות לוגית. שתי אוטומציות פשוטות עדיפות על אחת מורכבת.
• בדקו את הטריגר לפני שמוסיפים פעולות. צרו אוטומציה עם פעולה אחת בלבד (לדוגמה, הוספה לרשימה), ראו אם היא רצה במצבים הנכונים, ורק אז הוסיפו פעולות נוספות.
• השתמשו ב‑Webhook לסנכרון, לא לפעולות חיוניות. ה‑Webhook עשוי להיכשל אם המערכת המקבלת לא זמינה. אם פעולה חייבת לקרות (לדוגמה, חיוב לקוח), אל תסמכו רק על ה‑Webhook. שלבו עם מנגנון רטריי או בדיקה תקופתית.
• זכרו שאוטומציה לא חוזרת לאחור. אוטומציה שיצרתם היום תרוץ רק על אירועים חדשים, לא על אירועים היסטוריים. ראו את הסעיף הבא.

התנהגויות שכדאי להכיר

אוטומציות לא רצות על נתונים היסטוריים

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

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

אין יומן הפעלות

אין יומן שמראה אילו אוטומציות רצו, מתי, ועל איזה לקוחות. אם אתם בודקים “האם האוטומציה הזו רצה אתמול?”, אתם צריכים לבדוק את התוצאות (האם ההודעה נשלחה? האם ה‑Webhook הגיע למערכת שלכם?). זה מקום שמקשה על דיבאג.

השהיה זמנית בלי מחיקה

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

בעיות נפוצות

יצרתי אוטומציה אבל היא לא רצה

בדקו לפי הסדר:

1. מתג פעיל מופעל?
2. הטריגר באמת מתרחש? לדוגמה, אם הטריגר הוא “התווסף לרשימה X”, האם לקוחות אכן נוספים לרשימה?
3. התנאים נכונים? לפעמים תנאי נראה נכון אבל מנותב לא כפי שחשבתם.
4. לא הגעתם למקסימום היומי?
5. החשבון לא בחריגה ממכסת ההפעלות החודשית?

אם הכל תקין, פנו לתמיכת מאמבל עם שם האוטומציה.

האוטומציה רצה אבל הפעולה לא קרתה

לדוגמה: שלח הודעה מוכנה שלא הגיעה. הסיבות:

• חלון 24 השעות סגור והניסיון היה לשלוח הודעת טקסט חופשית.
• התבנית במצב Paused או Rejected על ידי Meta.
• הלקוח ברשימה השחורה (מאופשר דיוור מבוטל).
• המגבלה היומית של Meta מולאה (ראו מגבלות שליחה במערכת הדרגים של Meta).

ה‑Webhook לא מגיע למערכת שלי

בדקו:

• הכתובת ב‑https (לא http) ותקינה?
• המערכת המקבלת באמת מצפה ל‑POST?
• המבנה של ה‑Payload תואם למה שהמערכת מצפה?
• אין חומת אש שחוסמת את כתובת ה‑IP של מאמבל?

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

האוטומציה רצה פעמיים על אותה שיחה

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

הגעתי למקסימום חודשי, מה לעשות?

• שדרגו לתכנית גבוהה יותר (Pro = 25,000 הפעלות).
• שלמו תשלום עודף (0.0039 דולר להפעלה נוספת).
• צמצמו אוטומציות פחות חיוניות עד החודש הבא.

אני רוצה דיליי בין הטריגר לפעולה

הטריגר “שיחה לא פעילה” הוא דיליי מובנה (תקופת חוסר פעילות לפני שהטריגר מופעל). אבל אין דיליי כללי שאפשר להוסיף לטריגרים אחרים. אם אתם זקוקים לרצף “טריגר → המתן 24 שעות → פעולה”, כדאי להשתמש בקמפיין דריפ במקום באוטומציה.

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

• בניית צ’אטבוט במאמבל
• טריגרים לצ’אטבוט
• Dolores AI, המדריך להתחלת עבודה
• שעות פעילות והודעת מחוץ למשרד
• חיבור Mumble ל‑Make
• Mumble API, המדריך המלא

שורה תחתונה

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