ווייספלואו / Voiceflow

מה זה ווייספלואו ואיך בונים בו שיחה?

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

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

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

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

הפיצ'רים המרכזיים של ווייספלואו

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

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

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

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

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

כמה זה עולה?

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

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

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

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

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

ווייספלואו מול הדרכים האחרות לבנות בוט

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

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

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

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

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

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

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

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

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

# דוח שבועי של השיחות שנכשלו, כדי שהתיקון יהיה מבוסס ולא ניחוש
import os
import json
import time
from collections import Counter
import requests

BASE = "https://api.voiceflow.com/v2"
PROJECT = os.environ["VF_PROJECT_ID"]
HEAD = {"Authorization": os.environ["VF_API_KEY"]}
WEEK = 7 * 24 * 3600

# סימנים לכך שהשיחה לא הסתיימה בפתרון. אלה מה שמחפשים בתמליל
FAILURE_MARKERS = (
    "לא הבנתי", "אפשר לנסח מחדש", "נסה שוב",
    "אין לי תשובה", "מעביר לנציג",
)
ABANDON_TURNS = 2          # שיחה שנגמרה אחרי שתי הודעות היא כמעט תמיד נטישה

def fetch_transcripts(since):
    r = requests.get(BASE + "/transcripts/" + PROJECT,
                     headers=HEAD, params={"startDate": since}, timeout=90)
    r.raise_for_status()
    return r.json()

def fetch_turns(transcript_id):
    r = requests.get(BASE + "/transcripts/" + PROJECT + "/" + transcript_id,
                     headers=HEAD, timeout=90)
    r.raise_for_status()
    return r.json()

def last_user_message(turns):
    # השאלה האחרונה שהמשתמש שאל לפני שהשיחה נעצרה היא המידע היקר ביותר
    texts = [t["payload"]["payload"].get("message", "")
             for t in turns if t.get("type") == "request"]
    return texts[-1].strip() if texts else ""

def classify(turns):
    body = " ".join(json.dumps(t, ensure_ascii=False) for t in turns)
    if any(marker in body for marker in FAILURE_MARKERS):
        return "no_answer"
    if len(turns) <= ABANDON_TURNS:
        return "abandoned"
    return "ok"

def run(now=None):
    since = int((now or time.time()) - WEEK) * 1000
    report = {"total": 0, "no_answer": 0, "abandoned": 0, "questions": Counter()}
    for item in fetch_transcripts(since):
        turns = fetch_turns(item["_id"])
        outcome = classify(turns)
        report["total"] += 1
        if outcome == "ok":
            continue
        report[outcome] += 1
        question = last_user_message(turns)
        if question:
            report["questions"][question[:80]] += 1
    top = report["questions"].most_common(15)
    out = {"total": report["total"], "no_answer": report["no_answer"],
           "abandoned": report["abandoned"], "top_unanswered": top}
    with open("weekly-triage.json", "w", encoding="utf-8") as f:
        json.dump(out, f, ensure_ascii=False, indent=2)
    return out

# שלושה כללים שהופכים את הדוח הזה לשיפור ולא לקובץ שנשמר ונשכח
# שלב 1: לתקן שתי שאלות בשבוע ולא חמש עשרה. תיקון מדוד עדיף על שכתוב
# שלב 2: לקרוא חמש שיחות במלואן בכל שבוע. המספרים מראים מה, התמליל מראה למה
# שלב 3: למדוד את אחוז השיחות שהסתיימו בפתרון לפני התיקון ואחריו, אחרת אין ידיעה

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

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

חסרונות שאתם צריכים לדעת

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

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

היתרונות שעושים את ווייספלואו שווה

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

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

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

מתי לבחור ווייספלואו ומתי לבחור פתרון פשוט?

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

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

שאלה 2: כמה שיחות בחודש?
    עד 200               -->  לבדוק אם בכלל צריך בוט
    200 עד 5000          -->  החבילה המקצועית
    מעל 5000             -->  חבילה גבוהה, ולבדוק עלות לשיחה

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

שאלה 4: הבוט הוא המוצר?
    לא, ערוץ שירות       -->  פלטפורמה, בלי לפתח
    חלקית                -->  פלטפורמה עם קריאות למערכות
    כן, לב המוצר         -->  פיתוח עצמאי

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

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

השורה התחתונה: האם ווייספלואו שווה?

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

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

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

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