איך מוסיפים יכולות AI ל-SaaS שכבר בניתם

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

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

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

למה רוב יכולות ה-AI המוברגות נכשלות

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

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

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

תתחילו מהשאלה, לא מהמודל

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

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

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

דרך מהירה לדרג את מועמדי ה-AI שלכם

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

1. 1
   ערך: כמה המשתמשים רוצים את זה?

   תנו 5 אם זה עונה על בקשה שאתם שומעים כל הזמן ויחסוך למשתמשים זמן בצורה גלויה. תנו 1 אם זה "נחמד שיהיה" שמישהו בצוות חלם עליו.
2. 2
   סובלנות: מה קורה כשזה טועה?

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

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

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

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

בנו את זה לתוך המוצר, לא לצידו

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

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

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

שמרו אדם בלולאה — ועשו את זה ברור

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

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

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

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

המציאות ההנדסית שאיש לא מזהיר אתכם עליה

הדמו הוא ה-20% הקלים. להביא יכולת AI למצב מוכן לייצור בתוך SaaS אמיתי זה ה-80% הנותרים, וזו בעיקר עבודה לא זוהרת שיש לה מעט קשר למודל עצמו. כדאי לדעת את זה מראש, כדי שאב טיפוס שעובד לא יטעה אתכם להבטיח תאריך השקה שתפספסו.

צנרת נתונים והקשר

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

עלות והשהיה

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

כישלון והנתיב הלא-נעים

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

לתמחר את זה: יכולת, תוסף, או כל הסיפור?

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

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

השיקו דבר קטן אחד, ואז טפסו

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

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

שאלות נפוצות