מ־Webhook לליד שמור ב־Make: תהליך ראשון עם מיפוי, מניעת כפילויות ובדיקות

מגדירים תוצאה עסקית לפני שמניחים מודולים

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

הדוגמה המלאה היא היפותטית: טופס באתר של סטודיו בשם ״אורן דיגיטל״ שולח שם, טלפון, דוא״ל, מקור, זמן יצירה ומזהה בקשה. היעד בשלב הראשון הוא Data Store בשם leads_inbox. הוא אינו תחליף אוטומטי ל־CRM, אלא נקודת קליטה מבוקרת שקל לבדוק לפני שמחברים מערכת נוספת.

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

1. כתבו במשפט אחד את האירוע: ״כאשר הטופס מאשר שליחה, הוא שולח ליד אחד ל־Webhook״.
2. קבעו שהצלחה פירושה רשומה אחת בלבד עבור request_id מסוים, ולא רק קבלת HTTP 200.
3. הגדירו בעל תפקיד ללידים שנדחו ולכשלים שלא התאוששו.
4. השתמשו בנתוני דוגמה בלבד עד שכל בדיקות הקבלה עוברות.

• יש מקור אחד מוגדר לבקשה הראשונה.
• יש מזהה request_id שנוצר אצל השולח ונשמר ללא שינוי.
• ברור מי מקבל ליד תקין ומי מטפל בליד שגוי.
• אין בתרחיש הבדיקה פרטי לקוח אמיתי.

כותבים חוזה קלט ומיפוי מדויק

חוזה הקלט הוא ההסכמה בין הטופס לבין Make. שמות השדות באנגלית נשארים קבועים גם אם הכותרות בטופס משתנות. בדוגמה נדרשים request_id, full_name, phone, source ו־created_at. השדה email אופציונלי. כל ערך נשמר כטקסט למעט מידע שבאמת צריך עליו חישוב. מספר טלפון נשמר כטקסט, כדי לא לאבד את סימן הפלוס או אפסים מובילים.

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

דוגמה מלאה: הבקשה evt_20260908_00041 שייכת ליעל כהן, עם טלפון +972501234567, דוא״ל yael.example@example.com, מקור landing_page וקמפיין september_demo. זוהי דוגמה היפותטית. לאחר המיפוי הרשומה מקבלת גם status בערך new ו־received_at מזמן הקליטה של Make, כדי להבדיל בין הזמן שהמקור דיווח לבין הזמן שבו האוטומציה קיבלה את הבקשה.

{
  "request_id": "evt_20260908_00041",
  "full_name": "יעל כהן",
  "phone": "+972501234567",
  "email": "yael.example@example.com",
  "source": "landing_page",
  "created_at": "2026-09-08T09:15:00Z",
  "campaign": "september_demo"
}

יוצרים Data Store עם מבנה שמגן על הנתונים

ב־Make, Data Store הוא מאגר פשוט לשמירת מידע בין הרצות ותרחישים. צרו מאגר בשם leads_inbox והגדירו מבנה נתונים התואם לטבלת המיפוי. המפתח הראשי יהיה request_id. לפי תיעוד Make, אפשר ליצור Data Store עם מבנה נתונים מוגדר, והגדרת Strict דוחה פריטים נוספים שאינם במבנה. בפרויקט ראשון כדאי להפעיל Strict רק לאחר שהחוזה נסגר ונבדק, כי שדה חדש מהטופס עלול לגרום לדחייה במקום להיעלם בשקט.

הגדירו כשדות טקסט את full_name, phone, email, source, source_created_at, campaign, received_at ו־status. אל תשמרו את כל גוף הבקשה בשדה אחד כברירת מחדל. שמירה מצומצמת מקלה על חיפוש, מגבילה חשיפה ומכריחה את הצוות להחליט אילו נתונים באמת דרושים.

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

1. פתחו את אזור Data stores בארגון הנכון וצרו Data Store בשם leads_inbox.
2. צרו או בחרו Data structure עם השדות והסוגים שהוגדרו בטבלת המיפוי.
3. הקצו נפח בהתאם למכסה הזמינה בחשבון, בלי להעתיק הנחות נפח מסביבה אחרת.
4. הוסיפו ידנית רשומת בדיקה אחת, קראו אותה ומחקו אותה לפני חיבור ה־Webhook.
5. תעדו מי רשאי לשנות את המבנה ומתי מותר להוסיף שדה.

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

