גילוי נאות: המדריך כולל קישורי שותפים ל-Base44. הרשמה דרכם אינה מייקרת לך דבר. חלק מהקישורים למטה יוחלפו בקישורי Impact כשיהיו מוכנים.
[התחל ב-Base44, יוחלף בקישור Impact]
שער 14, Workspaces, חשבון וצוות
מרגע שיותר מאדם אחד נוגע במערכת, הסדר מפסיק להיות עניין אסתטי והופך לשאלה של כסף והרשאות. השער הזה מסביר מה זה Workspace, מי רואה מה, ואיפה בדיוק יושב החיוב.
רוב האנשים מתחילים ב-Base44 לבד: פותחים חשבון, בונים אפליקציה, ולא חושבים על מבנה ארגוני. זה עובד מצוין עד הרגע שבו מצטרף שותף, עובד או לקוח, ואז מתברר שכל ההחלטות שנדחו חוזרות ביחד: מי הבעלים, מאיזה כיס יוצאים הקרדיטים, ומי מורשה לפרסם לאוויר.
ה-Workspace הוא המיכל שמכיל את הכל, אפליקציות, חברי צוות, הגדרות וחיוב. השער הזה עובר על המבנה הזה לפי הסדר: מהגדרת ה-workspace עצמו, דרך תפקידים והרשאות, ארגון האפליקציות, תבניות וסקילים ארגוניים, ועד המסכים שבהם רואים בדיוק לאן הקרדיטים הולכים. אם אתה עובד לבד היום אבל מתכוון לגדול, זה הפרק שמשתלם לקרוא לפני ולא אחרי. הפרק אינו דורש ידע טכני, והוא רלוונטי גם למי שמנהל את הצוות ולא בונה בעצמו.
14.1 מה זה Workspace
רמה: בסיס
Workspace הוא המיכל הראשי של Base44: הוא מחזיק את האפליקציות, את חברי הצוות, את ההגדרות ואת החיוב. כשנרשמים, נפתחת סביבת עבודה אישית אוטומטית, וכל אפליקציה שתיצור תשב בתוכה.
מה משותף בין אפליקציות באותה סביבה:
- מאגר קרדיטים אחד. כל החברים מושכים מאותו מאגר, ואפליקציה צורכת את הקרדיטים של הסביבה שבה נוצרה, בלי קשר לשאלה מי עובד עליה כרגע.
- תוכנית וחיוב. לכל סביבה תוכנית משלה. קרדיטים לא עוברים בין סביבות, ופעילות באחת לא משפיעה על היתרה באחרת.
- חברים ותפקידים. Owner אחד שאחראי על חיוב, חברים, הגדרות ואפליקציות. Admin שמנהל חברים והגדרות אך לא חיוב, וזמין בתוכנית הארגונית. Editor שיכול לעבוד על אפליקציות שהוזמן אליהן. Viewer שרואה בלבד ולא משתמש בצ'אט. Guest שיכול לערוך אפליקציות שהוזמן אליהן אבל לא ליצור חדשות ולא לגעת בהגדרות הסביבה.
מתי לפצל לכמה סביבות: כשיש הפרדה אמיתית של כסף או של אחריות. סוכנות שיווק בתל אביב שעובדת מול שמונה לקוחות ורוצה שכל לקוח ישלם על עצמו, או בית ספר שמפריד בין סביבת ההוראה לבין המערכות הפנימיות שלו. אפשר להחזיק עד ארבע סביבות בבעלותך, כולל האישית שנפתחה בהרשמה, אבל אין הגבלה על מספר הסביבות שאחרים מזמינים אותך אליהן.
נקודה שמבלבלת צוותים ישראליים כמעט תמיד: חבר בסביבה שלך לא צריך תוכנית בתשלום משלו כדי לעבוד על האפליקציות שלך. הוא צריך תוכנית רק כדי להחזיק סביבה משלו. זה אומר שאפשר לצרף עובדים ופרילנסרים בלי שכל אחד ירכוש מנוי. [התחל ב-Base44, יוחלף בקישור Impact].
לפני שפותחים סביבה נוספת, שתי שאלות. הראשונה: מי משלם. הבעלים של הסביבה הוא זה שמחזיק את התוכנית ואת אמצעי התשלום, ולכן סביבה שפתח עובד שעזב הופכת במהירות לבעיה. השנייה: מה קורה כשצריך להעביר אפליקציה בין סביבות. זה אפשרי, אבל זו פעולה שדורשת הרשאות ותיאום ולא משהו שרוצים לעשות כל חודש. לכן ההמלצה הפשוטה היא להתחיל בסביבה אחת, לפצל רק כשמופיעה סיבה עסקית ברורה, ולוודא שהבעלות רשומה על מי שאמור להחזיק אותה לאורך זמן.
שים לב: הטעות הנפוצה היא לפתוח סביבת עבודה נפרדת לכל אפליקציה ואז לגלות שהקרדיטים מפוזרים ולא עוברים ביניהן, אז פצל רק כשיש הפרדה אמיתית של חיוב או של אחריות.
בתיעוד הרשמי: About workspaces
14.2 ניהול חברים והרשאות
רמה: מתקדם
הזמנת אנשים לסביבת העבודה היא הרגע שבו הכאוס מתחיל או נמנע. יש שלוש דרכים להזמין, וכל אחת מתאימה למצב אחר.
- הזמנה במייל לאדם בודד. ההזמנה תקפה לתקופה מוגבלת, והמוזמן צריך לאשר אותה ולהתחבר כדי להצטרף בפועל.
- העלאת קובץ CSV עם כתובות מייל ותפקיד אופציונלי לכל שורה. שורה בלי תפקיד מקבלת את ההרשאה הנמוכה ביותר כברירת מחדל, וזו התנהגות בטוחה שכדאי לנצל כשמצרפים כיתה שלמה.
- קישור הזמנה, שרק בעלים ומנהלים יכולים לייצר. הקישור פג אחרי תקופה קצובה שניתנת להארכה, ואפשר להגביל את מספר השימושים בו ואף לקשור אותו לדומיין מסוים.
ההגבלה לדומיין היא הפיצ'ר שהכי מפספסים. בית ספר או ארגון שמפיץ קישור הצטרפות בקבוצת וואטסאפ צריך להגביל אותו לדומיין הארגוני, אחרת מספיק שמשתתף אחד יעביר את הקישור הלאה.
ההרשאות עצמן עובדות בשתי רמות: תפקיד ברמת הסביבה, והזמנה ספציפית לכל אפליקציה. Editor הוא לא מישהו שרואה הכל, הוא צריך להיות מוזמן לכל אפליקציה בנפרד. Viewer רואה רק אפליקציות שהוזמן אליהן, לא עורך ולא משתמש בצ'אט, ולכן גם לא שורף קרדיטים. פרילנסר שמגיע לפרויקט אחד מתאים לתפקיד Guest, שאפשר לקדם ל-Editor או ל-Viewer בהמשך.
בניהול השוטף אפשר לשנות תפקיד מתוך רשימת החברים, לבצע פעולה על קבוצה גדולה של חברים בבת אחת, לייצא את הרשימה לקובץ, ולהאריך או למחוק קישורי הזמנה קיימים. הסרת חבר מבטלת את הגישה שלו לסביבה ולכל האפליקציות שבה. העבודה עצמה לא הולכת לאיבוד, כי האפליקציות שייכות לסביבה ולא לאדם שיצר אותן.
כלל עבודה שמונע את רוב התקלות: תן לכל אדם את ההרשאה הנמוכה ביותר שמאפשרת לו לעשות את העבודה, והעלה אותה רק כשמתברר שהיא לא מספיקה. קל להעלות הרשאה, ולא נעים לשאול מישהו למה הוא נגע באפליקציה של לקוח אחר. בסוכנות ישראלית טיפוסית המבנה נראה כך: הבעלים מחזיק את החיוב, מנהל הפרויקט הוא Editor עם גישה לכל אפליקציות הלקוחות, מעצבת חיצונית מקבלת Guest לאפליקציה אחת בלבד, ולקוח שרוצה לעקוב מקבל Viewer. כך אף אחד לא רואה יותר ממה שהוא צריך, והחשבון החודשי לא מושפע ממי שרק מסתכל.
שים לב: הטעות הנפוצה היא להפיץ קישור הזמנה פתוח בקבוצה ולגלות בתוך הסביבה אנשים שאיש לא הזמין, אז הגבל כל קישור לדומיין, למספר שימושים ולתקופה קצרה.
בתיעוד הרשמי: Workspace members
14.3 ניהול האפליקציות ב־Workspace
רמה: מתקדם
עמוד האפליקציות הוא המקום שבו סביבת עבודה נשארת מסודרת או מתפרקת. אחרי עשרים אפליקציות, החיפוש אחרי "איפה זה היה" עולה יותר זמן מהבנייה עצמה.
הכלים שקיימים: תיקיות לקיבוץ אפליקציות, כאשר אפליקציה יכולה לשבת בתיקייה אחת בלבד והתיקיות גלויות לכל חברי הסביבה. חיפוש שמכסה שם, תיאור, יוצר, מייל הבעלים ומזהה האפליקציה. סינון בין אפליקציות שיצרת לבין כל האפליקציות, מיון לפי עריכה אחרונה, יצירה אחרונה, שם או מספר מבקרים, ומעבר בין תצוגת רשת לתצוגת רשימה.
קונבנציית שמות שמחזיקה לאורך זמן בנויה משלושה חלקים: לקוח או מחלקה, סוג המערכת, וסביבה. למשל "כהן נדלן CRM" לצד "כהן נדלן CRM בדיקות". כשמחפשים לפי שם הלקוח הכל נופל יחד, וכשעובד חדש נכנס לצוות לא צריך להסביר לו מה זה "אפליקציה 3".
שינוי שם מתבצע מעמוד האפליקציות דרך תפריט הפעולות הנוספות. שים לב שהשינוי מעדכן גם את כתובת האפליקציה, כך שכל מי שקיבל את הקישור הישן צריך לקבל את החדש.
העברת אפליקציה בין סביבות דורשת שהאפשרות תהיה מופעלת בסביבה הנוכחית, ובעל הסביבה הוא שמבצע אותה. הכתובת של האפליקציה לא משתנה ואין צורך לפרסם מחדש. העברת בעלות היא פעולה נפרדת: רק הבעלים הנוכחי מבצע אותה, והמקבל חייב להיות כבר שותף בהרשאת עריכה ומעלה.
מחיקה היא החלק שצריך לקרוא פעמיים. אפליקציה שנמחקה יורדת מיד מהאוויר, עוברת לאזור הנמחקים לתקופה מוגבלת ואז נעלמת לצמיתות. בינתיים המשאבים החיצוניים משתחררים: דומיינים מותאמים, חיבורי אינטגרציות וקונקטורים, אוטומציות והפניות עמודים, תהליכים וקמפיינים. הדאטה, העמודים ופונקציות השרת ניתנים לשחזור בתוך חלון הזמן, אבל את החיבורים החיצוניים תצטרך לחבר מחדש ביד.
עוד הרגל קטן שמשתלם: ארכוב לוגי במקום מחיקה. אפליקציה שסיימה את תפקידה יכולה לעבור לתיקייה ייעודית ולקבל קידומת ארכיון בשם, ולהישאר במקומה בלי להפריע לאף אחד. זה לא עולה קרדיטים כל עוד איש לא מפעיל אותה, ושומר לך את הקוד, את הנתונים ואת ההיסטוריה ליום שבו לקוח יחזור ויבקש לחדש את המערכת שלו. מחיקה, לעומת זאת, משחררת גם את הדומיין שלו, ואת זה כבר לא תמיד אפשר להחזיר.
שים לב: הטעות הנפוצה היא למחוק אפליקציה כדי לנקות סדר ולגלות שהדומיין והחיבורים החיצוניים שוחררו, אז העבר אותה לסביבה אחרת או הפוך אותה לפרטית במקום למחוק.
14.4 תבניות Workspace
רמה: מתקדם
תבנית workspace הופכת אפליקציה גמורה לנקודת פתיחה חוזרת. בניגוד לתבניות בחנות הציבורית, תבנית פנימית גלויה רק לחברי הסביבה ולא עוברת תהליך אישור חיצוני.
מה נשמר בתבנית: המבנה, העיצוב והפונקציונליות של האפליקציה. החלק המעניין הוא דווקא הסודות. בעת יצירת התבנית אתה בוחר אילו מפתחות וחיבורי אימות יעברו לעותקים ואילו לא. עותק חדש מקבל רק את מה שסימנת, ולכל השאר המשתמש יצטרך להזין פרטים משלו. זו ההחלטה שמפרידה בין תבנית פנימית לצוות לבין תבנית שמחלקים ללקוחות.
התהליך בקצרה:
- לפרסם את האפליקציה. בלי פרסום אי אפשר ליצור ממנה תבנית.
- להיכנס להגדרות האפליקציה, לבחור יצירת תבנית ולסמן שהיא מיועדת לסביבת העבודה בלבד.
- לתת שם, תיאור וקטגוריות.
- להגדיר אילו סודות עוברים לעותקים.
- להעלות תמונות מסך, כאשר הראשונה היא תמונת השער ביחס רוחב-גובה של 16:9.
היצירה דורשת תוכנית בדרגת Builder ומעלה, והקמת הרישום עצמו שמורה למנהלי הסביבה. השימוש פשוט יותר: נכנסים לעמוד התבניות, ללשונית התבניות שלי, ובוחרים ליצור אפליקציה חדשה מהתבנית, לצפות באפליקציית המקור, או לנהל את הרישום ולעדכן אותו.
כאן זה מתחיל להשתלם באמת. סוכנות דיגיטל שמקימה לכל לקוח את אותה מערכת ניהול לידים מפסיקה לשכפל ביד ולשכוח חצי מההגדרות. בית ספר לשיווק דיגיטלי מקפיא אפליקציית תרגיל אחת ונותן לכל מחזור תלמידים להתחיל מאותה נקודה, במקום שכל תלמיד יבנה בסיס שונה ואז ייתקע במקום אחר. עדכונים לאפליקציית המקור מתפרסמים כרגיל, ושינוי פרטי הרישום נכנס לתוקף מיד בלי המתנה לאישור.
מה שכדאי לוודא לפני שמקפיאים תבנית: שהאפליקציה שממנה אתה יוצר אותה נקייה מנתוני אמת. תבנית נועדה להיות נקודת פתיחה, לא להעביר בטעות רשומות של לקוח אחד לעותק של לקוח אחר. בנה אפליקציית מקור ייעודית עם נתוני דוגמה בלבד, תחזק אותה בנפרד, והתייחס אליה כאל מוצר פנימי לכל דבר. הפיתוי לקחת את האפליקציה של הלקוח הראשון ולהפוך אותה לתבנית גדול, והוא גם מקור התקלה הנפוצה ביותר בשיטה הזאת, במיוחד כשהאפליקציה כבר רצה חודשיים בפרודקשן.
שים לב: הטעות הנפוצה היא לכלול בתבנית את כל מפתחות ה-API כדי לחסוך עבודה בהקמה, אז סמן רק את הסודות שבאמת מיועדים לשיתוף, כי כל עותק שייווצר מהתבנית יקבל אותם.
בתיעוד הרשמי: Workspace templates
14.5 Workspace Skills
רמה: מתקדם
Workspace Skill הוא מסמך הוראות שנשמר ברמת סביבת העבודה ומעצב את האופן שבו הצ'אט בונה אפליקציות. במקום להדביק את אותן הנחיות מיתוג בכל שיחה חדשה, כותבים אותן פעם אחת וכל אפליקציה בסביבה יורשת אותן, לכל מי שמורשה לעבוד שם.
ההוספה נעשית מהגדרות הסביבה, במדור התוספים, תחת סקילים. אפשר להתחיל מדף ריק או מתבנית מוכנה. סקיל מורכב משלושה חלקים: שם קצר, למשל brand-guidelines, תיאור שמסביר למערכת מתי להשתמש בו, והוראות צעד אחר צעד. ההנחיה בתיעוד היא לכתוב כמו שמדריכים עובד חדש ולא כמו שכותבים מפרט טכני. אפשר גם לתת ל-AI לחדד את הניסוח לפני השמירה. היצירה דורשת תוכנית בדרגת Builder ומעלה, ויש תקרה של מאה סקילים לסביבה.
מה כדאי להכניס לסקיל ארגוני:
- מיתוג: פלטת צבעים, טיפוגרפיה, שימוש בלוגו, סגנון כפתורים ומרווחים.
- שפה: עברית או אנגלית, פנייה בלשון זכר או נקבה, יחיד או רבים, וטרמינולוגיה קבועה. עסק ישראלי שבונה ממשקים בעברית ירוויח מהנחיה מפורשת על כיווניות RTL ועל ניסוח הודעות שגיאה בעברית תקינה.
- כללי קוד ומבנה: קונבנציות שמות לישויות, מבנה עמודים קבוע, ודפוסי טפסים חוזרים.
עדכון סקיל משפיע על עבודה שנעשית מכאן והלאה, ולא משכתב אפליקציות שכבר נבנו. אם שינית מיתוג, עדיין תצטרך לעבור על האפליקציות הקיימות ולבקש את השינוי בכל אחת.
מגבלה שצריך להפנים: סקיל הוא טקסט סטטי. הוא לא ניגש לנתונים חיים ולא אוכף סטנדרט ברמת הפלטפורמה. אם אתה צריך שהמערכת תקרא מידע עדכני ממקור חיצוני, החיבור הנכון הוא MCP ולא סקיל. וסקיל לא מחליף בדיקה, הוא משפר את הסיכוי שהתוצאה תצא נכון, לא מבטיח אותה.
דרך טובה להתחיל: במקום לנסח סקיל מאפס, קח שלוש אפליקציות שכבר בנית וכתוב מה חזר בהן בכל פעם. אילו הנחיות הדבקת שוב ושוב, מה תיקנת ידנית אחרי כל בנייה, ואיזה שינוי ביקשת בכל פרויקט מחדש. זו רשימת הכללים האמיתית של הארגון שלך, להבדיל מהרשימה שאתה חושב שהיא נכונה. אחרי שכתבת אותה, תריץ אפליקציה חדשה אחת ותראה מה עדיין היית צריך לתקן ביד, וזה יהיה הסקיל השני.
שים לב: הטעות הנפוצה היא להעמיס סקיל אחד עם כל כללי הארגון, אז פצל לפי תחום, מיתוג, שפה וכללי קוד בנפרד, כדי שהמערכת תדע מתי להשתמש בכל אחד מהם.
בתיעוד הרשמי: Workspace skills
14.6 חיוב, קרדיטים והגדרות חשבון
רמה: בסיס
הכסף ב-Base44 יושב ברמת סביבת העבודה, לא ברמת המשתמש. לכל סביבה תוכנית משלה, מאגר קרדיטים משלה והיסטוריית חיוב משלה. לכן השאלה הראשונה בארגון היא לא "איזו תוכנית" אלא "כמה סביבות ומי הבעלים של כל אחת".
הקרדיטים מתחלקים לשניים, וזה ההבדל שמפתיע אנשים בחשבון הראשון. קרדיטי הודעות נצרכים כשאתה מבקש מה-AI לבנות, לתקן או לשכתב, והצריכה נקבעת לפי כמות העבודה שהמערכת עושה ולא לפי אורך הבקשה. שינוי טקסט קטן עולה שבריר קרדיט, שינוי רוחבי באפליקציה עולה כמה. קרדיטי אינטגרציה נצרכים כשהאפליקציה עצמה מפעילה שירותים מובנים: שליחת מייל, יצירת תמונה, קריאה למודל שפה או הפעלת סוכן. קריאה לשירות חיצוני עם מפתח API שלך לא נצרכת מהמאגר הזה.
המעקב קיים בשתי רמות. בהגדרות הסביבה יש מסך צריכת קרדיטים עם היתרה וגרף לאורך זמן, ובלוח הבקרה של כל אפליקציה יש פירוט הצריכה שלה ומאיזה מקור היא הגיעה. אפשר גם לראות כמה עלתה הודעה בודדת. עסק שמריץ שלוש אפליקציות באותה סביבה חייב את הפירוט הזה, אחרת לא ידע איזו מהן שורפת את התקציב.
מחזור החיים של התוכנית: שדרוג נכנס לתוקף מיד עם התשלום, הורדת דרגה נכנסת לתוקף בסוף מחזור החיוב, וביטול עוצר חידושים עתידיים אבל לא מזכה על התקופה שכבר שולמה. השירות מוגדר כלא בר-החזר, ופניות חריגות נבחנות פרטנית מול התמיכה. חשבוניות זמינות לבעל הסביבה בהיסטוריית החיוב. קרדיטים שלא נוצלו אינם נצברים לחודש הבא. [בדוק תוכניות Base44, יוחלף בקישור Impact].
בהגדרות האישיות יושבים הפרטים שלך, מפתח ה-API לשימוש בכלים חיצוניים, אימות דו-שלבי והעדפות התראות. אחרי החלפת מפתח API, עדכן כל סקריפט או אינטגרציה שהשתמשו בישן, אחרת הם פשוט יפסיקו לעבוד.
ולבסוף, המלצה תקציבית לעסק ישראלי קטן: אל תבחר תוכנית לפי מספר הקרדיטים בדף המחירים, אלא לפי חודש עבודה אמיתי. תתחיל בתוכנית נמוכה, תעבוד חודש שלם, ואז תסתכל על מסך הצריכה. ההפרש בין ההערכה המוקדמת למציאות גדול אצל רוב האנשים, ולשני הכיוונים. ממילא שדרוג נכנס לתוקף מיד, אז אין שום יתרון בלשלם מראש על תוכנית גדולה שאולי לא תנצל.
שים לב: הטעות הנפוצה היא לגלות את צריכת הקרדיטים רק כשהיא נגמרת באמצע עבודה, אז פתח את מסך הצריכה פעם בשבוע ובדוק איזו אפליקציה צורכת מה לפני שזה הופך להפתעה.
בתיעוד הרשמי: Account settings
[התחל ב-Base44, יוחלף בקישור Impact]
