איך הוספנו עוזר AI לפלטפורמת SaaS — בלי לשבור אותה

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

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

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

המצב: שתי בעיות בתחפושת אחת

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

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

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

צמצום למשהו שנוכל לסיים

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

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

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

האב-טיפוס הראשון שבנינו — ומחקנו

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

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

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

מה בנינו בפועל

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

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

עיגון לפני חוכמה

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

העברה חלקה

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

מודע למי ששואל

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

1. 1
   ניקינו ובנינו מבנה לבסיס הידע

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

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

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

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

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

התוצאות — וזו שהפתיעה אותנו

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

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

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

מה היינו אומרים לצוות הבא

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

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

שאלות נפוצות