הטמעת בוט קולי מבוסס בינה מלאכותית לאישור הזמנות

בוט קולי לאישור הזמנות: היכן נשבר התהליך

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

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

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

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

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

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

תרחישי אישור אוטומטי: האפקט במספרים

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

• שיעור ההזמנות המאושרות. בשיא, חיוג ידני לא מדביק את הזרימה: הנציגים סוגרים את הפריטים הראשונים בתור, והשאר תלויים עד לפסק זמן. הבוט מחייג לכל הרשימה — עלייה של 20–25 נקודות אחוז ובלי צניחה בשעות עומס.
• הזמן עד לאישור. השיחה יוצאת דקה אחרי ביצוע ההזמנה, כשהלקוח עוד ליד הטלפון, ולא אחרי שעה כשהנציג התפנה. השהיה קצרה — היענות גבוהה יותר.
• העומס על הנציגים. מקרים טיפוסיים — הזמנה במלאי, כתובת וזמן ללא שינוי — עוברים לאוטומט, אלו 60–70% מהפניות. הנציג נשאר עם דחיות, החלפות וסירובים.
• פניות חוזרות. הלקוח לא מתקשר «מה עם ההזמנה»: הסטטוס מאושר ונראה ב-Битрикс24. שיעור השיחות האלה יורד פי כמה ומפנה את אותו קו.
• סוג הסירובים שנעלם. הזמנות שנתקעו בלי אישור ובוטלו בגלל פסק זמן מפסיקות להיווצר כתופעה.

כל מדד אנחנו מתעדים בדוח אחד לפני ואחרי, ולכן הרחבת התרחישים נעשית לפי נתונים, ולא לפי תחושות.

מצבי חיוג: השוואת גישות והמגבלות שלהן

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

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

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

שלבי הטמעה: מביקורת שיחות ועד מסירת המשמרת

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

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

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

כללי ניתוב, תרחישים ותיעוד לפי התוצאות

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

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

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

מקרה בוחן: איך חיוג אוטומטי הפחית את העומס על המשמרת

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

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

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

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

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

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

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

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

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

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

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

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

מקרים מורכבים: קשר גרוע, דיאלקטים, סירוב לשיחה

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

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

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

האם הבוט יבין דיאלקט או מבטא חזק?

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

הלקוח מסרב לדבר עם הבוט — מה אז?

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

לאן מגיעה הזמנה שנויה במחלוקת?

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

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

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

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

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

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

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