בניית בוט וואטסאפ לעסק: מה צריך להחליט לפני שמתחילים

בחרו תפקיד אחד לבוט

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

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

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

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

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

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

תסריט מלא: בקשת הצעת מחיר להתקנה

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

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

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

חלון 24 השעות, תבניות והסכמה

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

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

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

מעבר לנציג הוא שינוי מצב, לא משפט בשיחה

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

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

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

מה מותר ל-AI לעשות בפועל

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

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

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

בדיקת שיחות: לא רק ״שלום״ ו״תודה״

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

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

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

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

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

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

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

בדקו את מסלול החיבור

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

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

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

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

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

חיבור ל-CRM ומניעת טעויות

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

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

רשימת בדיקות לפני הפעלה

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

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