בן דוד שעונה בטלפון "כן, בטח נגיע" הוא לא אישור הגעה. הוא רגע שנרשם בראש של מישהו — לא מתועד, לא מתוארך, ולא ניתן לספירה — עד שהקייטרינג כבר סגור ומתברר שאף אחד לא באמת ידע כמה מנות להזמין.
ההבדל בין "אמרו שיבואו" לבין רשומה עם תשובה מתוארכת בבסיס נתונים הוא לא סמנטי. זה ההבדל בין לתכנן קייטרינג וישיבה לפי תחושת בטן, לבין לתכנן לפי ספירה שאפשר לסמוך עליה. מי שמתכנן לפי התחושה משלם על זה — במנות שלא נאכלות, בכיסאות ריקים, ולפעמים בכיוון ההפוך: אורח אמיתי שלא מצא מקום כי מישהו "בטח" ויתר.
התשובה "כן" צריכה להיות שדה, לא זיכרון
כשמערכת ניהול אורחים לא שומרת תשובת RSVP כערך מובנה, כל תשובה נשארת אצל מישהו — לא במסד נתונים. זה נשמע כמו פרט טכני זניח, אבל הוא בדיוק הפער שגורם למפיקים לתכנן קייטרינג לפי הרגשה. Greenvelope, פלטפורמת RSVP שבחנה את הנתונים שלה על פני 70,624 אירועים ו-5.5 מיליון הזמנות בדוח RSVP Response Rate Benchmarks, מצאה שיעור תשובה חציוני של 85.3% בכלל האירועים — ובחתונות ספציפית, 88.9% מהמוזמנים עונים בכלל, כאשר 80.9% מהתשובות הן "כן". המספרים האלה קיימים כי הפלטפורמה שמרה כל תשובה כרשומה נספרת. בלי שדה מובנה אין דוח כזה — יש רק תחושה של המארגן לגבי מי "בטח יבוא".
"אולי" ו"עדיין לא ענה" הם לא אותו דבר
גם כשמערכת כן שומרת RSVP, יש הבדל מהותי בין תשובה מהוססת לבין שתיקה מוחלטת — ושני המצבים האלה נוטים להיבלע יחד לתוך "לא כן", מה שמוחק מידע חשוב על היכן בדיוק עומד כל אורח בתהליך. מבנה נתונים שמפריד בין השניים — תשובת "אולי" מפורשת מול היעדר תשובה לחלוטין — מאפשר לראות בזמן אמת כמה מקומות כבר מאושרים לגמרי, כמה תלויים באוויר, וכמה פשוט לא נענו. זו לא רק נוחות תצוגה: זה ההבדל בין להזמין קייטרינג לפי מספר שכולל ניחושים, לבין להזמין לפי שלוש קבוצות נפרדות שאפשר להחליט לגביהן בנפרד.
רשימת המוזמנים היא לא רשימת הבאים
אורח שנוסף לרשימת המוזמנים — או שורה שיובאה מקובץ אקסל של רשימת תפוצה ישנה — הוא לא הרשמה. הוא שם. ההבדל הזה חייב להישמר במבנה הנתונים, אחרת כל "רשימת אורחים" היא בפועל ערבוב של אנשים שהתחייבו עם אנשים שרק הוזמנו להתחייב. שורה שמקורה בייבוא מקובץ, ולא בפעולה אקטיבית של האורח או הצוות, לא אמורה להיספר באף שער כמות — היא שלד שנוצר כדי שהשם יופיע ברשימה, לא אישור שאפשר לתכנן לפיו קייטרינג. באותו אופן, מוזמן שנוסף לרשימה מאושרת מתחיל תמיד במצב "טרם נרשם": חברות ברשימה ואישור הגעה בפועל הם שני מצבים נפרדים, לא שני כינויים לאותו מצב.
קיבולת אירוע נמדדת בשני שערים נפרדים
קיבולת אירוע היא לא מספר אחד — היא שני מספרים נפרדים שעונים על שתי שאלות שונות. השאלה הראשונה היא "כמה ראשים נרשמו בסך הכול", והתשובה שלה נספרת לפי סכום הכרטיסים ולא לפי מספר השורות — כי משפחה של ארבעה יכולה להירשם בשורה אחת עם ארבעה כרטיסים, ומי שסופר שורות פשוט טועה בקיבולת. השאלה השנייה, החדה יותר, היא "כמה ראשים אישרו הגעה בפועל" — ולה יש שער נפרד לגמרי, שסופר כרטיסים רק מתוך שורות שבהן שדה ה-RSVP מסומן כ"כן". אלה שני מונים עצמאיים: אפשר להיות מלא ב"נרשמו" ורחוק ממלא ב"אישרו", וההבדל ביניהם הוא בדיוק הפער שבין רשימת אורחים לרשימת אורחים שבאמת יגיעו.
מה שהופך מכסה כזו לגדר אמיתית ולא רק למספר על המסך הוא מתג נפרד שקובע אם הרשמות חדשות נחסמות בפועל כשמגיעים לתקרה — בלעדיו, המכסה היא תצוגה בלבד. וכשהמכסה כן חוסמת, כל הרשמה שנדחתה לא נעלמת: היא נכנסת לרשימת המתנה עם סיבה מפורשת — מלא, מכסת אישורים מלאה, או אירוע סגור — כך שיש תיעוד של מי נשאר בחוץ ולמה, ולא רק תחושה שמישהו התלונן.
מפת המצבים, בקצרה
| מצב האורח | מה זה אומר בפועל | נספר בשער הראשי (רשומים) | נספר בשער האישורים (RSVP=כן) |
|---|---|---|---|
| שורה שיובאה מאקסל | שלד לרשימה, לא הרשמה | לא | לא |
| מוזמן ברשימה מאושרת | טרם נרשם | לא | לא |
| נרשם דרך טופס/עמוד | שורה עם כרטיסים | כן | לא (עד שיענה) |
| ענה "כן" | RSVP=כן, עם תאריך ומקור תשובה | כן | כן |
| ענה "אולי" | RSVP=אולי, נספר בנפרד | כן | לא |
| ענה בטלפון דרך מוקד | אותו נתיב כתיבה כמו תשובה מהאתר | כן | כן, אם התשובה "כן" |
תשובה בטלפון היא לא פחות אמינה — אם היא נכתבת לאותו מקום
הבעיה במקור אף פעם לא הייתה הטלפון עצמו. "כן, בטח נגיע" בטלפון בעייתי כי הוא נשאר אצל מי שענה לטלפון — לא כי שיחת טלפון פחות אמינה מקליק על קישור. מוקד אישורי הגעה טלפוני שמכריח כל שיחה לנחות על אחת מכמה תוצאות מוגדרות מראש — כן, לא, אולי, אין מענה, בקשת חזרה, מספר שגוי — וכותב את התוצאה דרך אותו נתיב כתיבה שמשמש תשובת RSVP מהאתר, סוגר בדיוק את הפער הזה. השורה מקבלת תיוג של מקור התשובה — צוות, מוקד, האורח עצמו או בוט — יחד עם תאריך ושעה מדויקים של הרגע שבו נענתה. שיחת טלפון הופכת לשדה נספר, בדיוק כמו קליק על קישור, במקום להישאר משפט שמישהו יזכור, או לא, בישיבת התיאום עם הקייטרינג.
הפער הזה לא ייחודי לישראל — הוא פשוט יקר בכל מקום
הפער בין רשימת שמות לבין ראשים שבאמת מגיעים הוא בעיה מוכרת בתעשיית האירועים גם מחוץ לישראל. סיקור בענף האירועים הבריטי, ב-Event Industry News, על אומדן תעשייתי לגבי חתונות ובריתות זוגיות בבריטניה, מדבר על פוטנציאל של מעל 130 מיליון ליש"ט בבזבוז מזון — ואפילו אם לוקחים בזהירות רק מחצית מהאומדן הזה בחשבון, עדיין מדובר בעשרות מיליוני ליש"ט, כאשר הערכת יתר של מספר האורחים, כלומר תכנון קייטרינג לפי מספר שנשען על תשובות רכות, מוזכרת כאחד הגורמים. זה נתון בריטי ולא ישראלי, וסדר גודל ולא מספר מדויק — אבל הכיוון שהוא מצביע עליו ברור: כשהמספר שמתכננים לפיו לא נשען על שדה אמיתי, מישהו משלם על ההפרש, בדרך כלל בכסף שכבר יצא על אוכל שלא הוגש.
רוצים לבדוק איך רשימת האורחים לאירוע הבא שלכם נראית כשכל "כן" הוא שדה מתוארך ולא זיכרון של מישהו בטלפון? דברו איתנונפתח בטאב חדש ונעבור יחד על שני שערי הקיבולת שמתאימים למספרים שלכם.