יוצרים Custom Webhook ולוכדים בקשת דוגמה

צרו תרחיש חדש והוסיפו Webhooks > Custom webhook. לחצו Add והגדירו שם ייעודי לניסוי. תחת API key authentication הוסיפו מפתח והחזיקו אותו אצל השולח בלבד. שלחו אותו בכותרת x-make-apikey. כתובת ה-Webhook ומפתח האימות נשארים בצד השרת או בכלי הבדיקה שלכם; אין לשים את המפתח בקוד JavaScript של טופס ציבורי. טופס בדפדפן צריך לשלוח דרך שרת שמאמת ומגביל בקשות.

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

Make מציין ש־Custom Webhook מפעיל תרחיש כאשר מתקבלת בקשה, ושבקשות Webhook נכנסות לתור עיבוד. בלי מודול Webhook response, ברירת המחדל עשויה להחזיר 200 Accepted כאשר הבקשה התקבלה לתור. לכן בבדיקות שלנו לא נסתפק בקוד 200. נבדוק גם את הרשומה שנוצרה ואת גוף התשובה שנגדיר בהמשך.

1. הוסיפו לתרחיש מודול Custom webhook וצרו Webhook ייעודי לסביבת הבדיקה.
2. הגדירו API key authentication ובדקו שבקשה ללא המפתח אינה מתקבלת. אם מקור הטופס אינו מסוגל לשלוח כותרת אימות, חברו אותו דרך צד שרת לפני קליטת מידע אמיתי.
3. העתיקו את הכתובת ישירות לכלי הבדיקה המורשה, בלי לשמור אותה בקוד ציבורי.
4. הפעילו קליטת דוגמה ושלחו בקשת POST עם Content-Type: application/json.
5. פתחו את פלט המודול והשוו שדה מול שדה לחוזה הקלט.
6. שמרו צילום או תיעוד טקסט של שמות השדות בלבד, ללא כתובת ה־Webhook.

curl -i -X POST 'REPLACE_WITH_PRIVATE_TEST_WEBHOOK_URL' \
  -H 'Content-Type: application/json' \
  -H 'x-make-apikey: REPLACE_WITH_PRIVATE_TEST_KEY' \
  --data '{"request_id":"evt_20260908_00041","full_name":"יעל כהן","phone":"+972501234567","email":"yael.example@example.com","source":"landing_page","created_at":"2026-09-08T09:15:00Z","campaign":"september_demo"}'

מפרידים קלט תקין מקלט שגוי לפני הכתיבה

מיד אחרי ה־Webhook הוסיפו Router. לפי תיעוד Make, Router מפצל את הזרימה למסלולים, Filters קובעים אילו bundles עוברים, ואפשר להגדיר מסלול fallback למידע שלא התאים למסלולים האחרים. בנו מסלול Valid ומסלול fallback בשם Invalid. המסלול התקין דורש request_id, full_name, phone, source ו־created_at שאינם ריקים. אם הארגון מחייב דוא״ל, העבירו אותו מרשימת השדות האופציונליים לחובה והוסיפו תנאי מתאים.

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

בדוגמה ההיפותטית, בקשה עם request_id ‏evt_20260908_00042, שם ״גיל לוי״ וטלפון ריק מגיעה ל־Invalid. התוצאה הצפויה היא שאין רשומה חדשה ב־leads_inbox, והשולח מקבל תשובה שמסבירה כי phone חסר. בקשה אחרת עם טלפון תקין אך email ריק עוברת במסלול Valid, משום שבחוזה הנוכחי email אופציונלי.

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

1. הוסיפו Router מיד אחרי ה־Webhook.
2. במסלול Valid הגדירו Filter שכל שדות החובה קיימים ואינם ריקים לאחר ניקוי רווחים.
3. הוסיפו למסלול Valid תנאי source שווה landing_page בדוגמת הניסוי. הרחיבו רק לרשימת מקורות שאישרתם בחוזה הקלט.
4. סמנו את המסלול השני כ־fallback וטפלו בו כ־Invalid.
5. בנו תשובת שגיאה עקבית עם status, error_code ו־missing_fields.
6. ודאו שבמסלול Invalid אין מודול שכותב ל־leads_inbox.

{
  "status": "rejected",
  "error_code": "missing_required_field",
  "missing_fields": ["phone"],
  "request_id": "evt_20260908_00042"
}

