סינון לידים בוואטסאפ עם AI צריך להסתיים במידע שהצוות יכול לעבוד איתו: מה הלקוח מבקש, אילו פרטים כבר נמסרו ומה הפעולה הבאה. מספר הודעות גבוה אינו מדד להצלחה. אם הסוכן ממשיך לשאול אחרי בקשה לדבר עם אדם, או יוצר רשומה בלי פרטי קשר תקינים, השיחה יכולה להישמע טובה והתהליך עדיין להיכשל.
במדריך הזה נבנה מסלול מהודעה נכנסת עד הכנה לרשומה ב־CRM. הדוגמאות בדיוניות; לא נשלחו הודעות לאנשים ולא נוצרו פניות במערכת לקוחות אמיתית. אפשר להוריד את חומרי התרגול ולבדוק את כללי ההמשך לפני חיבור לערוץ פעיל.
מגדירים מה צריך לדעת לפני העברה לצוות
בעסק שמציע פיתוח, אוטומציה ולימוד, לא צריך לפתוח בשאלון ארוך. שתי שאלות מועילות הן מה הלקוח רוצה שיקרה ואילו מערכות משתתפות בתהליך. אחריהן בודקים אם יש דרך לחזור אליו, ואם הוא מעוניין בהמשך אוטומטי או בשיחה עם אדם.
| שדה | מקור המידע | מה עושים כשהוא חסר |
|---|---|---|
| סוג השירות | הבקשה בשיחה | שואלים מה התוצאה הרצויה |
| תיאור הצורך | ניסוח הלקוח | מבקשים דוגמה קצרה |
| פרטי קשר | מידע שנמסר או שזמין בערוץ כדין | מסמנים חסר; לא ממציאים |
| מערכות משתתפות | תשובת הלקוח | משאירים שדה להשלמה |
| הפעולה הבאה | כללי התהליך | בוחרים השלמה, בדיקה או העברה לאדם |
המודל יכול להציע את סוג השירות, אבל השרת צריך לבדוק שהערך שייך לרשימה המותרת. פרטי קשר ותקציב אינם שדות להשלמה יצירתית. גם כאשר מספר זמין מהערוץ, יש להבחין בינו לבין מספר חלופי שהלקוח מסר לצורך חזרה.
שלושה מסלולי שיחה
פנייה עם מידע מספיק. לקוח כותב שהוא צריך מערכת לניהול הזמנות, מסביר שההזמנות צריכות להופיע לצוות עם סטטוס, ומוסר מספר לחזרה. בתרגיל נוצר אובייקט עם service מסוג development, מספר בפורמט אחיד וסטטוס ready_for_review. המשמעות היא שהפנייה מוכנה לבדיקת הצוות; עדיין לא נשלחה הצעת מחיר.
פנייה שחסר בה מידע. לקוח מבקש אוטומציה לפניות, אבל עדיין אינו יודע באילו מערכות יעבוד ואינו מוסר מספר. התוצאה בתרגיל היא needs_information. השאלה הבאה צריכה להשלים פרט נחוץ, לא לחזור על כל מה שכבר נאמר. אפשר לשמור טיוטה פנימית ולציין במפורש שהפנייה עדיין אינה מלאה.
בקשה לדבר עם אדם. כשהלקוח כותב ״אני רוצה לדבר עם בן אדם״, מסלול הסיווג מסתיים ב־human_requested. אין צורך לדרוש ממנו קודם לענות על עוד שלוש שאלות. לצוות עוברים ההודעה והמידע שכבר נאסף, כדי שלא יצטרך להתחיל מחדש.
שלושת המסלולים, ההודעות והשדות הצפויים נמצאים בקובץ השיחות לתרגול. אלה דוגמאות לתכנון השדות והפעולה הבאה, ולא ציוני הצלחה של מודל או הוכחה לחיבור פעיל ל־WhatsApp ול־CRM.
החיבור לערוץ ולמערכת הלקוחות
בחיבור דרך WhatsApp Business Platform, אירועים נכנסים מתקבלים באמצעות webhook. יש להבחין בין תוכן הודעה לבין אירועי סטטוס של הודעה. מבנה ההודעות מתועד באוסף ה־API הרשמי של Meta. בדקו את התיעוד העדכני של סוג האירוע והגרסה שבה אתם משתמשים; אין להסתמך על שם שדה משוער.
בתוך המערכת שלכם, האירוע עובר בדיקת מקור, זיהוי כפילות, חילוץ שדות ובדיקת תוכן. רק לאחר מכן מכינים או יוצרים רשומת CRM. החיבור הסופי תלוי במערכת שנבחרה: אילו שדות היא דורשת, אילו הרשאות היא מאפשרת וכיצד היא מדווחת על שמירה מוצלחת. אין מחבר רשמי מובטח לכל מערכת.
לפני הפעלת הודעות יוצאות יש לבדוק גם את מדיניות WhatsApp Business החלה על השיחה ועל סוג ההודעה. המדריך מתמקד בטיפול בפנייה נכנסת; הוא אינו מדריך לשליחה המונית או לעקיפת הגבלות. ההבדל בין בחירת ערוץ לבין בניית הסוכן מוסבר במדריך סוכן AI בוואטסאפ.
מדריכים ועדכונים לעבודה עם AI
מדריכים בעברית, עדכוני כלים ודוגמאות לעבודה עם בינה מלאכותית.
איך מונעים רשומה כפולה
בקשה יכולה להגיע שוב בגלל ניסיון חוזר. שמירת אותו טקסט פעמיים אינה דרך לזהות כפילות: לקוח יכול לשלוח שני משפטים זהים בכוונה. השתמשו במזהה אירוע או במפתח בקשה שמייצג את הפעולה המסוימת, ושמרו את הקשר בינו לבין הרשומה שנוצרה.
בדוגמת הקוד המקומית שלנו, ניסיון חוזר עם אותו מפתח ואותם פרטים מחזיר את מזהה הרשומה הקיימת. ניסיון להשתמש באותו מפתח עם פרטים שונים מחזיר התנגשות. כשל בשמירה אינו מוסיף רשומה ואינו צורך את המפתח, כדי שאפשר יהיה לנסות שוב. הקוד ופלטי הבדיקות נכללים בערכת התרגול להורדה.
ב־CRM חיצוני, הודעת שגיאה לא תמיד מוכיחה שהכתיבה לא התבצעה. למשל, החיבור יכול להיפסק אחרי שהשרת שמר. לכן לפני ניסיון נוסף צריך לבדוק את מזהה הבקשה או הרשומה בצד המערכת, לפי היכולות שלה.
בדקנו גם את שלושת מסלולי השיחה מול מאגר התרגול המקומי, לאחר מיפוי ידני של השדות. פנייה מלאה נשמרה רק לאחר אישור; במסלול שחסר בו מידע ובבקשה לאדם לא נוצרה רשומה. ניסיון חוזר באותו מזהה החזיר את הרשומה הקיימת. דוח הרשומות וההחלטות מציג את התוצאות. זו בדיקת ניתוב ושמירה של שדות שנבדקו מראש, ללא חיבור לערוץ WhatsApp.
כאשר מגיעה הודעה חדשה ומספר הטלפון מתאים לרשומה קיימת, התרגיל מסמן התאמה אפשרית לבדיקה. הוא אינו מאחד לקוחות אוטומטית: מספר עשוי לשמש יותר מאדם אחד. במערכת אמיתית צריך להגדיר איך מזהים לקוח קיים ומתי מוסיפים פנייה חדשה לאותו לקוח, בלי לאבד את היסטוריית השיחה.
להפוך שיחה משתנה לפנייה שימושית
דוגמה: פנייה שמתחילה בלימוד וממשיכה לפיתוח
לקוחה כותבת שהיא מחפשת שיעור פרטי כדי לבנות כלי לעסק. במהלך השיחה מתברר שהיא רוצה שהכלי יתחבר למערכת ההזמנות ויהיה בשימוש של כמה עובדים. הסוכן לא צריך למחוק את בקשת הלימוד ולהכריז שהיא רוצה פרויקט פיתוח. אפשר לשמור את שני הצרכים ולשאול האם המטרה היא ללמוד לבנות בעצמה, לקבל מערכת מוכנה או לשלב בין האפשרויות. ההבדל משפיע על השיחה שהצוות ינהל בהמשך.
להכין תקציר שהנציג יכול לפעול לפיו
התקציר צריך לכלול את התוצאה שהלקוחה מבקשת, המערכות שהזכירה והשאלה שעדיין פתוחה. אין צורך להעתיק כל הודעת נימוס לרשומה המרכזית. לצד הסיכום אפשר לשמור הפניה לשיחה המקורית בהתאם להרשאות. כך הנציג מקבל תמונה קצרה, אבל יכול לבדוק ניסוח חשוב לפני שהוא חוזר ללקוחה. סיכום שמכיל רק ״מתעניינת ב־AI״ אינו מספיק להכנה מקצועית.
לא להפוך מידע חסר לפסילה
לקוח שאינו יודע לנקוב בתקציב עשוי עדיין להתאים לשיחת אפיון. הגדירו אילו פרטים נדרשים כדי להמשיך ואילו אפשר לברר עם איש מקצוע. השדה ״לא צוין״ צריך להישאר מובחן מ״לא מתאים״. אם יש תנאי סף אמיתי, כמו שירות שאינו מוצע, הסבירו אותו בשפה ברורה והציעו המשך רלוונטי אם קיים. הסוכן אינו צריך להמציא ציון התאמה כדי למלא את המסך.
לשמור את הסיבה לפעולה הבאה
לצד ready_for_review אפשר לשמור הסבר קצר: הלקוחה תיארה צורך וניתן לחזור אליה, אך טרם הוחלט על מסלול לימוד או פיתוח. ההסבר עוזר לצוות להבין מדוע הפנייה הועברה אליו. הוא גם מאפשר לבדוק בדיעבד אם הכללים שימושיים. אין צורך לנבא סיכוי לרכישה; עדיף לתעד מה ידוע ומה צריך לברר כדי לקדם שיחה מתאימה.
לקבוע אחריות לאחר יצירת הרשומה
פתיחת ליד היא תחילת העבודה של הצוות. הגדירו מי רואה פנייה חדשה, כיצד היא משויכת ומה קורה כשאיש הצוות אינו זמין. אם כל ליד נפתח בלי בעלים, החיבור הטכני יכול לעבוד והלקוח עדיין לא יקבל מענה. כדאי שהרשומה תכלול מצב ברור ופעולה הבאה, ושיהיה אפשר לראות פניות שממתינות לטיפול מעבר לזמן שהעסק קבע לעצמו.
בדקו גם את השיחה לאחר שהנציג חזר ללקוח. אם הסוכן ממשיך לשאול שאלות ישנות, נוצרת חוויה מבולבלת. עדכון מצב הטיפול צריך להשפיע על האוטומציה. אפשר להחזיר אותה לפעולה רק לפי כלל מוגדר, למשל כשהנציג מסיים את השיחה ומבקש מהמערכת להמשיך באיסוף פרט מסוים. המודל אינו אמור להסיק לבדו שהנציג סיים משום שלא נשלחה הודעה כמה דקות.
מדידה שמחברת שירות למכירה
לצד תוצאות המכירה, קראו כמה פניות שלא הבשילו. אם אנשים חוזרים ושואלים מה כלול בשירות, ייתכן שחסר הסבר בדף שאליו הם הגיעו. אם הסוכן אסף את כל הפרטים אך הצוות חזר אחרי זמן רב, השיפור הדרוש הוא בתהליך הטיפול. כך נתוני השיחה משמשים גם לשיפור השירות והאתר, מעבר לספירת לידים.
המדדים המועילים הם שיעור הפניות עם שדות מלאים, שיעור ההעברה לאדם, רשומות כפולות, שגיאות שמירה וזמן עד טיפול ראשון. כדי לבדוק איכות עסקית, צריך גם לדעת אילו פניות התקדמו לשיחה מתאימה ולעסקה. לחיצה או שיחה ארוכה לבדן אינן המרה עסקית.
לכל רשומה שמרו מקור פנייה והיסטוריית שינוי מתאימה. אל תציגו בסיכום הבטחה שהסוכן לא נתן או תקציב שהלקוח לא מסר. במידת הצורך הציגו לצוות גם את ההודעה שממנה חולץ השדה.
שאלות נפוצות
האם חייבים שהסוכן ייצור את הליד אוטומטית?
לא. אפשר להתחיל בטיוטה שמאושרת בידי הצוות, למדוד את איכות השדות ורק אחר כך להרחיב את הסמכות. ההחלטה תלויה במחיר של טעות וביכולת לתקן אותה.
מה לעשות כשהלקוח משנה את הבקשה באמצע השיחה?
מעדכנים את הטיוטה ושומרים את השינוי. אל תיצרו ליד חדש רק משום שסוג השירות השתנה. אם כבר נוצרה רשומה, צריך להגדיר מראש איך ומתי מעדכנים אותה.
איך בוחרים את היקף הפיתוח?
התחילו מתהליך אחד ומהמערכות שכבר בשימוש. מדריך עלות פיתוח סוכן יעזור להשוות היקפים, ומדריך סוכן AI לעסק יעזור להגדיר תוצאה. רוצים לחבר את הפניות לתהליך העבודה שלכם? בואו נדבר על השיחה, השדות ומערכת הלקוחות.