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

1לפני שמתחילים: מה בונים ומה משאירים בחוץ

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

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

2דרישות מקדימות

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

3שלב 1: מגדירים את מסלול הפנייה לפני יצירת המסכים

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

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

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

4שלב 2: מגדירים את הנתונים ואת גבולות ההדמיה

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

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

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

5שלב 3: בונים טופס פתיחת פנייה שאפשר לבדוק

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

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

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

6שלב 4: יוצרים תור טיפול ושיוך לאחראים

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

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

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

7שלב 5: מוסיפים תיעוד טיפול ומעקב ברור

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

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

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

8שלב 6: מפרידים בין הצעת סגירה לאישור סגירה

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

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

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

9שלב 7: מתרגלים פתיחה מחדש בלי לאבד את ההיסטוריה

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

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

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

10שלב 8: בודקים הפרדה בין פונים למטפלים

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

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

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

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

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

12צ'קליסט מסירה: היכן עוצרים ומה עושים בהמשך

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

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

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