Claude Code + Make.com: הסוכן שקרא 31 אוטומציות וגילה ש-9 מהן מפילות לידים בשקט כבר חודשיים

יש סוג של נזק בעסק שאי אפשר לראות בשום דוח.

הוא לא מופיע בדוח רווח והפסד. הוא לא מופיע ב-Meta. הוא לא מופיע ב-CRM, כי הוא בדיוק הדבר שמנע מהנתונים להגיע ל-CRM.

זה הנזק של אוטומציה שנשברה, ואף אחד לא שם לב.

הסיפור הבא הוא מקרה קלאסי שראיתי בעשרות וריאציות. עסק שירותים, שלוש שנים על Make.com, מערך אוטומציות שנבנה בהדרגה. אף אחד לא שינה כלום. הכל "עובד"…

המספרים

ככה נראתה התמונה אחרי שהסוכן סיים לסרוק:

• 31 תרחישים פעילים בחשבון
• 9 מהם נכשלו באופן קבוע
• 214 הרצות שנתקעו באמצע והצטברו בתור
• הישן ביותר נשבר לפני 67 יום
• 68 לידים מטופס אחד מעולם לא נכנסו ל-CRM

68 לידים. שילמו עליהם. הם מילאו טופס. הם חיכו לשיחה שלא הגיעה.

וכל הזמן הזה, הדשבורד הראה ירוק.

למה אוטומציה נשברת בשקט

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

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

הנה שלוש הדרכים הנפוצות שבהן זה נשבר:

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

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

3. ה-webhook התנתק. זה הרוצח האמיתי. webhook הוא כתובת שאליה מערכת אחת "צועקת" כשקורה משהו. אם התרחיש היה כבוי כמה ימים, Make יכול לנטרל את הכתובת. מאותו רגע היא ממשיכה לקבל בקשות ולזרוק אותן לפח. בלי שגיאה. בלי שורה ביומן. ממש כלום. אין לכם מה לחקור, כי לא נשאר שום סימן.

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

למה בדיוק בשביל זה צריך סוכן

הבדיקה הזאת היא בדיקה שבן אדם יכול לעשות ידנית. זו בדיוק הבעיה.

31 תרחישים, כל אחד עם יומן הרצות משלו, כל אחד עם רשימת חיבורים משלו. בדיקה ידנית רצינית לוקחת שעתיים וחצי. מי עושה את זה כל שבוע? אף אחד. אז לא עושים את זה בכלל, עד שמשהו מתפוצץ.

סוכן AI עושה את אותה בדיקה ב-3 דקות, ויותר חשוב: הוא עושה אותה כל בוקר, בלי שתבקשו ממנו.

איך בנינו את זה, שלב אחרי שלב

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

שלב 1: מוציאים מפתח גישה מ-Make

נכנסים ל-Make, לוחצים על השם שלכם למטה מימין, ואז על Profile. שם יש לשונית API access. מייצרים טוקן חדש.

הנקודה הקריטית: כשמסמנים הרשאות, מסמנים רק את ההרשאות שמתחילות ב-read. scenarios:read, connections:read, dlqs:read. לא נותנים לסוכן הרשאת כתיבה. הוא לא צריך לתקן, הוא צריך לספר.

את הטוקן שומרים במנהל סיסמאות. לא בקובץ, לא בצ'אט, לא בגיליון.

שלב 2: אומרים ל-Claude Code מה לעשות

נכנסים לתיקייה של העסק בטרמינל, מפעילים את Claude Code, וכותבים בערך את זה:

"יש לי חשבון Make.com. הטוקן שמור אצלי במנהל הסיסמאות תחת השם make-api. ה-API של Make יושב בכתובת של האזור שלי, ונדרשת כותרת Authorization עם הערך Token ואז הטוקן.

תבנה לי סקריפט שעושה את הדבר הבא:
1. מושך את כל התרחישים דרך GET /api/v2/scenarios
2. לכל תרחיש פעיל, מושך את ההרצות התקועות דרך GET /api/v2/dlqs
3. לכל תרחיש שיש בו הרצות תקועות, מושך את הלוג דרך GET /api/v2/dlqs/{id}/logs ומסווג את סוג התקלה
4. מסמן גם תרחישים פעילים שלא רצו בכלל יותר מ-7 ימים

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

וזהו. Claude Code כותב את הקוד, מריץ, מתקן את עצמו כשמשהו לא עובד, ומחזיר דוח.

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

שלב 3: הדוח שחזר

ככה נראו שלוש השורות הראשונות:

1. "טופס אתר ← CRM"
68 הרצות תקועות. הישנה ביותר: לפני 67 יום.
סיבה: השדה phone לא נמצא בנתונים הנכנסים.
מה לעשות: הטופס שונה ושם השדה התחלף. לתקן את המיפוי ואז להריץ מחדש את 68 ההרצות. הנתונים עדיין שמורים.

2. "לקוח חדש ← גיליון מעקב"
41 הרצות תקועות. הישנה ביותר: לפני 23 יום.
סיבה: ההתחברות לגוגל פגה.
מה לעשות: להתחבר מחדש בלשונית Connections.

