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

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

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

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

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

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

וזו הבעיה: הרוב המכריע של הכלים האלה - Make, Zapier, n8n - נבנים כך שהתרחיש ה"מאושר" עובד יפה, אבל מה קורה כשמשהו חורג ממנו לא תמיד מטופל. אם לא הגדרתם במפורש טיפול בשגיאות והתראות, כשל פשוט נופל בשקט. אתם לא תדעו עליו מהמערכת. תדעו עליו מהלקוח שמתקשר לשאול איפה החשבונית, או לא תדעו עליו בכלל.

בואו נפרק את זה לשלושה דפוסים שאני פוגשת שוב ושוב.

כשל 1: צד שלישי שינה משהו, ושלב אחד בשרשרת נשבר בשקט

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

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

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

כשל 2: הנפח גדל וחשף edge case שאף אחד לא בדק בהשקה

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

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

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

כשל 3: עובד גילה שהאוטומציה "מדלגת", והתחיל לעשות ידנית בלי לספר

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

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

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

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

הצ'ק-ליסט הרבעוני: איך מריצים את הביקורת בפועל

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

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

סיכום

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

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

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

בואו נדבר על זה >