לא רק מועד סיום: בנו עם Lovable מערכת שמובילה להחלטת חידוש חוזה

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

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

1דרישות מקדימות: מגדירים סביבת הדגמה ותהליך אנושי

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

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

2שלב 1: כתבו את גבולות המערכת ב־Project knowledge

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

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

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

3שלב 2: הגדירו כרטיס חוזה עם בעלות ומועדים נפרדים

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

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

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

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

4שלב 3: בקשו שמירה אמיתית של נתוני ההדגמה

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

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

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

5שלב 4: בנו תור החלטות, לא רק רשימת תאריכים

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

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

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

6שלב 5: הפרידו החלטת חידוש מביצוע ההחלטה

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

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

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

7שלב 6: שמרו היסטוריה כשפותחים מחזור חוזה חדש

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

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

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

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

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

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

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

9שלב 8: בצעו סימולציה ניהולית ועצרו בגבול האב־טיפוס

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

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

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

10טעויות נפוצות שכדאי לתקן לפני ההדגמה

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

11צ'קליסט לסיום האב־טיפוס

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

12הצעד הבא: התאמת התהליך לארגון

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