יצירת צ'אטבוטים מבוססי בינה מלאכותית על Typebot: הטמעת פלטפורמת קוד פתוח

מדוע הבוט ב-Typebot נשבר לאחר ההשקה

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

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

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

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

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

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

מה נותן היישום: אפקט בכמויות מדידות

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

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

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

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

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

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

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

מצבי עבודה של Typebot: השוואת אפשרויות פריסה

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

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

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

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

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

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

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

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

ארטיפקטים של היישום: סכמות, קונפיגורציות, נהלים

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

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

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

מקרה בוחן: צמצמנו פי שלושה את שיעור הפניות ללא מענה

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

מה שינינו

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

מה קרה בחודש העבודה הראשון

שיעור הפניות המוחמצות ירד מ-19% ל-6%, כ-70% מהשיחות נסגרות בלי מעורבות אדם. התשובה הראשונה מגיעה כעת תוך שניות במקום 40 דקות, ולכן פניות בלילה ובסופי שבוע הפסיקו ללכת לאיבוד. בשעת שיא יש לנציג 4-5 שיחות במקביל במקום 12 — הזמן שהתפנה עבר למקרים מורכבים שנדחו קודם.

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

במה שונה פריסה על שרת משלכם מהענן?

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

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

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

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

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

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

ספקות טכניים ומגבלות הפלטפורמה

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

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

כיצד מופרדות הרשאות הגישה?

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

מה קורה בעת עדכון הפלטפורמה?

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

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

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

כיצד אתם בודקים את איכות תשובות הבוט?

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

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

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

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

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