GTM engineer מה זה? התפקיד, הכלים והשכר בישראל 2026

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

הכותרת הזו נולדה בסביבות 2023 סביב הכלי Clay, והפכה בתוך שנתיים לאחד התפקידים הנחשבים בסטארט-אפים בשלב צמיחה. מבחינת שוק העבודה, הוא ממוקם בין Marketing Ops, Sales Ops ופיתוח תוכנה, ומי שמחזיק בו נדרש לדעת קצת מכל אחד מהם.

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

GTM מה זה? הפירוש של המושג ולמה זה לא מניה

GTM הוא ראשי תיבות של Go-To-Market: האופן שבו חברה מביאה מוצר לשוק ומוכרת אותו. זה כולל מי הלקוח, באיזה ערוץ מגיעים אליו, איזה מסר הוא שומע, ומי סוגר את העסקה. כשמחפשים gtm meaning בגוגל, התשובה הזו היא ההגדרה העסקית. יש גם תוצאות לחיפוש gtm stock, והן עוסקות בסימול של חברה נסחרת בבורסה, ואין להן קשר לנושא כאן.

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

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

Kareem Amin, מנכ"ל ושותף מייסד של Clay, הגדיר זאת בהודעה לעיתונות באוגוסט 2025: "GTM engineering represents the first true AI-native profession". אפשר להתווכח אם זה ה-AI-native הראשון, אבל ההגדרה קולעת בנקודה אחת: התפקיד לא היה קיים לפני שכלי AI אפשרו לשרשר מקורות נתונים ומודלי שפה בתוך טבלה אחת. הציטוט מגיע ממי שמוכר את הכלי, ולכן כדאי לקרוא אותו בהתאם. את הפרטים אפשר לבדוק ב-הודעת הגיוס של Clay.

מה עושה GTM engineer ביום-יום?

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

1. בניית רשימות והעשרת נתונים

הוא מושך חברות מבסיס נתונים כמו Apollo או LinkedIn Sales Navigator, ומוסיף להן שדות שאף ספק לא מספק מוכן: האם החברה מגייסת SDRs, באיזה CRM היא משתמשת, האם הייתה לה סבב גיוס בשנה האחרונה. העשרה כזו נעשית בשרשרת ספקים, כשכל אחד ממלא את מה שהקודם לא מצא. כך נראה ב-Clay מה שמכונה waterfall enrichment.

2. ניקוד וסינון

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

3. התאמה אישית בקנה מידה

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

4. חיבור למערכות ושמירה על איכות

כל התוצאות נכתבות ל-HubSpot או Salesforce, עם כללי שיוך, מניעת כפילויות ועדכון סטטוסים. כאן ההבדל בין חובבן למקצוען: מי שמסיים את העבודה בגיליון מייצר לצוות עומס. מי שמסנכרן ל-CRM, מייצר צנרת שאפשר למדוד. על ההיבט הארגוני אפשר לקרוא בהרחבה ב-מדריך RevOps לחברות B2B בישראל.

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

אילו כלים GTM engineer מחזיק?

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

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

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

במה GTM engineer שונה מ-RevOps, מ-SDR ומאיש אוטומציה?

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

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

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

כמה משלמים ל-GTM engineer בישראל?

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

הנתונים הבינלאומיים

• Clay: חציון של 160,000 דולר בשנה, לפי ההודעה מאוגוסט 2025. הנתון מגיע מספק הכלי שמרוויח מכך שהתפקיד נתפס כנחשק.
• Bloomberry: ניתוח של יותר מ-1,000 מודעות עם שכר מצוין הניב חציון של 127,500 דולר.
• טווח נפוץ: מ-60,000 דולר בתפקידים זוטרים ועד מעל 250,000 בחברות AI בשלב B ומעלה, לפי דוח השכר של RevGuild.

ההפרש בין 160,000 ל-127,500 מסביר את הבעיה בנתוני התחום. מודעות עם שכר מצוין שייכות לרוב לחברות שמוכנות לחשוף אותו, ובדרך כלל אלה גם החברות היותר מבוססות. נתון על תפקיד חדש נשען על קבוצה מצומצמת, ולכן בדוק את המקור לפני שאתה מצטט.

המצב בישראל

