הטעות היקרה ביותר באוטומציה היא לא באג בקוד — אלא עלייה לאוויר בלי השוואה. הסוכן רץ, הלקוחות מקבלים תשובות, ורק אחרי שבוע מגלים שחצי מההחלטות היו שונות ממה שנציג טוב היה עושה.
Shadow Mode הוא שלב שבו האוטומציה / סוכן AI רואה את אותם אירועים כמו התהליך החי, מחליט ומתעד — אבל לא משפיע על הלקוח. כך מודדים פערים בבטחה.
מה Shadow Mode כן ומה לא
כן:
- קורא אירועים אמיתיים (ליד חדש, הודעה, שינוי סטטוס)
- מריץ לוגיקה / מודל
- כותב המלצה, סיווג או טיוטת
ארכיטקטורה מינימלית
- מקור אירועים זהה לתהליך החי (webhook / תור / polling)
- מעבד Shadow מבודד (הרשאות קריאה בלבד כשניתן)
- אחסון החלטות עם מזהה אירוע, חותמת זמן, גרסת כללים
- שכבת השוואה מול פעולת האדם / המערכת החיה
- לוח מדדים לפערים ולהסכמה
בלי גרסת כללים בלוג — לא תדעו איזו גרסה נכשלה.
מה משווים בפועל
בחרו מדדי השוואה ברורים:
- הסכמה בסיווג (כוונה, תור, דחיפות)
- הסכמה בהסלמה (האם היה צריך אדם)
- קרבת ניקוד ליד (אם יש scoring)
- איכות טיוטת תשובה (מדגם אנושי, לא דיוק אוטומטי בלבד)
- שדות CRM שהיו מתמלאים מול
Shadow על סוכני AI מול אוטומציה כללים
כללים (rules): קל יחסית להשוות — תוצאה דטרמיניסטית.
סוכני AI: צריך גם:
- מדידת שונות בין הרצות
- בדיקת הבטחות אסורות בטיוטות
- סימון כשחסר הקשר מה-CRM
- הגבלת אורך וטון
ב-Shadow של סוכן — שמרו גם את הפרומפט/גרסת השלד, לא רק את הפלט.
חיבור ל-CRM בלי לזהם נתונים
המלצה:
- עסק: מה נחשב טעות חמורה
- תפעול: מי בודק מדגם ומתי
- טק: איך נראים לוגים ו-Kill Switch
תוכנית 10 ימים לדוגמה יום 1–2: הגדרת אירועים, לוגים, גרסאות
יום 3–4: חיבור קריאה מ-CRM והרצת shadow
יום 5–7: מדגם יומי + תיקון כללים
יום 8: סקירת ספים מול קריטריוני Go-Live
יום 9: Canary קטן (אם עברתם)
יום 10: הרחבה הדרגתית או חזרה ל-Shadow
תיאום עסקי-טכני
ישבו יחד לפני תחילת Shadow:
בלי הסכמה על "טעות חמורה" — המדדים לא יכוונו החלטה.
סיכום
Shadow Mode הוא הביטוח הזול ביותר לפני עלייה לאוויר של אוטומציה וסוכני AI: אותם אירועים, בלי השפעה על לקוח, עם השוואה, מדגם אנושי וקריטריוני Go-Live כתובים. מי שדולג עליו משלם אחר כך בתיקונים תחת אש.
רוצים להקים Shadow Mode מסודר לפני השקת אוטומציה אצלכם?
https://bramytech.com
050-7657001
i>כתבו לאובייקט/טבלה ייעודיים ל-shadow או לשדות prefix ברורים
- אל תדרסו שדות ייצור
- סנכרנו מזהי ליד לקריאה בלבד
- נקו נתוני shadow אחרי החלטה — לפי מדיניות שמירה
כאוס נתונים בזמן בדיקה הופך את Go-Live למסוכן יותר, לא פחות.
KPI ל-Shadow Mode
- שיעור הסכמה מול אדם / מערכת חיה
- שיעור אי-הסכמה קריטית (הייתה גורמת לנזק ללקוח)
- זמן עד תיקון כלל אחרי ממצא
- כיסוי תרחישים (כמה סוגי אירועים נראו)
- מוכנות Go-Live (checklist בינארי)
אם ההסכמה גבוהה אבל כיסוי התרחישים נמוך — אתם מוכנים רק למה שכבר ראיתם.
טעויות נפוצות
- Shadow על דאטה ישן בלבד בלי זרם חי
- אין בעלים לסקירת המדגם
- מעבר ל-Canary לפני סגירת פערים חוזרים
- מדידה טכנית בלי איכות תוכן
- שינוי כללים באמצע בלי לסמן גרסה
- "נריץ יומיים ונעלה" על תהליך רגיש
מה שמיולא בפועל
אל תמדדו רק "הסוכן רץ בלי שגיאה". יציבות טכנית ≠ איכות עסקית.
תוכנית דגימה ובקרה אנושית
Shadow בלי עיניים אנושיות הוא אשליה. הגדירו:
- מדגם יומי קבוע (למשל 20 אירועים)
- רשימת שאלות קצרה לנציג בודק: מסכים / חלקי / לא מסכים
- תיעוד סיבת אי-הסכמה (כלל חסר / הקשר חסר / טעות מודל)
- בעלים לתהליך התיקונים
אחרי שבוע של "הכול ירוק" בלי מדגם — אתם עיוורים.
קריטריוני Go-Live (דוגמה שעובדת)
עברו לאוויר רק כשמתקיימים יחד:
- לפחות N ימי Shadow רצופים (לרוב 7–14 לפי סיכון)
- הסכמה בסיווג מעל סף שנקבע מראש
- אין מחלקת שגיאה חוזרת באותו כלל בלי תיקון
- יש Kill Switch ולוגים בסביבת הייצור
- צוות התפעול יודע מה לעשות כשיש פער
כתבו את הספים. "נראה בסדר" הוא לא קריטריון.
פעולה ללוג
לא:
- לא שולח הודעות ללקוח
- לא מעדכן CRM בפעולות בלתי הפיכות (אלא אם בסביבת shadow ייעודית)
- לא מחליף נציג
- לא "פיילוט חלקי על לקוחות אמיתיים" — זה כבר canary
בלבול בין Shadow ל-Canary גורם לסיכון מיותר או לבדיקה חלשה מדי.
מתי Shadow Mode חובה
הריצו Shadow לפני Go-Live כשמתקיים אחד מאלה:
- סוכן AI מקבל החלטות סיווג / ניקוד / הסלמה
- אוטומציה נוגעת במחיר, הנחה, או הבטחת SLA
- יש חיבור חדש ל-CRM / וואטסאפ / מייל
- שינוי גדול בכללי עסק קיימים
- צוות חדש שלא מכיר את התהליך
אם הסיכון נמוך והפעולה הפיכה לחלוטין — אפשר לקצר. אם לא — אל תדלגו.