מפויילוט לייצור: איך בונים צינור לידים קולי שאפשר לסמוך עליו

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

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

השלבים בצינור

1. שיחה: סוכן קולי מנהל שיחה בעברית ואוסף כוונה, תחום, גודל ארגון ופרטי קשר.
2. Webhook: בסיום השיחה נשלחת חבילת נתונים לנקודת קצה ציבורית ייעודית.
3. אימות: חתימת HMAC נבדקת לפני כל עיבוד; ללא חתימה תקפה מוחזר 401.
4. חילוץ: מודל שפה ממיר תמלול חופשי לשדות מובנים עם סכימה קשיחה.
5. ניקוד: הליד מקבל ציון התאמה 0–10 וקטגוריה תפעולית.
6. שמירה: רשומה נכתבת לבסיס הנתונים תחת מדיניות הרשאות ברמת שורה.
7. התראה: התראת דחיפה ודוא"ל נשלחות לצוות, עם קישור ישיר לרשומה.

אימות webhook הוא לא אופציונלי

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

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

חילוץ מובנה: הסכימה קודמת לפרומפט

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

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

ניקוד ICP: להפוך רשימה לתור עבודה

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

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

אמינות: כל קריאה חיצונית תיכשל מתישהו

ספק התמלול, ספק המודל וספק הדוא"ל — כולם יחזירו בשלב כלשהו 429 או 503. עטיפת ניסיונות חוזרים עם השהיה מעריכית ו-jitter היא ההבדל בין ליד אבוד לבין עיכוב של שתי שניות. שתי נקודות חשובות: לכבד כותרת Retry-After כשהיא קיימת, ולא לנסות שוב שגיאות 4xx שאינן 408 או 429 — קלט שגוי לא משתפר בניסיון נוסף.

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

פרטיות: מה לא נכנס ללוג

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

מה מודדים אחרי העלייה לאוויר

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

סיכום

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