העברת בוט AI לנציג: העברת הקשר חלקה

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע handoff של בוט AI מאבד את הקשר הדיאלוג

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

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

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

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

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

מה משתנה לאחר העברה חלקה של הפנייה

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

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

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

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

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

תאימות עם מערכות רישום אנחנו מכסים דרך ממשקים פתוחים — מ-Zendesk ועד לפאנלים פנימיים של תמיכה. להלן מה שמשתנה בדיוק לאחר ההפעלה:

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

מצבי העברת הדיאלוג לנציג והמגבלות שלהם

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

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

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

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

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

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

כיצד אנחנו מיישמים העברת הקשר: שלבי העבודה

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

  1. ביקורת תרחישי הבוט: מפרקים את עץ הדיאלוגים ומוצאים מבויי סתום — ניסוחים שלא זוהו, נושאים מחוץ לתרחיש, בקשות חוזרות.
  2. תרשים העברת הנתונים: מגדירים את הרכב ההקשר — היסטוריית ההודעות, המטרה שזוהתה, השדות שמולאו בפנייה, מזהה הסשן — ומאיפה עמדת הנציג שולפת אותו.
  3. הגדרת כללי אסקלציה: טריגרים — בקשה מפורשת של אדם, כמה כשלי זיהוי ברצף, תגובה שלילית, שתיקה ממושכת. לכל כלל קובעים עדיפות ומסלול לתור המתאים.
  4. הרכבת כרטיס הנציג: כל ההקשר במסך אחד — מה שאל הלקוח, מה הבוט כבר ענה, ומה נשאר לברר. אין צורך להרים את הדיאלוג ביד.
  5. בדיקה על פניות אמיתיות: הרצה על זרימה חיה, מדידת שיעור ההעברות התקינות והזמן עד למענה הראשון של הנציג.
  6. כיול לפי לוגים: מסירים הפעלות שווא ומוסיפים ניסוחים שבהם הבוט ויתר מוקדם מדי.
  7. העברה לצוות: תקנון אסקלציה, הוראות לנציגים, לוח עם מדדי ההעברות.

תרשימים, תקנונים והוראות לנציגים

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

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

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

מקרה בוחן: העברת דיאלוג למערך התמיכה

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

מה שינינו בנקודת ההעברה

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

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

מדד לפני אחרי
שיעור הדיאלוגים שנסגרו בלי נציג 38% 71%
הזמן עד למענה האנושי הראשון 6 דק' 1.5 דק'
שאלות הבהרה בפתח השיחה 2–3 0–1
פניות לנציג במשמרת 34 19

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

מה לעשות אם הבוט העביר דיאלוג בלי הקשר?

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

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

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

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

ספקות טכניים נפוצים בנוגע להעברת הדיאלוג

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

מה יקרה אם הנציג לא זמין?

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

מתי הבוט צריך להעביר את הדיאלוג?

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

האם זה ישבור את תרחישי הבוט הקיימים?

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

איך בודקים את ההעברה לפני ההפעלה?

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

נדבר על המשימה שלכם להעברת דיאלוג לנציג

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

  • איך זה בנוי כיום: אילו ערוצים מחוברים (צ'אט באתר, מסנג'רים, טלפוניה), מי מקבל את הדיאלוג ראשון, ולפי איזה כלל מתחבר אדם.
  • כללי אסקלציה: «תקראו לנציג» מפורש, רמת ודאות נמוכה של התשובה, שליליות בהתכתבות, שאלה חוזרת, ניסיונות הבהרה שמוצו.
  • מה הולך לאיבוד בהעברה: היסטוריית ההודעות, שדות הפנייה שנאספו לאורך הדיאלוג, ניסיונות פתרון קודמים — מראים איזה מערך צריך להגיע לעמדת הנציג.
  • ייצוא התכתבויות אמיתיות עם אסקלציות: דרכן רואים איפה ההעברה נקרעת, כמה דיאלוגים הבוט סוגר ואילו תרחישים הנציג בכל זאת קורא עד הסוף ביד.
  • נקודות אינטגרציה: מערכת רישום הפניות, תור הנציגים, ערוץ ההתראות, הרשאות גישה לנתונים.
  • מגבלות: דרישות לאחסון ולאנונימיזציה של ההתכתבות, תקנון שעות העבודה והעברת הדיאלוג בין משמרות.
  • תפקידים: מי אחראי לכללי האסקלציה, מי מקבל את התוצאה, מי מלווה את הפתרון בתפעול.

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