מונעים מרוץ כפילויות ומריצים שלוש בקשות ראשונות

במסלול Valid הוסיפו Data store > Check the existence of a record, בחרו leads_inbox ומפו את request_id לשדה Key. פצלו לפי התוצאה: true מחזיר duplicate_ignored בלי כתיבה; false ממשיך ל-Add/replace a record עם אותו Key והמיפוי שבטבלה. כבו את Overwrite an existing record, כדי שהתנגשות לא תדרוס ליד שכבר קיים. שגיאת מפתח קיים מטופלת ככפילות אחרי בדיקת הרשומה, ולא כאישור להחלפת תוכן.

כדי לסגור את חלון המרוץ, פתחו את הגדרות התרחיש והפעילו Process data in order. תיעוד Make קובע ש־Instant Webhooks מעובדים במקביל כברירת מחדל, וכאשר אפשרות זו מופעלת Make ממתין לסיום ההרצה הקודמת לפני תחילת הבאה. זה מפחית קצב עיבוד, אבל בתרחיש קליטת לידים קטן הוא מספק ברירת מחדל בטוחה יותר מבדיקת קיום מקבילית. אם נפח הבקשות מחייב מקביליות, צריך יעד נתונים עם כתיבה אטומית או אילוץ ייחודיות, ולא להניח ש־Filter לבדו מונע כפילות. ההגנה הסדרתית חלה על התרחיש הזה בלבד. השתמשו במאגר ייעודי ואל תתנו לתרחיש נוסף לכתוב אליו בלי מנגנון תיאום מתאים.

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

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

1. הפעילו Process data in order לפני בדיקת הכפילויות.
2. הוסיפו בדיקת קיום לפי Key השווה ל־request_id.
3. פצלו בין מפתח קיים לבין מפתח חדש, ורק המסלול החדש כותב רשומה.
4. שלחו את הבקשה התקינה פעמיים בלי לשנות request_id.
5. שלחו בקשה חסרה ובדקו שאין כתיבה.
6. תעדו לכל מבחן את קוד התשובה, גוף התשובה ומספר הרשומות לפני ואחרי.

• שתי בקשות זהות יוצרות רשומה אחת בלבד.
• קלט חסר אינו נכתב ל־Data Store.
• ה־Key ברשומה זהה בדיוק ל־request_id שנשלח.
• כל שדה ברשומה תואם לטבלת המיפוי.
• התרחיש מוגדר לעיבוד לפי סדר בסביבת הבדיקה.

מחזירים תשובה שמבדילה בין קבלה, כפילות ודחייה

עד עכשיו הזרימה קיבלה החלטה פנימית, אבל גם המערכת השולחת צריכה לדעת מה קרה. הוסיפו לכל מסלול סיום תשובת Webhook עקבית. במסלול של ליד חדש החזירו status בערך accepted ואת request_id. במסלול הכפילות החזירו duplicate_ignored ואת אותו מזהה. במסלול הקלט השגוי החזירו rejected, קוד שגיאה ורשימת שדות חסרים. כך השולח אינו צריך לפרש טקסט חופשי, וצוות התמיכה יכול לחפש אירוע לפי מזהה אחד.

קוד HTTP וגוף התשובה ממלאים תפקידים שונים. קוד ממשפחת 2xx מתאים כאשר הבקשה התקבלה או כאשר ניסיון חוזר עם אותו request_id כבר טופל בהצלחה. קוד ממשפחת 4xx מתאים לקלט שהשולח צריך לתקן. כשל פנימי זמני צריך להיראות לשולח ככשל שניתן לנסות שוב, ולא כתשובת הצלחה. בחרו את הקודים המדויקים לפי חוזה ה־API של המערכת השולחת ותעדו אותם. אל תשנו קוד או מבנה גוף בלי לתאם, כי גם שינוי קטן עלול לשבור את מנגנון הניסיון החוזר.

בדוגמה ההיפותטית, הטופס שולח evt_20260908_00041 בפעם הראשונה ומקבל accepted. לאחר ניתוק רגעי הוא שולח שוב בדיוק את אותה בקשה ומקבל duplicate_ignored. מבחינת המשתמש, שתי התשובות משמעותן שאין צורך לשלוח טופס נוסף. לעומת זאת, evt_20260908_00042 ללא טלפון מקבל rejected עם missing_fields. הממשק מציג בקשה לתקן את הטלפון ואינו מציג הודעת הצלחה.

