שאלות נפוצות

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

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

הזמן משתנה בהתאם למורכבות הארגון, אך ברוב המקרים מדובר במספר שבועות בודדים (3-6 שבועות) משלב האפיון ועד להפעלה מלאה של המערכת.

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

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

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

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

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

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

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

לכל אוטומציה יש ניטור והתראת כשל, כך שאנחנו מזהים את השינוי כשהוא קורה ולא כשלקוח מתלונן. תיקון של שינויי API הוא חלק מהתחזיקה השוטפת.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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