איך בונים CRM מלא לעסק בלי מפתח - והכלל שמונע מהמבנה להתפוצץ אחר כך
רוצים CRM אמיתי לעסק - לא עוד טבלה, אלא מערכת עם ישויות, תהליכים, טפסים ושליחות אוטומטיות - בלי לשכור מפתח. דוד הדס הראה את זה על אוריגמי (Origami), פלטפורמת CRM מודולרית. אבל הלב של הסשן הוא לא הפלטפורמה - הוא העיקרון שקובע אם המערכת שלכם תחזיק או תתפוצץ: ארכיטקטורת ישויות נכונה. כל נתון שתרצו לנתח = ישות נפרדת מקושרת, לא שדה מקומי. אוריגמי קיימת עד היום, ויש היום עוד פלטפורמות מודולריות - אבל העקרונות עובדים בכל אחת. 7 הפרומפטים למטה בונים את המערכת נכון מהיסוד.

הערת הכתבת: המפגש הזה (16.7.2024) כולו על אוריגמי (Origami) - פלטפורמת CRM מודולרית ישראלית. אוריגמי קיימת ופעילה, ויש היום עוד פלטפורמות מודולריות שעושות דברים דומים. אבל שימו לב מה מהסשן הזה לא תלוי בכלי בכלל: ארכיטקטורת ישויות (מה ישות ומה שדה), מקור אמת אחד, הפרדת תוכן מנתונים בתבניות, טפסים שמעדכנים במקום לשכפל, וההחלטה מה בתוך המערכת ומה באוטומציה חיצונית. אלה עקרונות של בניית מערכות - הם עובדים באוריגמי, ב-Airtable, ב-Notion, בכל פלטפורמה שתבחרו. המיומנות: לאפיין מה העסק צריך, ואז לבחור את הפלטפורמה שתיתן את התוצאה הכי טובה היום. הפרומפט הפתוח למטה עוזר לאפיין.
כל עסק מתחיל אותו דבר: טבלה. לקוחות, לידים, עסקאות - הכל נדחס לטבלה אחת, וזה עובד. עד שזה מפסיק. פתאום אתם רוצים לדעת כמה עסקאות היו בחדר מסוים, או לשלוח הודעה אישית לכל לקוח, או לעצור שליחות בשבת - ומגלים שהמבנה שבניתם לא נבנה לזה, ואתם נלחמים בו בכל פעם מחדש. במפגש הרביעי של אוטוטיוזדיי דוד הדס הראה איך בונים מערכת CRM מלאה בלי קוד על אוריגמי - אבל יותר מזה, הוא לימד את הכלל שמפריד בין מערכת שגדלה איתכם למערכת שקורסת תחת עצמה.

