איך לבחור חברת אוטומציה בישראל - שבעה קריטריונים

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

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

1. הם שואלים על העסק לפני שהם מציעים כלי

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

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

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

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

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

מה סביר לקבל בסוף שלב האפיון

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

2. בעלות: על מי רשומים החשבונות ואיפה יושבים ה-workflows

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

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

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

הרצה על שרת שלכם מול הרצה בענן של הספק

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

3. תמחור: מה בדיוק כלול בשוטף

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

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

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

4. מה קורה כשזה נשבר

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

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

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

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

הכשל השקט

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

5. תיעוד והעברת ידע

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

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

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

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

6. ניסיון רלוונטי אמיתי, לא קיר של לוגואים

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

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

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

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

7. הם אומרים לכם לא

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

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

ספק שמסכים לכל מה שביקשתם או שלא הבין את הבקשה, או שלא אכפת לו ממנה.

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

טבלת ניקוד להשוואה בין ספקים

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

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

השאלות לפגישה הראשונה, והתשובות שצריכות להדליק נורה

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

1. 1על מי יהיו רשומים החשבונות של הכלים, ומי יהיה האדמין
2. 2אם נסיים את ההתקשרות, מה בדיוק אני מקבל ותוך כמה ימים
3. 3מה כלול במילה תחזוקה, ומה כבר נחשב פיתוח נוסף בתשלום
4. 4כמה עולה לי התשתית בחודש, ולמי אני משלם עליה
5. 5מי מקבל התראה כשריצה נכשלת, ומה זמן התגובה שאתם מתחייבים לו
6. 6איך אתם מזהים שהמערכת דילגה בשקט על רשומה
7. 7מי בפועל יבנה את זה, ומה קורה כשהוא לא זמין שבועיים
8. 8באיזו מערכת מהרשימה שלנו כבר עבדתם בפועל
9. 9מה מהרשימה שלי אתם חושבים שלא כדאי לבנות
10. 10מה יגרום לפרויקט הזה לקחת פי שניים זמן ממה שאמרתם

מתי לא לשכור אותנו

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

כשהנפח קטן מדי

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

כשהתהליך עצמו לא סגור

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

כששבלונה מוכנה מביאה אתכם ל-90 אחוז

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

כשהתקציב קטן והשיווק רעב

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

כשאתם עומדים להחליף מערכת ליבה

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

סדר הפעולות המומלץ

1. 1כתבו במשפט אחד איזה תהליך כואב, כמה פעמים בחודש הוא קורה, וכמה זמן הוא לוקח
2. 2בדקו קודם אם שבלונה מוכנה או שינוי נוהל פנימי פותרים את זה
3. 3פנו לשלושה ספקים לכל היותר, עם אותו תיאור מדויק לכולם
4. 4בפגישה, ספרו כמה שפחות על פתרונות ותנו להם לשאול
5. 5בקשו הצעה שמפרידה הקמה, תשתית, שוטף ופיתוח נוסף
6. 6תנו ציון בשבעת הקריטריונים לפני שאתם מסתכלים על המחיר הסופי
7. 7בקשו נספח בעלות בכתב לפני חתימה - חשבונות, גישות, תיעוד ותנאי פרידה
8. 8התחילו בתהליך אחד. לא בשלושה במקביל

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