בניית CRM עם Lovable: מתהליך מכירה לאב־טיפוס שאפשר לבדוק

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

בתיעוד ההתחלה של Lovable מתואר תהליך שבו מנסחים בשפה רגילה מה רוצים לבנות [1]. כאן נשתמש בגישת vibe coding כתרגיל עבודה: מנסחים דרישה, בוחנים את התוצאה ומבקשים תיקון ממוקד. תיאור כתוב הוא נקודת פתיחה לבנייה, לא הוכחה לכך שהמערכת שנוצרה עומדת בדרישות.

1דרישות מקדימות: מה להכין לפני פתיחת הפרויקט

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

2שלב 1: מגדירים תהליך מכירה לפני שמגדירים מסכים

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

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

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

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

3שלב 2: מגדירים שדות וקשרים בין הרשומות

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

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

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

4שלב 3: ממלאים תבנית אפיון קצרה

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

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

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

5שלב 4: כותבים פרומפט בנייה עם גבולות ברורים

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

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

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

6שלב 5: בודקים שהמסכים משרתים החלטות ופעולות

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

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

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

7שלב 6: מריצים תרחישי בדיקה עם נתונים מדומים

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

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

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

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

8שלב 7: מגדירים ובוחנים דרישות הרשאה בסיסיות

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

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

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

9שלב 8: מסכמים בדיקת משתמשים ומחליטים על ההמשך

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

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

10טעויות נפוצות שכדאי למנוע

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

11צ'קליסט סיום והצעד הבא

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

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