בחיפוש משרות בישראל מופיעות מודעות GTM engineer, GTM AI engineer ו-GTM systems engineer בתל אביב, פתח תקווה, רמת גן ורעננה. בין המעסיקים: monday.com, Papaya Global, Lusha, Transmit Security, Chargeflow ו-Team8. הדרישות החוזרות הן ניסיון ב-CRM, SQL, חיבורי API וכלי אוטומציה כמו Clay, n8n ו-Make.

לגבי שכר, מצאתי אומדן אחד בלבד: אגרגטור משרות העריך לתפקיד GTM systems engineer בתל אביב טווח של 18,000 עד 26,000 ש"ח בחודש. זו הערכה שנוצרה אוטומטית והמעסיק לא פרסם אותה, ולכן אין להתייחס אליה כאל נתון שוק. ההנחה הסבירה היא שהשכר בישראל מתיישר עם תפקידי RevOps ו-Marketing Ops בכירים, ושתפקיד שמחייב קוד משלם בהתאם לרמת הוותק: עובד עם שנתיים שלוש ניסיון בכלים נמצא בצד הנמוך, ומי שהוביל בנייה של מערכת שלמה בצד הגבוה.

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

איך נהיים GTM engineer?

אין מסלול רשמי. Clay דיווחה על שבעה בוטקמפים עצמאיים שהכשירו יותר מ-2,500 בוגרים בתחום עד אוגוסט 2025, והתפקיד מאוייש בעיקר על ידי אנשים שהגיעו מצד אחד של התחום ולמדו את השני.

1. מגיעים מ-RevOps או Marketing Ops: מכירים את ה-CRM ואת התהליך העסקי, ולומדים SQL ו-API.
2. מגיעים מפיתוח או אנליזה: מכירים קוד, ולומדים את השפה של מכירות ושיווק.
3. מגיעים מ-SDR או מנהל קמפיינים: מכירים את המטרה, ובונים מערכות כדי להשיג אותה בקצב גבוה יותר.

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

דוגמה: איך נראית צנרת GTM אחת מקצה לקצה

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

1. מקור: ייצוא של חברות מ-Apollo לפי תעשייה, גודל ומדינה, עם סינון ראשוני של כפילויות מול ה-CRM.
2. העשרה: בדיקה אם לחברה יש משרת אבטחת מידע פתוחה, באיזה ענן היא עובדת, והאם פורסמה בה השבוע כתבה או הודעה על גיוס.
3. ניקוד: כל חברה מקבלת ציון של 0 עד 100. מי שמעל 70 ממשיכה, ואת השאר המערכת מחזירה לבדיקה בחודש הבא.
4. איש קשר: איתור ה-CISO או מנהל ה-IT, אימות כתובת המייל, ובדיקה שהוא עדיין עובד בחברה.
5. הודעה: מודל שפה כותב שורת פתיחה על בסיס הסימן שנמצא, ואדם בודק דגימה של עשרה אחוזים לפני שליחה.
6. שליחה ומדידה: רצף של לינקדאין ומייל, וכל תגובה חוזרת ל-CRM עם התיוג המתאים.

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

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

טעויות נפוצות בבניית צנרת

• אוטומציה לפני הגדרת ICP: מי שלא יודע למי הוא מוכר, מייצר רעש מהר יותר.
• העשרה בלי תקציב: שרשרת ספקים על עשרות אלפי רשומות צורכת קרדיטים במהירות, ולכן מריצים קודם על דגימה של 50 שורות.
• היעדר תיעוד: צנרת שרק אדם אחד מבין היא סיכון עסקי, ולא נכס.
• הסתמכות על הודעת AI ללא בדיקה: מודלים ממציאים פרטים, ומשפט שגוי על הנמען שורף את הפנייה.
• התעלמות מדין ודיווח: פנייה קרה בישראל כפופה לחוק הספאם ולדיני הגנת הפרטיות, ויש לבדוק בכל קמפיין אם הנמען הסכים לקבל דיוור שיווקי.

מתי עסק צריך לגייס GTM engineer?

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

• מתאים: סטארט-אפ B2B עם 5 עד 30 אנשי מכירות ושיווק, שמוכר ללקוחות ארגוניים ויש לו ICP מוגדר.
• לא מתאים עדיין: חברה שעדיין מחפשת התאמה בין מוצר לשוק, או כזו שמוכרת לעשרה לקוחות בשנה.
• אלטרנטיבה: סוכנות או פרילנסר שבונים את המערכת פעם אחת ומעבירים לצוות הפנימי.

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

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