איך לנתב פניות שירות עם Jev AI ובקרה אנושית
מדריך מעשי לתכנון ניתוב פניות שירות עם Jev AI: הגדרת קטגוריות, בדיקת תשובות, ניסוי בעברית והעברה לנציג כשאין החלטה אמינה.
אפשר להתחיל להשתמש ב-AI בשירות לקוחות בלי לתת לו לענות ללקוחות: תנו לו להציע לאיזה צוות להעביר כל פנייה, והשאירו מסלול ברור לבדיקה אנושית. מדריך קהילתי על Jev AI, שפורסם ב-Hugging Face ב־21 בספטמבר 2026, מדגים בניית החלטות מובנות לצורך תהליך כזה. הנה דרך מעשית לתכנן ניסוי בעסק ישראלי, עם בדיקות בעברית ובלי לחבר החלטה לא בדוקה ישירות למערכת השירות.
1. הגדירו איזו החלטה מותר למערכת לקבל
המדריך, ששמו Jev AI API Tutorial: Build Your First Structured Decision with Choice, Score, and Noul, עוסק בבניית בקשת API, טיפול בתשובה וניתוב אוטומטי או העברה לאדם. זהו פרסום קהילתי, לא הכרזה רשמית של Hugging Face על מוצר חדש. אפשר להגיע אליו דרך [המדריך המקורי](https://huggingface.co/blog/sora-2/jev-ai-api-tutorial-build-your-first-structured-de).
לניסוי ראשון, בחרו תיבת פניות אחת ומשימה מוגבלת: המלצה על צוות מטפל. אל תצרפו בשלב הזה החזרים כספיים, שינוי הזמנות או שליחת תשובות ללקוח. ההפרדה מאפשרת לבדוק אם המיון שימושי לפני שמעניקים למערכת סמכות לבצע פעולות בעלות משמעות עסקית.
- חיוב: בירור על חשבונית, תשלום או חיוב שנראה כפול.
- משלוח: בירור מיקום חבילה או שינוי בפרטי מסירה.
- תקלה: דיווח על מוצר או שירות שאינם פועלים.
- בדיקה אנושית: פנייה עמומה, כמה נושאים יחד או מקרה שהעסק החריג מאוטומציה.
אלה קטגוריות מוצעות לניסוי, לא ערכים מתועדים של Jev AI. כתבו לכל אחת הגדרה, דוגמה ומקרה גבול. למשל, בפנייה ״המשלוח לא הגיע ואני רוצה זיכוי״ צריך להחליט מראש אם צוות המשלוחים מטפל ראשון או שהשילוב מחייב נציג. בלי כלל כזה, גם ההשוואה בין החלטת המערכת להחלטת העובד תהיה לא עקבית.
אוטומציה טובה צריכה לדעת גם מתי לא להחליט.
2. הכינו פניות לבדיקה וכללי טיפול במידע
אספו דוגמאות מייצגות מערוצי השירות שבהם אתם עובדים, בכפוף להרשאות ולמדיניות הארגון. לפני העברה לספק חיצוני, הסירו פרטים שאינם נחוצים למיון: מספרי זהות, פרטי תשלום, כתובות מלאות ומזהים אישיים. בדקו בנפרד את תנאי שמירת המידע והשימוש בו אצל הספק; התחקיר המצורף אינו מספק תשובות בנושאים האלה.
בקשו מנציגים לסמן את הקטגוריה הרצויה ואת המקרים שבהם חסר מידע. כששני נציגים חלוקים, בררו אם הבעיה היא בניסוח הפנייה או בהגדרת הקטגוריה. שמרו חלק מהדוגמאות לבדיקה מאוחרת, ואל תשתמשו בהן לשיפור ההנחיות, כדי שלא תבדקו רק מקרים שכבר התאמתם להם את המערכת.
לעסק בארץ חשוב לכלול יותר מעברית תקנית: הודעות קצרות מהטלפון, שגיאות כתיב, סלנג וטקסט כמו ״ה־tracking תקוע אבל ירד לי חיוב״. אם אתם מטפלים גם בערבית, רוסית או אנגלית, הכינו קבוצת בדיקה נפרדת לכל שפה. הצלחה בשפה אחת אינה ראיה לאיכות בשפה אחרת.
זהו מדריך לתכנון ולבדיקת התהליך, לא דיווח על הרצה שביצענו. התחקיר אינו כולל endpoint, שיטת אימות, schema מלא, מחירים או תוצאות בעברית. את פרטי החיבור ומשמעות שדות התשובה יש לאמת בתיעוד לפני כתיבת האינטגרציה.
3. חברו את ה-API דרך שכבת אימות
בשלב המימוש, בנו רכיב שמקבל את הטקסט המצומצם של הפנייה, יוצר בקשה בהתאם לתיעוד ומחזיר תוצאה פנימית לאפליקציה. אל תנחשו את המבנה של Choice, Score או Noul מתוך שמותיהם בלבד. השתמשו בדוגמה המקורית כדי להבין את החוזה, ואז בדקו אותו מול התיעוד הזמין של השירות.
בתוך האפליקציה כדאי להגדיר חוזה משלכם: קטגוריה מוצעת, סימון אם נדרשת בדיקה אנושית וסיבת ההעברה לבדיקה. אלה שדות תכנון מקומיים, לא שמות שדות של Jev AI. המתאם שתכתבו צריך לתרגם את תשובת השירות לחוזה הזה ולדחות תשובות שלא ניתן לפרש בבטחה.
- שלחו את הבקשה מצד השרת ושמרו את מפתח ה-API מחוץ לקוד הלקוח.
- בדקו שהבקשה הסתיימה בהצלחה ושהתשובה תואמת למבנה המתועד.
- ודאו שהקטגוריה המוצעת נמצאת ברשימת הקטגוריות המאושרות.
- החילו את כללי העסק, כולל חריגים שמחייבים בדיקה אנושית.
- במקרה של timeout, תשובה חסרה או שגיאת פענוח, השאירו את הפנייה בתור נגיש לנציג.
אם התשובה כוללת ציון ביטחון, אל תתייחסו אליו אוטומטית כהסתברות שההחלטה נכונה. תחילה צריך להבין מה הציון מודד, ואחר כך לבדוק איך הוא קשור לטעויות בדוגמאות שלכם. סף ניתוב הוא החלטה תפעולית שצריך לבסס על בדיקה, לא מספר שמעתיקים ממדריך.
4. בדקו בעברית והשוו להחלטות הנציגים
הריצו את קבוצת הבדיקה השמורה והשוו כל המלצה לסימון האנושי. אל תסתפקו בשיעור הצלחה כולל: בדקו אילו קטגוריות מתבלבלות זו בזו, כמה פניות מגיעות לבדיקה ידנית ואילו טעויות עלולות לעכב לקוח. ניתוב שגוי של בירור כללי אינו בהכרח שקול לניתוב שגוי של טענה לחיוב לא מורשה.
בדקו במיוחד שלילה, ציניות וריבוי נושאים. ״אין בעיה במשלוח, הבעיה בחשבונית״ לא אמור להגיע למשלוחים רק בגלל מילת מפתח. הוסיפו גם הודעות שמנסות להורות למערכת לבחור קטגוריה מסוימת: תוכן הפנייה הוא חומר לסיווג, לא הרשאה לשנות את כללי הניתוב.
תעדו לכל טעות את סוג הפנייה, ההמלצה שהתקבלה והטיפול הנכון. תקנו הגדרות עמומות והנחיות חסרות, ואז בדקו שוב על דוגמאות שלא שימשו לתיקון. אם המערכת מצליחה רק בניסוחים מסודרים, צמצמו את השימוש אליהם במקום להכריז שהיא מוכנה לכל תיבת השירות.
5. הפעילו במצב צל ורק אז פתחו ניתוב אוטומטי
במצב צל המערכת מציעה קטגוריה, אבל הנציגים ממשיכים לנתב בפועל. כך אפשר לבדוק על פניות שוטפות אם ההמלצות מועילות, בלי לשנות את חוויית הלקוח. מדדו גם זמני תגובה, כשלי API, עלות בפועל והעברות חוזרות בין צוותים, ולא רק התאמה לתווית.
לאחר בדיקה, אפשר לפתוח ניתוב אוטומטי רק לקטגוריות שבהן התוצאות עומדות בדרישות שהגדרתם. השאירו אפשרות לתיקון ידני, תיעוד של ההמלצה המקורית ומתג שמחזיר את כל הפניות לטיפול אנושי. ודאו גם שניסיון חוזר לאחר תקלה אינו יוצר פעולה כפולה במערכת השירות.
עבור צוות ישראלי קטן, יעד פתיחה שימושי הוא להפחית מיון ידני בפניות פשוטות, לא להחליף את מוקד השירות. אם המערכת מעבירה יותר מדי מקרים לאדם, בדקו תחילה את הקטגוריות ואת איכות הקלט. הורדת סף הביטחון רק כדי להגדיל אוטומציה עלולה להעביר את העבודה שנחסכה לתיקון טעויות בהמשך.
שאלות נפוצות
איך משתמשים ב-Jev AI כדי למיין פניות שירות?
מגדירים קטגוריות טיפול וכללי העברה לנציג, מחברים בקשת API לפי התיעוד ובודקים את התשובה לפני ביצוע הניתוב. המדריך הקהילתי מתאר תהליך כזה, אך פרטי החיבור המדויקים אינם כלולים בתחקיר שעליו מבוססת הכתבה.
האם Jev AI מתאים לפניות שירות בעברית?
התחקיר אינו כולל תוצאות בדיקה בעברית, ולכן אין בסיס להבטיח איכות מיון. לפני הפעלה צריך לבדוק פניות מייצגות, כולל סלנג, שגיאות כתיב ושילוב עברית ואנגלית, ולהשוות להחלטות של נציגים.
מתי מערכת AI צריכה להעביר פניית שירות לאדם?
כאשר התשובה חסרה או לא תקינה, כשהפנייה אינה מתאימה לקטגוריה מוגדרת או כשאין בסיס מספיק להחלטה אוטומטית. מומלץ להעביר לנציג גם מקרים רגישים שהעסק החריג מראש, בלי להסתמך רק על ציון ביטחון.
דרגו את הכתבה
הדירוג עוזר לנו לדעת מה שווה לכם.
תגובות