אישורי הגעה ב-SMS וב-WhatsApp: ספירה אמינה של כן, לא ואולי
חזרה לבלוג
automation·5 בספטמבר 2026·5 דק' קריאה·מאת יהונתן סעדיה

אישורי הגעה ב-SMS וב-WhatsApp: ספירה אמינה של כן, לא ואולי

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

עיקרי הדברים

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

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

מה נדרש כדי שספירה תהיה אמינה

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

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

אוצר המילים של התשובות, והזנב הארוך שאחריו

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

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

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

למה "אולי" אינו קטגוריה שלישית?

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

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

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

תשובה שהשתנתה: מי מנצח

אורח שאישר ואז ביטל, או ביטל ואז אישר, הוא מקרה שכיח ולא חריג. הכלל הוא לצבור ולא לדרוס:

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

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

קשור: תזכורות לפגישות והפחתת אי-הגעה, SMS מול WhatsApp מול מייל לתזכורות, ספקי SMS בישראל - השוואה.

אותו אדם ענה גם ב-SMS וגם ב-WhatsApp - מה נספר?

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

  • מפתח הזיהוי הוא מספר הטלפון המנורמל. מספר ישראלי שנשמר פעם כ-050-1234567 ופעם כ-+972501234567 הוא שני אורחים שונים בכל דוח, עד שמנרמלים אותו לפורמט E.164 בכניסה.
  • בית אב אינו מספר טלפון. בני זוג עם שני מכשירים שקיבלו שתי הזמנות ייצרו ספירה כפולה אלא אם הן קשורות למזהה הזמנה אחד.
  • תשובה שהגיעה בערוץ שלא נשלחה בו הזמנה היא עדיין תשובה. אורח שקיבל SMS ובחר להשיב ב-WhatsApp למספר העסקי אינו טועה, והמערכת צריכה לשייך אותו לפי מספר הטלפון.
  • בשני ערוצים באותה דקה עם תשובות סותרות - נדיר, אבל קורה כשנשלחו שתי הודעות. במקרה כזה עדיף לסמן להכרעה אנושית מאשר לבחור לפי חוק שרירותי.

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

התאמת המספר הסופי: מה חייב להסתכם

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

מדדמספרהערה
הזמנות שנשלחו380הבסיס לכל אחוז
השיבו בפועל288209 בכפתור, 79 בטקסט חופשי
טקסט חופשי שפוענח אוטומטית61מתוך 79
הועברו לתור אנושי18אלה שנשארו
השיבו בשני ערוצים23נספרו פעם אחת לפי התשובה המאוחרת
מגיעים214הזמנות, לא אנשים
לא מגיעים74הזמנות
ללא תשובה במועד הסגירה92380 פחות 288
מספר אורחים שהוצהר402סכום המניין מתוך 214 ההזמנות המאשרות

שתי בדיקות סוגרות את הדוח: 214 ועוד 74 ועוד 92 שווה 380, ו-209 ועוד 79 שווה 288. אם אחת מהן אינה מסתכמת, יש רשומה שנספרת פעמיים או תשובה שאיבדה שיוך - וזה תמיד ניתן למצוא, כי הטקסט המקורי נשמר.

מקורות

#RSVP#event responses#SMS#WhatsApp#reply parsing#אוטומציה

שאלות נפוצות

כדאי לשלוח לינק לטופס במקום לבקש תשובה בהודעה?

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

מה עושים עם תשובות שמגיעות אחרי מועד הסגירה?

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

עד כמה אפשר לסמוך על פענוח אוטומטי של טקסט חופשי?

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

איך מונעים תזכורת שנשלחת למי שכבר ענה?

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

להמשך קריאה

שירות רלוונטי

WhatsApp Cloud API

תבניות, אינבוקס דו-כיווני ותזכורות על ה-API הרשמי של Meta.

מידע נוסף →←

על הכותב

יהונתן סעדיה

מפתח פרילנסר לאוטומציה, אתרים ו-MVP

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

בוא נעבוד יחד

יש לך פרויקט דומה?

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