האוטומציה שלכם נכשלת? ב-94 אחוז זה עוד נחשב תקין

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

עיקרי הדברים

• Zapier מתעדת שתהליך נכבה אוטומטית כשיותר מ-95 אחוז מההרצות שלו נכשלו בשבעת הימים האחרונים והוא רץ יותר מעשרים פעמים באותה תקופה. תהליך שנכשל בתשעים אחוז מההרצות נשאר דולק.

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

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

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

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

האוטומציה נשברה. למה לא קיבלתם על זה שום הודעה

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

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

מה הפלטפורמה מגדירה כשגיאה, ומה היא לא מגדירה

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

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

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

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

למה הכשל השקט הוא זה שעולה כסף

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

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

מה קורה בצד של מטא כשהליד לא הגיע למערכת שלכם

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

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

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

שמונה סוגי כשל, ומה רואים בכל אחד מהם

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

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

מה זה עולה, באריתמטיקה על הנחות עבודה

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

נניח עלות ליד של 150 שקל, אחוז סגירה של שנים עשר אחוז ועסקה ממוצעת של 18,000 שקל. ארבעה ימי עבודה של שקט הם כחמש פניות: 750 שקל של תקציב מדיה שנשרף על לידים שאיש לא ראה, וכשש עשיריות של עסקה, כלומר כ-10,800 שקל של צינור מכירות.

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

מה רוב העסקים טועים בו

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

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

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

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

דרך העבודה: שש שורות בבדיקה השבועית

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

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

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

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

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

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

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

מה הנתונים לא אומרים

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

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

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

שאלות נפוצות

איך אני יודע שהאוטומציה שלי עובדת עכשיו?

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

הפלטפורמה שולחת לי מיילים על שגיאות. זה לא מספיק?

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

אם ה-Webhook לא נמסר, הליד אבד לגמרי?

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

כל כמה זמן צריך לבדוק?

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

מה הסף הנכון להתראת היעדר בעסק קטן?

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

זה לא אומר שכדאי לחזור לעבודה ידנית?

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

במה זה שונה מהמאמר על אוטומציות שמפספסות לידים?

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