הפתרון
מייל נכנס ← זיהוי דייר וצוות (לוגיקה קבועה) ← חילוץ וסיווג (Gemini Flash) ← ניתוב ל-4 מסלולים (קריטי / דחוף-רגיל / בדיקה ידנית / כשל טכני) ← כתיבה ל-Sheets + התראה מתאימה. שכבת AppSheet מעליה נותנת לצוות השטח ממשק עבודה יומיומי מהטלפון.
מ-30 דקות טיפול ידני לדקות ספורות - פרויקט מלא: Make · Gemini · AppSheet · Google Data Studio
חברת נדל"ן המנהלת 18 פרויקטים במקביל טיפלה ב-800 פניות דיירים בחודש בתהליך ידני לגמרי - מייל, וואטסאפ ומכתבים שעברו בין רכזי שטח בלי שום סנכרון. בניתי מערכת קצה-לקצה שמזהה את הדייר, מסווגת את חומרת הפנייה באמצעות AI, ומנתבת אותה אוטומטית לטיפול הנכון - עם רשתות ביטחון לכל מקרה שה-AI לא בטוח בו.
מידע לא מובנה (טקסט חופשי, תמונות) בשילוב החלטה סובייקטיבית (רמת חומרה) - שילוב שלא ניתן לפתרון בכלל קשיח מסורתי, ודורש הבנת שפה טבעית.
מייל נכנס ← זיהוי דייר וצוות (לוגיקה קבועה) ← חילוץ וסיווג (Gemini Flash) ← ניתוב ל-4 מסלולים (קריטי / דחוף-רגיל / בדיקה ידנית / כשל טכני) ← כתיבה ל-Sheets + התראה מתאימה. שכבת AppSheet מעליה נותנת לצוות השטח ממשק עבודה יומיומי מהטלפון.
בחרתי Resume ולא Rollback לטיפול בכשל API - בפנייה לא-קריטית, עצירת כל התהליך יקרה יותר מהזרמה מיידית לתור ידני.
מדידת אמינות החלטת ה-AI נבנתה כדו-כיוונית, לא חד-כיוונית - כך שגם מקרה שבו ה-AI היה זהיר מדי נתפס, לא רק מקרה שבו הוא היה מקל מדי.
הפרדתי בין מדד היסטורי לתפעולי על אותו נתון בדיוק (Backoffice) - כי "כמה AI טעה אי-פעם" ו"כמה עבודה יש עכשיו" הן שתי שאלות שונות שדורשות שתי תשובות שונות.
הבחנתי בין AI_urgency ל-Urgency בחישוב הדיוק - שדה אחד קבוע (תמונת קפאה) ואחד מתעדכן, כדי שמדד ההצלחה לא יתעוות ככל שיותר קריאות נסגרות.
שיעור Backoffice: 23.7% היסטורי מצטבר, 9 קריאות ממתינות בפועל
Delta סיווג: 6.9%-20% שבועי, מול יעד 85% דיוק לאישור מעבר ל-Production
זמן עד אישור: ירידה מ-30 דקות ידניות לדקות בודדות בפיילוט