הבדילו בין JSON שהתרחיש שלכם מחזיר לבין תשובת Accepted כללית של Make. לפי התיעוד, אם תשובה מותאמת לא זמינה בזמן ההמתנה, השולח עשוי לקבל קבלה לתור בלבד. לכן צד השולח חייב לבדוק גם גוף JSON ו-request_id, ובמקרה לא חד-משמעי לברר מצב או לנסות שוב עם אותו מזהה. אין להציג ללקוח ״נשמר״ רק בגלל קוד 200.

1. הוסיפו Webhooks > Webhook response בסוף כל מסלול, לאחר הכתיבה במסלול החדש.
2. בחרו Status 201 לליד חדש, 200 לכפילות שטופלה ו-422 לקלט חסר. הגדירו Custom header בשם Content-Type עם application/json.
3. מפו את request_id לגוף JSON באמצעות שדה ממופה, ושמרו את ערך status המתאים למסלול.
4. בהגדרות התרחיש הפעילו Commit after each module, כדי שכתיבת ה-Data Store תושלם לפני אישור השליחה. בדקו זאת שוב באמצעות חיפוש הרשומה לאחר התשובה.

{
  "status": "accepted",
  "request_id": "evt_20260908_00041"
}

מתכננים ניסיון חוזר בלי ליצור לידים נוספים

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

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

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

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

1. פתחו Scenario settings והפעילו Store incomplete executions. אל תאפשרו השלכת נתונים כשנפח האחסון מלא.
2. לחצו על מודול הכתיבה, בחרו Add error handler ואז Retry. לגרסת הלמידה בחרו Automatically complete execution: No, כדי לבדוק כשל לפני ניסיון ידני.
3. בהרצה שנכשלה, פתחו Incomplete executions, חפשו את request_id ב-Data Store ובדקו אם הכתיבה כבר התרחשה. רק אז תקנו והמשיכו.
4. אל תשתמשו ב-Skip או ב-Resume עם פלט הצלחה מומצא כדי להעלים שגיאת שמירה.

• כל retry משתמש באותו request_id.
• אין retry אוטומטי על missing_required_field.
• הצלחה מוחזרת רק אחרי כתיבה מוצלחת או זיהוי כפילות.
• קיימת מגבלת ניסיונות וסיום ברור לטיפול אנושי.
• יומן השגיאות אינו מכיל גוף בקשה מלא ללא צורך.

מריצים חבילת בדיקות קבלה, כולל בקשות כמעט מקבילות

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

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

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

1. הקצו לכל מקרה request_id ייחודי, למעט בדיקות הכפילות.
2. רוקנו רק נתוני בדיקה מזוהים או השתמשו במאגר בדיקה נפרד.
3. הריצו את המקרים לפי הטבלה ותעדו תוצאה בפועל מול תוצאה צפויה.
4. פתחו את Data Store והשוו כל שדה לחוזה, כולל received_at ו־status.
5. עצרו מסירה אם בדיקת כפילות, דחיית קלט או כשל כתיבה אינה עוברת.

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

אם ה־Webhook אינו מופעל, התחילו בצד השולח: בדקו כתובת יעד, שיטת POST, Content-Type וגוף JSON. אין להדביק את כתובת ה־Webhook בכרטיס תמיכה פתוח. אם ההרצה מתחילה אך שדות אינם זמינים למיפוי, שלחו מחדש דוגמה מלאה והפרידו בין שדה שאינו נשלח לבין שדה שנשלח בערך ריק.

אם כל בקשה מגיעה למסלול Invalid, בחנו כל תנאי Filter בנפרד. רווחים, אותיות שונות בשם source או חותמת זמן בפורמט אחר יכולים להסביר את הדחייה. תקנו את המקור או את החוזה, לא את נתוני הלקוח בתוך התרחיש בלי כלל מתועד. אם כפילות עדיין נכתבת, ודאו שה־Key הוא request_id המדויק, שכל ניסיון חוזר שומר אותו מזהה ושעיבוד לפי סדר אכן מופעל בתרחיש הנכון.

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

מוסרים תרחיש שאדם אחר מסוגל לתחזק

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

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

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

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

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

עולים לאוויר בהדרגה וקובעים את הפעולה הבאה

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

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

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

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

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