3. "תזכורת פגישה בוואטסאפ"
0 הרצות תקועות, אבל התרחיש פעיל ולא רץ 31 יום.
סיבה משוערת: ה-webhook לא מקבל בקשות.
מה לעשות: לבדוק שהמערכת ששולחת אליו עדיין מחוברת.

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

התיקון, ומה קרה אחרי

התיקונים עצמם לקחו כשעה. שינוי שם שדה אחד, שלוש התחברויות מחדש, ובדיקה של שני webhooks.

אחר כך הגיע החלק הטוב. ב-Make יש אפשרות להריץ מחדש הרצות תקועות, דרך הכפתור במסך או דרך ה-API. 68 הלידים נכנסו ל-CRM.

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

ההגנה: להפוך את זה למשימה יומית

מצאנו ותיקנו. עכשיו הדבר היחיד שחשוב באמת: שזה לא יקרה שוב.

הוראה אחת ל-Claude Code:

"תהפוך את הסקריפט הזה למשימה שרצה כל יום ב-8:00 בבוקר. אם הכל תקין, אל תשלח כלום. אם יש תרחיש עם הרצות תקועות, או תרחיש פעיל שלא רץ יותר מ-3 ימים, תשלח לי וואטסאפ עם רשימה קצרה בעברית."

שתי מילים בהוראה הזאת שוות זהב: "אם הכל תקין, אל תשלח כלום".

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

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

הגדרה אחת ב-Make שחייבים לוודא היום

לפני שאתם בונים משהו, יש הגדרה אחת שקובעת אם הכל לעיל בכלל אפשרי.

נכנסים לכל תרחיש, לוחצים על גלגל השיניים, ומוודאים ש-Allow storing of Incomplete Executions דלוק.

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

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

5 האוטומציות שחייבות ניטור, לפי סדר

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

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

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

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

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

5. כל השאר. תיוגים, סנכרונים פנימיים, גיבויים. חשוב, אבל לא דחוף.

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

כמה זה עולה באמת, במספרים

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

קחו את המספרים שלכם ומלאו:

• כמה לידים אתם מקבלים בחודש דרך טפסים?
• מה שיעור הסגירה שלכם מליד ללקוח?
• מה שווי עסקה ממוצעת?

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

בעסק מהדוגמה זה יצא כך: 34 לידים בחודש, סגירה של 12%, עסקה ממוצעת של 4,800 שקל. כלומר כ-19,500 שקל בחודש. התקלה רצה 67 יום.

וזה עוד לפני שמחשבים את מה שאי אפשר לכמת: 68 אנשים שפנו לעסק, לא קיבלו מענה, והסיקו מזה מסקנה. חלקם סיפרו אותה לחברים.

מול המספר הזה, 20 דקות של הגדרה הן בדיחה.

מה זה לא פותר

אני לא אוהב לספר רק את החצי היפה, אז הנה הגבולות:

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

זה לא מחליף אדם שמסתכל על התוצאה. מישהו עדיין צריך לפתוח את ה-CRM פעם בשבוע ולשאול "הלידים מיום שלישי נראים הגיוניים?". התחושה של מי שמכיר את העסק תופסת דברים שאף API לא מדווח.

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

ואם אתם לא על Make

העיקרון זהה בכל מקום, רק השמות משתנים.

ב-Zapier קוראים לזה Zap ול-Zap History, וגם שם יש API שמחזיר את ההרצות שנכשלו. ב-n8n קוראים לזה Workflow ו-Executions, והגישה דרך ה-API עוד יותר פשוטה. גם למי שבנה אוטומציות ישירות מול ה-API של מערכת כלשהי, הכלל לא משתנה.

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

שורה תחתונה

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

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

67 יום או יום אחד. זה כל ההבדל, וזאת אחת ההוראות הקצרות ביותר שתיתנו ל-Claude Code.

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

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

שאלות נפוצות

מה זה Make.com בשפה של בעל עסק?
כלי שמחבר בין מערכות בלי לתכנת. לדוגמה: כשמישהו ממלא טופס בדף הנחיתה, Make לוקח את הפרטים, פותח כרטיס לקוח ב-CRM, שולח וואטסאפ אוטומטי, ומוסיף שורה לגיליון. כל שרשרת כזאת נקראת תרחיש, באנגלית Scenario.

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

מה זה Incomplete Execution?
הרצה שהתחילה, נתקעה באמצע, ונשמרה בצד בתור. Make קורא לזה גם DLQ. הנתונים לא אבדו ואפשר להריץ אותם מחדש, אבל רק אם הפעלתם מראש את ההגדרה Allow storing of Incomplete Executions בתרחיש. אם היא כבויה, ההרצה נופלת ונעלמת.

כמה זמן לוקח לבנות את הסוכן הזה?
כ-20 דקות לגרסה הראשונה: להוציא טוקן API מ-Make, לתת ל-Claude Code את כתובת ה-API ואת מספר הצוות, ולבקש דוח. אחרי שהדוח עובד, עוד 10 דקות להפוך אותו למשימה שרצה לבד כל בוקר.

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

באהבה ענקית,
יהב.