פנייה שנשלחת בטופס צריכה להגיע למקום שבו הצוות יכול לטפל בה. במדריך הזה נבנה תכנון מעשי להעברת פניות דרך Custom webhook של Make אל Google Sheets, עם מזהה קבוע ובקרה על ניסיונות חוזרים. זהו מדריך המבוסס על התיעוד, ולא תרחיש שהורץ בפועל. כל ערכי הדוגמה והתוצאות הצפויות סינתטיים.
לפני שמתחילים
הפתרון מתאים לעסק עם מעט פניות ועם ספק טפסים שמסוגל לשלוח בקשות מאומתות מהשרת, או עם שרת קבלה קיים. טופס בדפדפן לבדו אינו מקום לשמירת מפתח סודי. נדרשים חשבונות מורשים, גיליון בדיקה נפרד ואחראי שיבדוק פניות שנתקעו. הקמת התשתית והרשאותיה היא שלב מקדים, שצריך לבצע בהתאם למדיניות העסק.
כדי לצמצם מידע אישי, הגיליון בדוגמה שומר הפניה לרשומת הטופס, ולא שם, טלפון או מלל חופשי. הצוות מוצא את פרטי הקשר במערכת המקור לפי contact_ref. יש לוודא שהמזהה אכן מאפשר לאנשי הצוות המורשים להגיע לפנייה, אחרת מתקבלת רשימת מעקב שאי אפשר לעבוד איתה.
1 הגדירו חוזה נתונים קטן
בקשו ממערכת הטפסים לשלוח אובייקט JSON אחד לכל פנייה. חמשת השדות הבאים הם טקסט חובה. זהו קלט מלאכותי בלבד:
- submission_id: DEMO-20261004-001
- submitted_at: 2026-10-04T09:00:00Z
- source: website_contact
- service: automation_consulting
- contact_ref: CONTACT-DEMO-001
submission_id נוצר פעם אחת במערכת המקור ונשאר זהה בכל שליחה חוזרת. אל תשתמשו בכתובת דוא״ל כמפתח: אדם אחד יכול לפנות פעמיים בנושאים שונים. submitted_at הוא זמן הקבלה המקורי ב־UTC. source מקבל רק website_contact; service מקבל רק automation_consulting או website_build. הגבילו מזהים לאותיות לטיניות, ספרות, מקף וקו תחתון, באורך של עד 80 תווים.
מערכת המקור צריכה לדחות שדות חסרים, ערכים ריקים, תאריך בלתי תקין ושדות עודפים. היא גם קובעת את מזהה האירוע ואת המקור בעצמה. אין לסמוך על ערכים שהדפדפן שולח כאילו הם הוכחה לזהות הפונה. בטלו קבצים מצורפים בתרגיל הזה ושמרו את הבקשה קטנה.
2 הכינו את הגיליון ואת ההרשאה
צרו גיליון בדיקה בשם Leads Demo ולשונית Intake. בשורה הראשונה הגדירו, משמאל לימין, את הכותרות submission_id, submitted_at, source, service, contact_ref, status. אל תמזגו תאים ואל תשנו כותרות באמצע הבדיקה.
בחרו חיבור Google מורשה שמתאים לעבודה העסקית. הרשאה לחיבור אינה בהכרח מוגבלת לגיליון היחיד שבחרתם במודול. בדקו את מסך ההסכמה ואת מדיניות הארגון; בהגדרת לקוח OAuth עצמאי התיעוד מציין הרשאות Sheets ו־Drive. העדיפו חשבון ייעודי בעל גישה מצומצמת למסמכים, ושתפו את הקובץ רק עם המטפלים בפניות. אין צורך במידע פיננסי או בהרשאת דוא״ל לצורך התרגיל.
3 הגדירו קבלה מאומתת
בתרחיש חדש הוסיפו Webhooks ואז Custom webhook. דרך Add תנו לו שם המתאר סביבת בדיקה. הגדירו API Key authentication, ושמרו את המפתח ואת כתובת הקבלה רק בתצורת שרת מוגנת. הצד השולח מצרף את המפתח בכותרת x-make-apikey ומגדיר Content-Type כ־application/json.
אין להדביק את הכתובת או המפתח במאמר, בצילום מסך, ב־HTML או ב־JavaScript ציבורי. אם ספק הטפסים אינו תומך בכותרת אימות מהשרת, השתמשו בשכבת שרת מתאימה. אל תסירו אימות כדי לקצר את ההתקנה.
ב־Advanced settings בחרו Data structure מפורש עם חמשת שדות הטקסט כחובה. קליטת דוגמה בלבד מלמדת את Make אילו שדות למפות, אך אינה תחליף לאימות מבנה. בדקו בנפרד גם את הערכים העסקיים המותרים. אל תעבירו את אותם שדות גם בכתובת הבקשה וגם בגוף שלה.
4 הוסיפו סימון לפני הכתיבה
לפני יצירת המאגר, בדקו את ההקצאה הפנויה בחשבון: לפי תיעוד Make, מסלול Free כולל 1 MB לאחסון Data store, וגודל המאגר המזערי הוא 1 MB. לכן ההקצאה מספיקה למאגר אחד, ולא לכמה מאגרים נפרדים לתרגילי הסדרה במקביל. אם ההקצאה כבר בשימוש, עצרו לפני יצירת מאגר נוסף; אין למחוק נתונים קיימים או להפעיל שדרוג בתשלום רק כדי לבצע את התרגיל.
צרו Data store לבדיקה בשם Intake Demo עם שדה טקסט state. המפתח יהיה submission_id. הוסיפו Check the existence of a record ומפו אליו את המזהה. לאחריו הוסיפו Router עם שני תנאים נפרדים לפי התוצאה הבוליאנית.
כאשר המפתח אינו קיים, הפעילו Add/replace a record: מפתח שווה submission_id, מצב שווה pending, ואפשרות Overwrite an existing record כבויה. לאחר הצלחת השמירה המשיכו לכתיבה בגיליון. כאשר המפתח קיים, אל תכתבו שורה נוספת; החזירו תשובת record_exists והעבירו את הבירור לאחראי.
בהגדרות התרחיש הפעילו Process data in order, והקצו לתהליך כותב יחיד. הפעילו גם Commit after each module כדי שסימון pending יישמר לפני הניסיון לכתוב בגיליון. זו בחירה מכוונת לתהליך הזה, ולא המלצה גורפת לכל אוטומציה. היא דורשת טיפול יזום ברשומות ממתינות.
5 מפו את שורת המעקב
הוסיפו Google Sheets ואז Add a Row. בחרו את הקובץ והלשונית שהכנתם, ומפו לפי הכותרות:
- עמודות A עד E מקבלות בהתאמה את חמשת שדות ה־Webhook.
- עמודה F, ששמה status, מקבלת את הטקסט הקבוע new.
- אין למפות כתובת Webhook, כותרת אימות או את כל חבילת הנתונים לתא אחד.
לאחר הכתיבה הוסיפו Update a record לאותו מפתח ושנו state ל־stored. תוצאת היעד הסינתטית היא שורה אחת שמתחילה ב־DEMO-20261004-001 ומסתיימת ב־new, ולצדה סימון stored במאגר. זו ציפייה לבדיקה, לא פלט שנצפה ב־Make.
6 קבעו איך מגיבים לכשל
בתרגיל השאירו Store incomplete executions כבוי, וחברו מסלול שגיאה שמסתיים ב־Commit למודול הכתיבה ולמודול עדכון הסימון. הוא עוצר את הריצה ושומר שינויים תומכי־עסקאות שכבר נעשו. המטרה היא להשאיר pending לבדיקה, בלי להוסיף ניסיונות כתיבה אוטומטיים. הגדירו בדיקת תקלות תפעולית; תשובה חסרה או ממתינה אינה אישור הצלחה.
אחרי הצלחה, Webhook response בסוף המסלול יכול להחזיר 201 עם status: stored והמזהה. במסלול מפתח קיים החזירו 202 עם status: record_exists; זו אינה הוכחה שהגיליון עודכן. בתכנון הזה הספק שומר פניות עד התאמה לתוצאה העסקית. תשובת Accepted רגילה מציינת קבלה בלבד. אם ספק הטפסים מפסיק להמתין מוקדם יותר, עברו לתהליך אסינכרוני עם מעקב מצבים בצד השרת.
7 בדקו קצוות לפני הפעלה
שלחו בסביבת הבדיקה את הדוגמה, ואחריה שוב אותו מזהה. הציפייה היא שורה אחת. שלחו מזהה חדש: הציפייה היא שורה נוספת. נסו מקור אסור, שדה חסר ושירות בלתי מוכר: הם צריכים להידחות לפני הכתיבה. בדקו גם שתי בקשות סמוכות ואת המצב שבו Google אינו זמין.
אם נשאר pending, חפשו את submission_id בגיליון ובדקו שאין ניסיון פעיל נוסף. נמצאה שורה תואמת אחת? השלימו את הסימון בלבד. לא נמצאה שורה לאחר בירור סופי? תעדו את ההחלטה, פנו את סימון הניסיון ורק אז שלחו שוב את האירוע המקורי. נמצאו שתי שורות או אי־ודאות? עצרו לבירור, בלי מחיקה אוטומטית.
תחזוקה ומסקנה
בדקו תורים, נפח Data store, מכסת credits וקצב בקשות ל־Google. בשגיאת 429 הפחיתו עומס והשתמשו בהמתנה מבוקרת בצד השולח. התאימו שמירת נתונים ולוגים לצורך אמיתי; גם מזהי קשר עשויים להיות מידע אישי. הצלחה פירושה פניות ניתנות לאיתור, שורות תקינות ורשימת חריגים מטופלת. המבנה מצמצם כפילויות ומאפשר התאוששות, אך אינו מבטיח עיבוד פעם אחת בדיוק בין שתי מערכות נפרדות.
קובצי תרגול להורדה
החבילה כוללת דוגמאות מקוריות שנכתבו ידנית, נתוני דמה ותוצאות צפויות לבדיקה. היא לא הורצה ב־Make, אינה Blueprint לייבוא ואינה מפעילה אוטומציה. השתמשו בה לצד המדריך ובסביבת בדיקה מורשית בלבד.
הורדת חבילת התרגול של Make (ZIP, 6 KB)
לרקע על התאמה לעסק, עלויות ותחזוקה, קראו את סקירת Make לעסקים קטנים.
מקורות
- מרכז העזרה של Make: Data stores
