ליד חדש שנוסף לגיליון צריך להגיע לאדם שמטפל בו, בלי להעתיק ידנית את אותה שורה למייל. במדריך הזה מתכננים תרחיש שקורא שורות חדשות מ־Google Sheets ושולח התראה לכתובת פנימית קבועה. מוסיפים גם רישום לפי מזהה ליד, כדי שעיבוד חוזר לא יהפוך מיד לעוד הודעה.
זהו מדריך המבוסס על התיעוד הרשמי, שנבדק ב־4 באוקטובר 2026. התרחיש לא הורץ בחשבון Make במסגרת הכנת המאמר. כל הנתונים והתוצאות הצפויות כאן סינתטיים ואינם פלט אמיתי של Make.
1 מכינים סביבת תרגול מוגבלת
הכינו גיליון בדיקה בשם lead_alert_lab עם לשונית leads. השתמשו בחיבור Google מורשה ובתיבת בדיקה שנמצאת בשליטתכם. לפני יצירת חיבור חדש, קראו את ההרשאות המבוקשות ואשרו אותן רק אם הן מתאימות לתפקיד החשבון. בחירת לשונית בתוך מודול אינה מצמצמת בהכרח את היקף הרשאות Google לאותה לשונית.
התרגיל צריך גישה לקריאת הגיליון ולשליחת מייל. חיבור מובנה עשוי לבקש הרשאות רחבות יותר; אין כאן הבטחה לחיבור שמוגבל לשליחה בלבד. אל תוסיפו Additional scopes או פרטי OAuth מותאמים בלי צורך מוגדר. לא מכניסים סיסמה, מפתח, תוכן רפואי או פרטי תשלום לשורה.
אשרו מראש כתובת נמען פנימית אחת. כתובת הלקוח בשורה אינה נמען ההתראה. בדוגמה מופיעה הכתובת alerts@example.com לצורכי המחשה בלבד; החליפו אותה בתיבת הבדיקה שלכם לפני שליחה.
2 קובעים מבנה ומזהה קבוע
בשורה הראשונה הגדירו את הכותרות הבאות, בעמודות A עד F:
- lead_id: מזהה ייחודי מהמערכת שהוסיפה את הליד
- created_at: זמן יצירה כטקסט ISO 8601 עם אזור זמן
- contact_name: שם לתצוגה
- contact_email: כתובת לחזרה, אם יש צורך עסקי לשמור אותה
- request_type: ערך קצר כמו consultation
- source: מקור כמו website
קלט סינתטי לדוגמה, לא פלט של Make:
- lead_id: L-1001
- created_at: 2026-10-04T09:30:00+03:00
- contact_name: Example Contact
- contact_email: lead@example.com
- request_type: consultation
- source: website
אותו אירוע חייב לקבל אותו lead_id גם בניסיון חוזר. אל תבנו מזהה ממספר השורה, ואל תיצרו מזהה אקראי חדש בכל ריצה. הוסיפו שורות בתחתית הטבלה ללא שורות ריקות באמצע. שמרו על שמות העמודות ואל תמיינו את טבלת המקור בזמן התרגול.
3 מגדירים את הקריאה מהגיליון
צרו תרחיש חדש והוסיפו Google Sheets > Watch New Rows. בחרו את קובץ הבדיקה ואת leads. הגדירו Table contains headers לערך Yes, את Row with headers לטווח A1:F1 ואת Limit ל־1 בניסוי הראשון.
ב־Choose where to start בחרו All רק בגיליון הבדיקה שמכיל את הדוגמה היחידה. בגיליון קיים בחירה זו מעבדת גם שורות היסטוריות. שמרו גם את התרחיש עצמו.
זהו טריגר שסורק במועדי הריצה; הוספת שורה אינה מבטיחה תגובה מיידית. השאירו את התרחיש ללא הפעלה מתוזמנת במהלך הבנייה. שורה ריקה באמצע הטבלה עלולה למנוע עיבוד של השורות שאחריה.
הוסיפו על החיבור למודול הבא מסנן: lead_id קיים וגם אורך trim(lead_id) גדול מאפס; request_type קיים וגם אורך trim(request_type) גדול מאפס. בביטויים בוחרים את שדות המקור מתוך המיפוי. שורה שנעצרת במסנן צריכה להיכנס לרשימת בדיקה ידנית; המסנן עצמו אינו תור שגיאות.
4 מוסיפים מחסום לעיבוד כפול
לפני יצירת המאגר, בדקו את ההקצאה הפנויה בחשבון: לפי תיעוד Make, מסלול Free כולל 1 MB לאחסון Data store, וגודל המאגר המזערי הוא 1 MB. לכן ההקצאה מספיקה למאגר אחד, ולא לכמה מאגרים נפרדים לתרגילי הסדרה במקביל. אם ההקצאה כבר בשימוש, עצרו לפני יצירת מאגר נוסף; אין למחוק נתונים קיימים או להפעיל שדרוג בתשלום רק כדי לבצע את התרגיל.
צרו Data store לתרגול בשם lead_alert_state, עם שדה טקסט state. המפתח יהיה הטקסט lead-alert: ולאחריו שדה lead_id הממופה. לדוגמה: lead-alert:L-1001.
הוסיפו Check the Existence of a Record. העבירו הלאה רק תוצאה בוליאנית false. אחריה הוסיפו Add/Replace a Record עם אותו מפתח, state=pending ו־Overwrite an existing record כבוי. ניסיון להוסיף מפתח קיים צריך לעצור בשגיאה, בלי לעקוף את ההגנה.
המפתח נשמר לפני השליחה בכוונה. כך ריצה חדשה לא שולחת שוב רק משום שהשלב האחרון לא הושלם. זו הגנה שימושית, אך אינה הבטחה ל״בדיוק פעם אחת״ בין שתי מערכות. השאירו ריצות בדיקה ללא חפיפה ואל תריצו במקביל תרחיש נוסף על אותם מפתחות.
בהגדרות התרחיש הפעילו Process data in order וגם Commit after each module. בתרגיל הזה השאירו Store incomplete executions כבוי. חברו מסלול שגיאה המסתיים ב־Commit למודול Gmail ולעדכון הרישום האחרון. זו בחירה מכוונת ששומרת את pending אם פעולה מאוחרת נכשלת ועוצרת לבירור, בלי להוסיף ניסיונות אוטומטיים דרך incomplete executions.
5 ממפים התראה קצרה
הוסיפו Gmail > Send an email בגרסה העדכנית, V4. הגדירו To ככתובת הבדיקה הקבועה. השאירו CC, BCC וקבצים מצורפים ריקים; אין צורך לבחור שולח אחר מהחשבון המחובר.
ב־Subject הכניסו טקסט קבוע ״ליד חדש ״ ולאחריו את lead_id. בחרו Collection of contents עם תוכן טקסט קצר. מפו רק lead_id, request_type ו־source. למשל:
״התקבל ליד L-1001 בנושא consultation. מקור: website. פרטי הטיפול נמצאים בגיליון leads.״
זו תוצאה צפויה סינתטית, לא הודעה שנשלחה. שם וכתובת קשר אינם נחוצים בהתראה הזאת ולכן נשארים בגיליון. אין למפות טקסט חופשי מהטופס לתבנית HTML. אם מוסיפים בעתיד תוכן משתמש ל־HTML, צריך לטפל בתווים מיוחדים ולא לפרש אותו כתגיות.
אחרי Gmail הוסיפו Update a Record עם אותו מפתח ו־state=sent. השאירו Insert missing record כבוי, כדי שרשומה חסרה לא תיראה כמו סיום תקין.
6 בודקים תוצאה והתאוששות
רק לאחר בדיקת הנמען והמיפוי אפשר לבצע Run once בסביבת הבדיקה המאושרת. יעד ההצלחה הוא הודעת בדיקה אחת בתיבת הנמען, נושא עם L-1001, ורשומה במצב sent ברישום. ״המודול הצליח״ לבדו אינו מוכיח שההודעה הגיעה לתיבה.
בדיקות קצה צפויות, כולן סינתטיות:
- שורה חדשה עם L-1001 שוב: לא נשלחת הודעה נוספת
- L-1002 עם request_type ריק: נעצרת לפני יצירת pending
- רשומת L-1003 שכבר במצב pending: אינה נשלחת אוטומטית שוב, ומחייבת בירור
- שורה ריקה לפני L-1004: בודקים את רציפות הטבלה לפני שינוי הטריגר
- שני לידים שונים עם אותה כתובת קשר: נשארים שני אירועים אם המזהים שונים
אם המייל נשלח ועדכון sent נכשל, השאירו את המפתח. בדקו בתיקיית הנשלחים ובתיבת הבדיקה, ואז תקנו את הרישום בלבד לאחר התאמה. במקרה של timeout בשליחה, התוצאה אינה ידועה; אין למחוק pending ולהריץ שוב באופן עיוור. אם יש ניסיון אוטומטי ממתין, בדקו גם אותו לפני פעולה ידנית.
שגיאת הרשאה דורשת תיקון החיבור המאושר; שגיאת שדה דורשת תיקון המיפוי. מגבלת קצב או נפח דורשת בדיקת Make וספק הדואר, האטה והמתנה בהתאם לשגיאה. לחיצות חוזרות על Run once אינן מתקנות את הסיבה.
Commit עוצר את כל הריצה, ולא רק את הליד שנכשל. אם בהמשך מגדילים את Limit, שמרו את מזהי הלידים שנקראו והתאימו את כולם לרישום. ייתכן שפריטים מאוחרים טרם טופלו ו־Run once רגיל לא יקרא אותם שוב. התאוששות מהקלט ההיסטורי מחייבת בדיקת מפתחות ונמענים לפני Replay; הוא עובר מחדש גם בשלבים שהצליחו.
7 מחליטים מתי להפעיל
קבעו תדירות לפי הזמן שבו באמת צריך לטפל בליד, ובדקו אילו מרווחים זמינים בתוכנית שלכם. קריאות בדיקה, מודולי הרישום והשליחה עשויים לצרוך credits גם כשאין הרבה לידים. בדקו צריכה בפועל, מכסת אחסון ומגבלות שליחה לפני הרחבה; אין במדריך אומדן מחיר מאומת.
הגדירו מי בודק pending תקוע ושורות שנחסמו, ומהי תקופת שמירת המזהים. מחיקה מוקדמת של מפתח מבטלת את ההגנה מפני חזרה של אותו אירוע. רק אחרי שבדיקות הכפילות וההתאוששות עוברות, אפשר לאשר מעבר מגיליון הבדיקה לתהליך העסקי.
קובצי תרגול להורדה
החבילה כוללת דוגמאות מקוריות שנכתבו ידנית, נתוני דמה ותוצאות צפויות לבדיקה. היא לא הורצה ב־Make, אינה Blueprint לייבוא ואינה מפעילה אוטומציה. השתמשו בה לצד המדריך ובסביבת בדיקה מורשית בלבד.
הורדת חבילת התרגול של Make (ZIP, 6 KB)
לרקע על התאמה לעסק, עלויות ותחזוקה, קראו את סקירת Make לעסקים קטנים.
מקורות
- מרכז העזרה של Make: Data stores
