מקרה בוחן: מה באמת קרה כשבנינו סוכן AI ללקוח אמיתי

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

הלקוח והבעיה

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

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

מה בנינו בפועל

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

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

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

איך זה השתלב עם התהליך הקיים, לא במקומו

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

מה לא עבד בשבוע הראשון

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

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

התוצאה בפועל

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

מספר שאני כן אוהבת לשתף: מתוך כ-40 לידים בשבוע בממוצע, הסוכן מסווג נכון כ-90% מהם בלי מעורבות אנושית בכלל. ה-10% הנותרים הם בדיוק המקרים שאני רוצה שיעברו לבדיקה אנושית – מקרים גבוליים או רגישים. זו לא כשלון של המערכת, זו בדיוק ההגדרה של Human-in-the-loop שעובד כמו שצריך.

מה הייתי עושה אחרת

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

למה זה עובד לטווח ארוך

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

מה זה אומר לגבי פרויקטים דומים

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

סיכום

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

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

בואו נדבר על זה > · ראו פרויקטים נוספים