מה זה Presale? הסבר פשוט + כמה משרות פתוחות בישראל

זמן קריאה: 7 דקות

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

איפה presale נכנס במחזור העסקה

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

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

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

הדמו: מה מבדיל בין הדגמה למכירה

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

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

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

POC: איך לא לאבד שליטה

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

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

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

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

שאלוני אבטחה, RFP והחלק שאיש לא אוהב

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

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

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

המסירה שאחרי החתימה

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

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

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

Presale, Sales Engineer ו-Solutions Engineer

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

Presale - מונח רחב, נפוץ מאוד בישראל, ומתאר את כל הפעילות הטכנית לפני החתימה.
Sales Engineer - השם המקובל בארצות הברית לאותו תפקיד, לרוב עם דגש חזק על הדמו ועל ליווי העסקה.
Solutions Engineer - נוטה לכלול גם עבודה אחרי החתימה: אפיון פתרון, ליווי אינטגרציה והרחבה אצל לקוח קיים.
Solutions Architect - לרוב עמוק יותר טכנית ופחות קשור למחזור המכירה, ולעיתים בכלל בצד הטכנולוגי של הארגון.

בלוח כרגע 11 משרות מסווגות להנדסת פתרונות, 5 להנדסת מכירות ו-3 ל-presale - כלומר אותה משפחת תפקידים מפוזרת בין כמה שמות. המסקנה המעשית: מי שמחפש עבודה בתחום חייב לחפש בכל השמות האלה, כי סינון לפי אחד מהם מפספס את רוב ההזדמנויות.

מה נדרש כדי להיכנס לתפקיד

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

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

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

שאלות נפוצות

צריך לדעת לתכנת?

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

האם presale נמדד על יעדי מכירה?

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

מה ההבדל בין presale ל-Customer Success?

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

כמה נסיעות יש בתפקיד?

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

איך מתכוננים לראיון לתפקיד?

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

האם התפקיד קיים גם בחברות קטנות?

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

כמה עסקאות מלווים במקביל?

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

מה הקשר בין presale למוצר?

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