המסע: 7 תחנות
כל תחנה = מה קרה בסשן + הפרומפט שאורז את זה בשבילכם
להבין מתי CRM מודולרי מנצח אוטומציה
דוד פתח בהסבר מה בכלל נותנת מערכת CRM מודולרית שטבלה פשוטה לא: היא בנויה שכבות - קטגוריות שמכילות דפים, רובם 'ישויות' (המקבילה לטבלה), ובתוך כל ישות קבוצות שדות ושדות. הכוח שלה שהיא נותנת לגרד רמה של פיתוח אמיתי בלי קוד: שדות מכל סוג (תאריך, יוזר, חתימה, נוסחה, HTML), תהליכי עבודה עם כפתורי פעולה ווובהוקים, טפסים, והרשאות מפורטות. אבל דוד אמר משהו ששווה לתלות על הקיר: הגבול של מערכת כזו הוא לא המערכת - הוא היכולת של מי שמיישם אותה. מטמיע טוב מגיע ליכולות קרובות לפיתוח. הכלי חזק כמו היד שמפעילה אותו.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
אבחון ארכיטקטורת הישויות של המערכת שלי
וכאן הגיע העיקרון שדוד חזר עליו יותר מכל דבר אחר, כי הוא זה ששובר מערכות: ישות מקושרת מול שדה בחירה. כל נתון מהותי שתרצו לנתח לעומק - לקוח, ליד, עסקה, תשלום, חדר, אפילו תאריך - חייב לשבת בישות נפרדת משלו, ולהתחבר לאחרים דרך שדה קישור. למה זה קריטי? שדה בחירה הוא מקומי, הוא לא מוביל לשום מקום. קישור לישות מאפשר להגיע מכל מקום לכל דבר: להיכנס למופע 'חדר' ולראות את כל הפגישות בו, להיכנס ל'תאריך' ולראות כל מה שקרה בו. כלל האצבע: כל דבר שאולי תרצו לנתח כנתון בפני עצמו - ישות. דבר זניח ומקומי כמו בחירת שעה - שדה. דוד הזהיר מהשטח: ארכיטקטורה לא נכונה = הסתבכות בכל פעם מחדש. זה החלק שאי אפשר לתקן בדיעבד בקלות.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
מנגנון שדה מידע מרכזי לשליטה גלובלית
פה דוד חשף טכניקה אלגנטית שפותרת כאב אמיתי: איך משנים התנהגות בכל המערכת בלי לעדכן עשרות רשומות. יוצרים ישות 'מידע' מיוחדת, ובעזרת תהליך אימות מונעים ממנה גם יצירת מופע חדש וגם מחיקה - כך שתמיד יש בה בדיוק מופע אחד. בתוך המופע היחיד הזה יושבים שדות שליטה גלובליים, למשל 'האם היום מותר לשלוח תקשורת'. כל מופע במערכת (ליד, תקשורת) מקבל אוטומטית קישור למופע המידע היחיד, ושואב ממנו את הערך דרך שדה מצביע. עכשיו כדי לשנות את כל המערכת - מעדכנים שדה אחד. זה בדיוק העיקרון של 'מקור אמת אחד': לא לפזר את אותה החלטה בעשרים מקומות, אלא לרכז אותה בנקודה אחת ששולטת בכולן.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
שליחת תקשורת אוטומטית מתוזמנת ומותנית
וכאן דוד בנה מנגנון שליחה שהוא כמעט מערכת דיוור שלמה בפני עצמה. התקשורת יושבת בישות נפרדת עם סטטוסים (בעריכה / ממתין לשליחה / נשלח), ערוץ, ומועד. שליחה מתוך ליד נעשית ב'המרת מופע' - כפתור שלוקח את נתוני הליד, יוצר מופע תקשורת, ומעביר את השדות כולל הערוץ המועדף, כך שאותו כפתור שולח אוטומטית בערוץ הנכון. הטריק החכם: שדה תאריך שמתעדכן כל בוקר ב-9 דרך cron - שמשרת שני דברים בבת אחת: השוואות תאריכים, וגם טריגר יומי קבוע לשליחות. ובלימת ימים אסורים: לפני שהודעה עוברת ל'ממתין לשליחה' בודקים את שדה 'האם היום מותר', ואם לא - היא נשארת ומחכה, והטריגר היומי יבדוק שוב מחר. הודעה שנקבעה לשישי תישלח לבד בראשון. (דוד גם הזהיר: במערכת אין OR בתנאים, רק AND - אז מייל ווואטסאפ = שני תהליכים נפרדים.)
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
תבניות HTML עם משתנים דינמיים ורינדור
פרסונליזציה בלי לכתוב כל הודעה מחדש - זה מה שדוד בנה בתחנה הזו. יוצרים ישות 'תבניות', וכל תבנית היא שדה HTML עם עיצוב מלא. בתוך התבנית מטמיעים משתנים - שם או מספר סידורי של שדה מוקף בסולמיות (#field#) - והמערכת מרנדרת אותם לערך האמיתי של הלקוח בזמן השליחה. טיפ ששווה זהב: כל שדה יש לו מספר סידורי קבוע שלא משתנה גם אם משנים את שם ה-API, אז עדיף לבסס משתנים על המספר. דוד עבר על הדקויות מהשטח - איך שדה HTML נערך רק דרך Make, איך כל תבנית היא מופע נפרד שאפשר לערוך לפני שליחה. העיקרון הרחב: מפרידים בין התוכן (התבנית) לבין הנתונים (הלקוח), והמערכת מחברת ביניהם ברגע האמת. ככה הודעה אחת משרתת אלף לקוחות, כל אחד מרגיש שכתבו לו.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
טפסים שמעדכנים מופע קיים
דוד נגע בטעות שכל מי שעבד עם טפסים מכיר: לקוח ממלא טופס, ובמקום לעדכן את הרשומה הקיימת שלו נוצרת כפילות. הפתרון שלו פשוט ומדויק: בכל ישות בונים טופס, בוחרים שדות, אפשר להזריק CSS לעיצוב, ומעתיקים את הכתובת. כברירת מחדל טופס יוצר מופע חדש - אבל כשמוסיפים בסוף הכתובת את ה-ID של מופע קיים, ההגשה מעדכנת אותו ישירות במקום לשכפל. אפשר אפילו להעלות קבצים דרך הטופס ולקשר לליד, ולהפעיל לוגיקה על מה שנשלח. זה ההבדל בין טופס שיוצר בלגן לטופס ששומר על מסד נתונים נקי - כל לקוח והרשומה האחת שלו, לאורך זמן.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
אבחון: מה ראוי לאוטומציה לעומת מערכת
ואת הסשן דוד סגר בהחלטה שכל בונה מערכות מתמודד איתה: מה פותרים בתוך המערכת ומה דרך כלי אוטומציה חיצוני כמו Make. המערכת לבדה כבר חזקה - כפתורים, וובהוקים, אימותים, cron, נוסחאות, הרשאות. אבל יש דברים שרק Make עושה: עריכת שדות HTML, מניעת התנגשויות (פגישה בשעה תפוסה), סריקת מייל נכנס, שליחת וואטסאפ. הכלל שלו: מינימום תלות חיצונית, אבל איפה שצריך - Make הוא הזרוע. הוא גם חשף מגבלה עדינה: שלושה סוגי שדות (מטא-דאטה, נוסחה, מצביע) הם 'תצוגה בלבד' ואי אפשר לבסס עליהם טריגר, ולכן הטריק של שדה תאריך יומי ב-cron. זו החשיבה שמפרידה בין מי שבונה מערכת שעובדת למי שנתקע: לדעת את גבולות הכלי, ולתכנן עקיפה לפני שנתקעים.
ההמשך המלא של הפרומפט שמור לחברי אוטוטיוזדיי פלוס יחד עם ההקלטה והתמלול המלאים של הסשן
שורות ההמשך כוללות את כל ההנחיות המדויקות והדוגמאות שהוצגו בשידור החי מול הקהילה
🎯 מה עושים עם זה עכשיו?
קראת איך זה נעשה. עכשיו קחו את הכלים ותעשו את זה בעצמכם - כל הפרומפטים של הסשן, מוכנים להריץ על העסק שלכם. פלוס ההקלטה המלאה והתמלול.
הצטרפו לאוטוטיוזדיי+· 49 ש״ח בחודשעוד לא בשלים? בואו ללייב הבא בחינם ←רוצים לעבוד על התמלול הנקי?
העתיקו אותו ותעבדו איתו איך שנוח לכם.
🔒 התמלול המלא שמור לחברי אוטוטיוזדיי+. עם המנוי אתם מעתיקים אותו בקליק ועובדים איתו איך שנוח לכם.
לפתוח את התמלול · 49 ש״ח בחודששאלות ששאלתם (וה-AI ישאל גם)
מה ההבדל בין ישות מקושרת לשדה בחירה?
שדה בחירה הוא מקומי בתוך הרשומה ולא מקשר לשום מקום. ישות מקושרת מאפשרת להגיע מכל מקום לכל דבר ולנתח נתון בפני עצמו. כלל: כל דבר שתרצו לנתח = ישות, דבר זניח ומקומי = שדה.
מתי כדאי CRM מודולרי במקום טבלאות פשוטות?
כשיש כמה סוגי נתונים שצריך לחבר ולנתח (לקוחות, לידים, עסקאות, תשלומים), תהליכים אוטומטיים, טפסים והרשאות. טבלה פשוטה מספיקה רק לעסקה חד-פעמית פשוטה.
מה זה מקור אמת אחד במערכת?
ישות אחת עם מופע יחיד שמחזיקה שדות שליטה גלובליים. כל המערכת שואבת מהם, אז כדי לשנות התנהגות בכל מקום מעדכנים שדה אחד במקום עשרות רשומות.
מה עושים בתוך ה-CRM ומה צריך Make?
המערכת לבדה נותנת כפתורים, וובהוקים, אימותים, cron ונוסחאות. Make נדרש לדברים כמו עריכת HTML, מניעת התנגשויות, סריקת מייל נכנס ושליחת וואטסאפ. הכלל: מינימום תלות חיצונית.
💬 הדיון על הסשן
שאלות, תובנות, מה יישמנו - השרשור של הקהילה.
עוד אין תגובות - תהיו הראשונים לפתוח את הדיון 👇
