צוות תפעול צריך טופס פנייה. צריך להחליט מה לשאול, מתי צריך שאלת המשך, ומי מקבל את המידע אחרי השליחה. על המסך רואים שדות וכפתור. העבודה האמיתית נמצאת בחיבורים ביניהם. ב-Formalingo, מוצר שאנחנו בונים ומפעילים ב-DevShift, אפשר לראות איך ההחלטות האלה מקבלות צורה בתוכנה.
מבט על המימוש לפי קוד מקומי שנבדק ב-3 בנובמבר 2026. הסקירה אינה מאמתת את גרסת הפריסה של האתר הציבורי ואינה מציגה תוצאות של לקוחות.
מתחילים בעבודה שמחכה אחרי השליחה
טופס הוא שלב בתוך תהליך. מי שממלא אותו רוצה לסיים ולהמשיך הלאה. מי שמקבל את התשובות צריך מספיק מידע כדי לעשות את הפעולה הבאה. אלה שתי נקודות מבט שונות, ושתיהן צריכות מקום בתכנון. עוד שדה יכול לעזור לצוות המטפל, אבל גם להוסיף עבודה לכל מי שמגיע לטופס.
לכן, כשאנחנו ניגשים לבעיה כזאת, אנחנו מתחילים בשאלה מעשית: איזו החלטה תתקבל בעזרת כל תשובה? כך אפשר לדבר על מה שחסר, על מידע שכבר קיים ועל שאלות שרלוונטיות רק בחלק מהמקרים. זו דרך לבחון את המוצר עוד לפני שבוחרים את סדר השדות או את הצבע של הכפתור.
במימוש של Formalingo יש שלושה חיבורים שכדאי להתעכב עליהם: מהבקשה לתוכנית, מהתוכנית לשאלות שמתנהגות נכון, ומהשלמת הטופס להעברת המידע הלאה. עמוד המוצר של Formalingo מציג את התמונה הרחבה. כאן ניכנס להחלטות שמאחורי החוויה הזאת.
המסך הראשון הוא תוכנית שאפשר לשנות
בקשה בשפה חופשית משאירה מקום לפרשנות. שם של טופס עדיין לא אומר אילו שאלות צריכות להופיע בו, מה חובה למלא או מתי נדרש פירוט. ב-Formalingo יש שלב תכנון בשיחה: ה-AI מציע תוכנית, יכול לשאול שאלות הבהרה, והאדם שיוצר את הטופס יכול להמשיך לדייק אותה.
ההפרדה קיימת גם מאחורי המסך. למתכנן יש כלי לבקשת תשובות מאדם, ואין לו כלי שכותב את הטופס. יצירת הטופס מתחילה בפעולה מפורשת של יוצר הטופס, בלחיצה על Build Form. כך הפירוש של הבקשה מופיע כשלב שאפשר לקרוא ולשנות, לפני שהוא הופך למבנה של שאלות.
יש גם אפשרות Build Form Anyway. כלומר, המוצר נותן הזדמנות לבדיקה ולהבהרה, אבל לא מחייב אישור מעמיק של כל פרט. מבחינתנו, הלקח התכנוני הוא לתת לאדם משהו מוגדר שאפשר לתקן. תוכנית גלויה מאפשרת לומר מה חסר; היא לא מוכיחה שה-AI הבין הכול.
מדריך יצירת הטפסים הציבורי מתאר גם את השלבים של הוספת שאלות ופרסום טופס.
שאלת ההמשך צריכה להתאים לתשובה עכשיו
אחרי שיש שאלות, צריך לקבוע איך הן קשורות זו לזו. לוגיקה מותנית מאפשרת להציג או להסתיר שאלה בהתאם לתשובה קודמת. החלק המעניין מתחיל כשמישהו משנה את דעתו: הטופס צריך להתאים את עצמו למצב החדש, כולל המשמעות של תשובות שכבר נכתבו.
דוגמה להמחשה בלבד: בטופס פנייה נשאלת השאלה ״איך ליצור קשר?״ עם האפשרויות ״אימייל״, ״טלפון״ ו״אחר״. בחירה ב״אחר״ פותחת את השאלה ״באיזו דרך ליצור קשר?״. אם הוגדרה כחובה, נדרש פירוט במסלול הזה. מעבר בחזרה ל״אימייל״ מסתיר אותה, ולכן הפירוט כבר אינו נדרש במסלול הנוכחי.
במימוש שבדקנו, הדפדפן מנקה תשובה כאשר השאלה שלה הופכת למוסתרת. זה חשוב גם למי שמטפל בפנייה: בלי טיפול במעבר הזה, בחירה מעודכנת ופירוט ישן עלולים לספר שני סיפורים שונים. כאן ההחלטה על נראות משפיעה גם על התשובה שנמצאת בדפדפן, ולא רק על השטח שתופסת השאלה במסך.
תיעוד הלוגיקה המותנית מציג את מנגנון כללי ההצגה וההסתרה.
בשליחה בודקים מחדש מה באמת חובה
הדפדפן הוא המקום שבו ממלאים את הטופס. ההחלטה אם אפשר להשלים אותו מתקבלת גם בשרת. אם כל צד יפרש את התנאים בדרך אחרת, אפשר להגיע למצב מתסכל: המסך מאפשר להמשיך, אבל השליחה נדחית בגלל שאלה שלא הייתה רלוונטית.
Formalingo משתמש באותו מנגנון להערכת הכללים בדפדפן ובשרת. בעת השלמת הטופס, השרת מחשב מחדש אילו שאלות גלויות, מוציא תשובות לשאלות מוסתרות מהבדיקה, ובודק את שאלות החובה הפעילות. כשחסרות תשובות, הוא מחזיר את שמות השאלות החסרות כדי שאפשר יהיה להבין מה צריך להשלים.
בדוגמה שלנו, הדרישה לפירוט תלויה בבחירה הנוכחית. אין טעם לבקש תשובה לשאלה שהמסלול הנוכחי הסתיר. זהו פרט קטן לכאורה, אבל הוא מחבר בין מה שהאדם רואה לבין התנאים שהמערכת אוכפת. הלקח שלנו לפיתוח מוצר: כדאי לשתף את כלל ההחלטה בין הצדדים, ולבצע את הבדיקה שוב במקום שבו מאשרים את ההשלמה.
״הטופס הושלם״ ו״המידע הגיע״ הם שני מצבים
בסוף המילוי מגיעה נקודת מעבר נוספת. התשובה יכולה להיות שלמה מבחינת הטופס, בזמן שהמערכת הבאה עדיין לא אישרה שקיבלה אותה. אם מחברים את שני הדברים לסטטוס יחיד, קשה לדעת איפה העבודה נעצרה ומי צריך לטפל בה.
ב-Formalingo, עדכון סטטוס ההשלמה, רישום אירוע ההשלמה ורישום ההעברה לאינטגרציה נשמרים יחד בעסקה אחת במסד הנתונים. כך ההשלמה והרישום שצריך להמשיך ממנה נוצרים כיחידה אחת. בדיקת השלמה חוזרת נשענת על אותו זיהוי של אירוע ההשלמה, במקום להתייחס לכל בדיקה כאל אירוע עסקי חדש.
נרשמה השלמת הטופס, יחד עם האירוע וההעברה שנדרשים להמשך התהליך.
זהו מצב נפרד. הטיפול בהעברה יכול להיות ממתין, הושלם או לא ידוע.
מה עושים אם החיבור נותק לפני שהתקבל אישור? ייתכן שהמערכת הבאה קיבלה את המידע, וייתכן שלא. הלקח התכנוני הוא לבדוק את מצב היעד לפני שמחליטים לשלוח שוב. הודעת ניתוק לבדה אינה הוכחה שלא קרה דבר. זו החלטה שצריך לתכנן במפורש, לצד האפשרות לסמן שהמצב עדיין אינו ידוע.
תיעוד אירועי העבודה והחיבורים מציג איך אירועים כמו השלמת טופס יכולים להודיע למערכת אחרת. השלמה מקומית ואישור חיצוני נשארים שתי עובדות שונות.
כשצריך תיקון, אומרים מה צריך לתקן
לא כל קלט מתאים להתחיל ממנו. בתכנון טופס מתוך קובץ, המימוש בודק מצבים כמו קובץ חסר, סוג שאינו נתמך, קובץ גדול מדי או תוכן ריק או בלתי קריא. אלה נקודות שבהן צריך לעצור את הניסיון ולתת הסבר, במקום להציג טופס שנראה משכנע בלי בסיס שימושי.
החיבור לשאלות החובה דומה: כשמשהו חסר, עדיף לדעת איזו שאלה דורשת השלמה. שם של שאלה נותן כיוון להמשך. הודעה כללית שמשהו השתבש משאירה לאדם לנחש. מבחינתנו, איכות ההסבר היא חלק מההתנהגות של המוצר, לצד המסלול שבו הכול מצליח.
חשוב גם להפריד בין מידע שכבר ידוע לבין מידע שצריך לבקש. מדריך הנמענים והמילוי המקדים מתאר קישורים אישיים ואפשרות לתשובות שמולאו מראש. בתכנון תהליך, זו הזדמנות לבדוק מה באמת נחוץ לשאול שוב, ומה צריך לאפשר לאדם לבדוק ולעדכן.
לפני שבונים עוד מסך, בודקים את הצעד הבא
החוט שמחבר את ההחלטות האלה הוא היכולת להבין מה קורה עכשיו ומה עוד מחכה. בשלב התכנון אפשר לתקן את הפרשנות. בזמן המילוי השאלות והתשובות משתנות יחד. בהשלמה נבדק המסלול הרלוונטי. בהעברה הלאה נשמר ההבדל בין מה שנרשם אצלנו לבין מה שאושר בצד השני.
זו גם הדרך שבה אנחנו ניגשים לפיתוח מוצר מותאם ולשילוב AI בתהליכי עבודה: מתחילים בפעולה עסקית מוגדרת, בוחנים מי מקבל את ההחלטה, ומטפלים גם במצב שבו צריך הבהרה או בירור. את הכלים בוחרים אחרי שהחיבורים האלה ברורים.
לפני הדגמת המוצר הבאה, הכינו שלושה דברים: טופס שמשתמשים בו היום, תשובה שמשנה את שאלת ההמשך, והמערכת שמחכה למידע בסוף. בקשו לראות מה קורה כשמשנים את התשובה, וכשהמערכת הבאה לא מאשרת קבלה. שם אפשר לראות אם התהליך באמת מחובר.
