תצפית על זמינות אצל ספק אינה התחייבות ללקוח. שלוש חותמות הזמן שאסור למזג, למה זמינות אינה בוליאנית, ואיך מנסחים את המסך כך שלא יבטיח מה שאין.
עיקרי הדברים
- זמינות שנצפתה היא עדות על מצב תצוגה, לא על מלאי פיזי ולא על יכולת אספקה.
- שלוש חותמות זמן שונות חייבות להישמר בנפרד: מתי הספק מצהיר שהנתון נכון, מתי אתם צפיתם בו, ומתי הוא הוצג למשתמש.
- זמינות אינה בוליאנית. אוצר המילים של schema.org מגדיר שנים-עשר מצבי זמינות שונים, וההבדל ביניהם משנה מה מותר לומר ללקוח.
- מתריעים על מעבר מצב, לא על מצב. פריט שנמצא "אזל" בכל בדיקה כבר לא חדשותי אחרי ההתראה הראשונה.
- כשלספק יש הזנה רשמית או ממשק - בקשו אותם. זהו המסלול שנשבר פחות, ולעיתים קרובות הספק פשוט לא נשאל.
תצפית על זמינות באתר של ספק אומרת שברגע מסוים הוצג שם סימון מסוים. היא אינה אומרת שהפריט שמור לכם, שהוא יישאר זמין עד שתזמינו, או שהוא יגיע בתאריך כלשהו. כל מסך שמתרגם תצפית כזו להבטחה ללקוח יוצר התחייבות שאיש לא נתן.
הפער בין תצפית לבין הבטחה
השרשרת בין "כתוב באתר של הספק שיש" לבין "הלקוח יקבל" מכילה לפחות חמישה מקומות שבהם הקשר נשבר:
- הנתון באתר הספק עצמו עשוי להיות מאוחסן במטמון ולא לשקף את המחסן ברגע זה.
- מלאי פיזי אינו מלאי זמין: חלקו משויך להזמנות פתוחות של לקוחות אחרים.
- ספק עשוי להציג "זמין" עבור פריט שהוא מזמין מיצרן בעצמו לפי דרישה.
- הפריט יכול להימכר בין רגע הצפייה שלכם לרגע ההזמנה שלכם.
- תנאי הזמנת מינימום, אזור משלוח או מדיניות אשראי יכולים למנוע את ההזמנה גם כשיש מלאי.
המונח המקצועי לצד השני של הפער הוא זמינות להתחייבות: הכמות שהמערכת מוכנה להבטיח ללקוח לאחר שנוכו שיוכים קיימים. תצפית חיצונית לעולם אינה מחשבת אותה, מפני שהיא אינה רואה את ההזמנות הפתוחות של הספק. זה ההסבר המלא לכותרת: מתריעים - ולא מבטיחים.
שלוש חותמות זמן שאסור למזג
| חותמת | מי קובע אותה | מה היא אומרת | מה קורה כשהיא נעלמת |
|---|---|---|---|
source_as_of | הספק, אם הוא מצהיר עליה | לאיזה רגע הנתון של הספק נכון | אתם מייחסים לספק עדכניות שלא הצהיר עליה |
observed_at | אתם | מתי הבדיקה שלכם רצה בפועל | אי אפשר לדעת אם הנתון בן דקה או בן יומיים |
shown_at | המסך | מתי המשתמש ראה את הערך | לקוח רואה ערך ישן ומניח שהוא עכשווי |
changed_at | המערכת | מתי הערך השתנה לאחרונה מבחינתכם | אי אפשר להבדיל בין יציבות לבין קורא תקוע |
השורה השלישית היא זו שנופלת ראשונה בפועל. מסך שנטען פעם בבוקר ונשאר פתוח כל היום ימשיך להציג "זמין" גם אחרי שהמצב השתנה, מפני שאיש לא הגדיר שההצגה עצמה מתיישנת. הפתרון פשוט: לכל ערך זמינות במסך יש גיל מוצג, וכשהגיל חורג מהסף, הערך מוחלף בהודעה ולא נשאר על המסך.
למה "יש במלאי" אינו ערך בוליאני?
מפני שמצבי הזמינות הנפוצים אינם שניים. אוצר המילים הפומבי של schema.org, בגרסה 30.0 שפורסמה במרץ 2026, מונה שנים-עשר חברי ItemAvailability: BackOrder, Discontinued, InStock, InStoreOnly, LimitedAvailability, MadeToOrder, OnlineOnly, OutOfStock, PreOrder, PreSale, Reserved, SoldOut.
ההבחנות האלה אינן אקדמיות. Discontinued פירושו שאין טעם להמתין, BackOrder פירושו שכן, MadeToOrder פירושו שזמן האספקה נקבע רק בהזמנה, ו-InStoreOnly פירושו שהזמינות קיימת אך לא בערוץ שאתם מזמינים דרכו. מיפוי של כל אלה ל"כן/לא" מוחק בדיוק את המידע שמכתיב מה אומרים ללקוח.
לכן שומרים שני שדות ולא אחד: raw_status - הטקסט כפי שהופיע אצל הספק, ו-mapped_status - הערך שמיפיתם אליו. כשמיפוי מסתבר כשגוי, השדה הגולמי הוא מה שמאפשר לתקן אחורה במקום לנחש.
מה מותר לומר ללקוח לכל מצב
| מה נצפה | מה זה כנראה אומר | מה מותר לומר ללקוח | פעולה פנימית |
|---|---|---|---|
| מסומן זמין, נצפה לפני פחות משעה | סביר שניתן להזמין | "נצפה זמין אצל הספק היום בשעה 09:40" | אפשר להתחיל תהליך הזמנה |
| מסומן זמין, נצפה לפני יומיים | לא ידוע | לא להציג כזמין | לרענן לפני כל תשובה ללקוח |
| כמות מוצגת נמוכה | מלאי מתכלה, ייתכן שיווצר מחסור | לא לצטט את הכמות | להקדים הזמנה או למצוא מקור חלופי |
| אזל | אין כרגע בערוץ שנבדק | "אינו זמין כרגע אצל הספק שבדקנו" | לבדוק ספק חלופי, לרשום למעקב |
| הזמנה מוקדמת או ייצור לפי הזמנה | תאריך נקבע רק מול הספק | לא לצטט תאריך | לפנות לספק לקבלת מועד בכתב |
| הופסק ייצור | לא יחזור | לומר זאת מפורשות ולהציע חלופה | להסיר מהקטלוג ולהחליף |
השורה החשובה ביותר היא האחרונה בעמודת "מה מותר לומר": בשום מצב לא מצטטים תאריך אספקה שנגזר מתצפית. תאריך הוא מידע שמגיע מהספק בכתב, ומרגע שנמסר ללקוח הוא הופך להתחייבות מסחרית.
מתריעים על מעבר, לא על מצב
התראה על מצב מייצרת הודעה יומית זהה ומאבדת את תשומת הלב שלה תוך שבוע. התראה על מעבר מייצרת ידיעה. ארבעה מעברים ששווה להתריע עליהם:
- זמין ➜ אזל, על פריט שמופיע בהזמנות פתוחות שלכם.
- אזל ➜ זמין, על פריט שנמצא ברשימת המתנה.
- זמין ➜ הופסק ייצור, שדורש החלטת החלפה ולא רק רכש.
- ירידה חדה בכמות המוצגת מעל סף שהגדרתם, כשהספק מציג כמות בכלל.
שני מנגנונים מונעים ריצוד. הראשון הוא אישור כפול: משנים מצב רק אחרי שתי בדיקות רצופות שמסכימות, כדי שתקלה רגעית באתר הספק לא תיצור התראה. השני הוא השהיה: אחרי התראה על פריט, אין מתריעים עליו שוב במשך חלון זמן קבוע. בלי שני אלה, יום אחד של תקלות אצל הספק מייצר עשרות התראות שווא, וזו הדרך המהירה ביותר לכך שאיש לא יקרא את ההתראה הבאה.
חשוב לא פחות: התראה על מקור שקט. אם קורא של ספק לא הצליח לקרוא אף פריט בשלוש ריצות רצופות, זו תקלה - ולא "אין שינויים". ההיגיון והעלות של שבירה כזו מפורטים באיסוף קטלוגים ומחירים מספקים.
מה צריך המסך לומר בפועל?
ניסוח הוא חלק מהתכנון, לא עיטור. שלוש דוגמאות לניסוח שמעביר את אותה עובדה בלי להתחייב:
- במקום "יש במלאי" - "נצפה זמין אצל הספק ב-14.8 בשעה 09:40".
- במקום "אספקה תוך 3 ימים" - "זמן אספקה נמסר על ידי הספק בעת ההזמנה".
- במקום "נותרו 4 יחידות" - "הספק הציג מלאי נמוך; הכמות אינה מאומתת".
בממשק פנימי מוסיפים מחוון גיל לכל שורה, ובממשק שלקוח רואה - לא מציגים כלל נתון זמינות שמקורו בתצפית חיצונית, אלא רק את המלאי שלכם. הגבול בין מלאי שלכם למלאי של אחר מפורק בסנכרון מלאי בין חנות לאתר, ותהליכי הרכש שנשענים עליו באוטומציה של ניהול מלאי.
לבקש מהספק לפני שבונים
השאלה שכמעט אף אחד לא שואל היא "יש לכם קובץ מלאי?". לספקים בינוניים ומעלה יש לרוב אחד, והם מוכנים לשלוח אותו ללקוח קבוע. מה שכדאי לבקש, לפי סדר העדפה: ממשק מתועד; קובץ יומי בפורמט קבוע; לוח משותף שמתעדכן; ולבסוף התחייבות בכתב על זמן אספקה לפריטים המרכזיים.
הזנה רשמית פותרת יותר מבעיה טכנית. היא מגיעה עם source_as_of אמיתי, היא לא נשברת כשהספק משנה עיצוב, והיא הופכת את הזמינות לנתון מוסכם בין שני צדדים במקום לפרשנות של מסך.
מקורות
שאלות נפוצות
האם מותר להציג ללקוח שלי את המלאי של הספק?
מבחינה מערכתית זה סיכון: אתם מציגים נתון שאינכם שולטים בו ואינכם יכולים לאמת, ובפועל הופכים אותו להתחייבות שלכם. הפרקטיקה הבטוחה היא להציג מלאי משלכם בלבד, ולהשתמש בנתוני הספק פנימית לצורכי רכש והתראות. השאלה החוזית נפרדת ונדונה מול הספק.
כל כמה זמן צריך לבדוק זמינות אצל ספק?
לפי חלון הקבלה של ההחלטה. אם הזמנת רכש נכתבת פעם ביום, בדיקה יומית מספיקה. אם אתם מוכרים פריטים מהירי מחזור ומתחייבים ללקוח באותו יום, נדרשת בדיקה תכופה יותר - וגם אז התשובה ללקוח נשענת על רענון נקודתי ולא על הערך השמור.
מה עדיף - כמות מדויקת או סימון זמינות?
סימון זמינות אמין יותר, מפני שכמויות שמוצגות באתרי ספקים נוטות להיות מעוגלות, מוסתרות מעל סף מסוים, או מוצגות ברמת מחסן ולא ברמת סניף. כמות שימושית כאשר הספק מספק אותה בהזנה רשמית ומצהיר על משמעותה. אחרת עדיף לטפל בה כאיתות.
איך יודעים שהמיפוי של מצבי הזמינות שגוי?
שומרים את הטקסט הגולמי לצד המצב הממופה, ובודקים אחת לחודש את הערכים הגולמיים שלא זוהו. ניסוח חדש אצל הספק, למשל "אזל זמנית" מול "אזל", יופיע שם לפני שהוא יגרום להחלטה שגויה, וזו הבדיקה הזולה ביותר במערכת.
להמשך קריאה
שירות רלוונטי
אוטומציה לעסקים
אני בונה אוטומציות מותאמות שמורידות עבודה חוזרת מקצה לקצה.
על הכותב
יהונתן סעדיה
מפתח פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מפתח בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה רוצה לבנות או איזה תהליך להפוך לאוטומטי. אני חוזר תוך 24 שעות עסקים עם כמה שאלות ממוקדות, ואז עוברים על זה יחד בשיחת היכרות חינמית של 30 דקות, בלי התחייבות. בסוף יש לך היקף עבודה, לוח זמנים ומחיר קבוע - או תשובה כנה שלא שווה לבנות את זה.