הרשאות ובידוד
בידוד בין מחלקות ולקוחות נאכף במסד הנתונים, עם יומן ביקורת לכל פעולה של אדם או של סוכן AI.
פיתוח מקומי לארגונים
ארגונים שמחליטים לבנות לבד מערכת דיוור, SMS, CRM וסוכני AI מגלים שהבסיס לבדו לוקח שנים: הרשאות, הסכמות, מסירה, יומני ביקורת ותרגום. אצלנו הבסיס הזה כבר קיים ונבדק, וצוות פיתוח מקומי בונה עליו רק את מה שייחודי לכם, יחד עם הצוות שלכם ובעברית.
פיתוח בישראל, עם אנשי הצוות שבונים את המערכת עצמה
השוואת דרכים
כך נראית הדרך כשכותבים מאפס, לעומת פיתוח על בסיס קיים. ההערכה לפי שלבים, כי כל ארגון שונה, אבל הסדר תמיד אותו סדר.
השנים בציר הן סדר הגודל של בנייה פנימית מאפס, לא התחייבות זמן לפרויקט שלכם.
מה כבר בנוי
בידוד בין מחלקות ולקוחות נאכף במסד הנתונים, עם יומן ביקורת לכל פעולה של אדם או של סוכן AI.
מייל, SMS ו-WhatsApp מרשימה אחת, עם הסכמה מתועדת לכל נמען והסרה שחלה על כל הערוצים.
אנשי קשר, עסקאות, פניות, פרויקטים ותהליכי אוטומציה עם גרסאות, הדמיה וחזרה לגרסה קודמת.
איך עובדים יחד
למה מקומי
פרויקט מערכת שיווק ו-CRM בארגון נכשל בדרך כלל לא בקוד אלא בפער בין מה שהצוות העסקי צריך לבין מה שספק בחו״ל הבין. צוות מקומי מכיר את חוק הספאם הישראלי, את דרישות הנגישות, את ספקי ה-SMS בארץ ואת הדרך שבה ארגון ישראלי מאשר החלטות. הוא יושב בישיבות, עונה באותו אזור זמן ומדבר עברית עם מי שישתמש במערכת.
החיסכון העיקרי הוא בבסיס. מערכת אוטומציה שיווקית רצינית צריכה ניהול הסכמות שעומד בבדיקה משפטית, מסירה שלא נופלת לספאם, בידוד בין מחלקות, יומני ביקורת וממשק מלא בכמה שפות. ב-EmailPro כל אלה כבר קיימים ומכוסים ביותר מתשעת אלפים בדיקות אוטומטיות, ולכן תקציב הפיתוח של הארגון הולך למה שבאמת מבדל אותו.
וכשהפרויקט נגמר, הקוד לא נעלם אצל ספק. ההרחבות שנבנו לכם מתועדות, נבדקות בכל גרסה, ונגישות גם לעוזרי AI דרך שכבת ה-MCP של המערכת, כך שסוכן או עוזר שהארגון מאשר יכול להפעיל אותן כמו כל יכולת אחרת.
בכנות
פיתוח על בסיס קיים חוסך זמן רק כשהבסיס מתאים. אלה המקרים שבהם נגיד לכם את זה מראש.
אם אתם בונים מערכת דיוור כדי למכור אותה הלאה כמוצר משלכם, בסיס של ספק אחר יגביל אתכם בדיוק במקום שבו אתם רוצים להתחרות. במקרה כזה עדיף לבנות לבד.
חיבור בודד ל-CRM חיצוני או ל-Zapier לא דורש פרויקט פיתוח. בדרך כלל הוא כבר קיים כ-webhook חתום או כחיבור מוכן, ונראה לכם איך מגדירים אותו לבד.
פרויקט פיתוח צריך בעל עניין אחד שמאשר דרישות ומקבל את התוצר. בלי אדם כזה, הדרישות משתנות כל שבוע והפרויקט מתארך, גם עם הצוות הטוב ביותר.
בדרך כלל את רוב התקציב והזמן, כי החלק הגדול של מערכת כזו הוא הבסיס ולא היכולת הייחודית. הרשאות, הסכמות, מסירה, ערוצים, CRM, יומני ביקורת ותרגום כבר בנויים ונבדקים. את ההיקף המדויק אפשר לתת רק אחרי שמפרטים את מה שחסר לכם, ולכן מסמך האפיון הוא השלב הראשון.
זכויות השימוש בהרחבות שנכתבו לארגון והאופן שבו הן נמסרות מוגדרים בהסכם הפרויקט. בכל מקרה ההרחבות מתועדות ומכוסות בבדיקות, והצוות שלכם עובד עליהן לאורך הפרויקט, כך שהידע נשאר בארגון ולא רק אצלנו.
כן, וזו מטרה מוצהרת של העבודה המשותפת. המפתחים שלכם לומדים את מבנה ההרחבות, את הבדיקות ואת תהליך המסירה תוך כדי הפרויקט, ומקבלים תיעוד. אחרי זה אפשר להמשיך לבד, או לסכם בהסכם הפרויקט את המשך המעורבות שלנו.
שני הדברים משלימים. ההרחבות נכתבות על אותו קוד שרץ בכל אפשרות פריסה, ונבדקות בסביבה שסוכמה לפרויקט. הסדר המקובל הוא סביבת ניסיון קודם, ואחריה ייצור בתוך הרשת כשהבדיקות של אבטחת המידע עוברות.
ERP, CRM קיים, מערכות הזמנות ותורים, חנויות אונליין, מרכזיות ומערכות זהות. חלק מהחיבורים כבר קיימים כחיבור מוכן או כ-webhook חתום, ואת מה שאין כותבים בפרויקט. בשלב האפיון עוברים על כל מערכת ומחליטים אם היא מקור מידע, יעד, או שניהם.
שיחה עם מי שבונה את המערכת, ובסופה הערכה כתובה של מה כבר קיים ומה צריך לפתח.
לקבוע שיחה