Agentic Forms — טפסים שנבנים ומתמלאים בשיחה
מאת צוות מדיה דיל · 12.08.2026 · Generative UI · 5 דק׳
מדריך ל-Agentic Forms: איך הופכים טופס מסורתי לשיחה שמחלצת ומאמתת שדות בזמן אמת, בלי לוותר על מבנה נתונים יציב, נגישות ותאימות לאחור.
טופס פתיחת חשבון בנק קלאסי מציג עשרים שדות בבת אחת: שם, תעודת זהות, כתובת, הכנסה חודשית, מטרת החשבון, ועוד. משתמש אמיתי בדרך כלל מתחיל למלא, נתקל בשדה מבלבל, ונוטש. Agentic Forms הופכים את החוויה הזו לשיחה: הסוכן שואל שאלה אחת בכל פעם, מבין את התשובה בשפה חופשית ("אני עצמאי, מרוויח בערך 15 אלף בחודש"), וממפה אותה אוטומטית לשדות המבניים שהמערכת צריכה — כולל השלמת שדות שאפשר להסיק מהתשובות הקודמות בלי לשאול שוב. זו לא רק "צ'אטבוט שממלא טופס" — זו ארכיטקטורת טופס חדשה, שבה מבנה הנתונים הסופי זהה לטופס הרגיל, אבל אופן האיסוף שונה לגמרי.
מבנה נתונים קבוע, ממשק גמיש
העיקרון המרכזי ב-Agentic Forms הוא שהסכימה הסופית של הנתונים לא משתנה — עדיין יש שדה תעודת זהות שחייב לעבור ולידציה של תשעה ספרות, עדיין יש שדה מטרת חשבון עם רשימת ערכים סגורה. מה שמשתנה הוא הדרך שבה השדות האלה מתמלאים: לא תמיד input בודד עם label, אלא לפעמים שאלה בשיחה, לפעמים חילוץ ממידע שכבר סופק קודם בשיחה, ולפעמים עדיין טופס גרפי רגיל לשדות שדורשים דיוק גבוה (כמו מספר חשבון בנק). זה בדיוק אותו עיקרון של UI as Data: מבנה הנתונים הוא החוזה היציב, אופן ההצגה הוא המשתנה. בלי ההפרדה הזו קשה מאוד לבנות טפסים אגנטיים שעדיין מתחברים ל-Backend קיים בלי לשכתב את כל שכבת האימות.
חילוץ ואימות תוך כדי שיחה
כשמשתמש עונה "אני גר ברחוב הרצל 15 בתל אביב", הסוכן צריך לחלץ מזה כתובת, עיר, ומספר בית — ולעשות זאת בביטחון גבוה מספיק כדי לא לשאול שוב. זה דורש שילוב של חילוץ מבוסס מודל (parsing) עם ולידציה מבנית קשיחה בדיוק כמו בטופס רגיל, בהתאם לגישה שתיארנו במדריך Structured Outputs. ההבדל הקריטי מטופס רגיל הוא שגיאת ולידציה לא מוצגת כהודעת שגיאה אדומה מתחת לשדה — היא הופכת לשאלת המשך בשיחה: "לא מצאתי עיר בכתובת שכתבת, איזו עיר זו?" חוויה כזו מרגישה טבעית בהרבה, אבל דורשת ניסוח דינמי של הודעות שגיאה בהתאם להקשר, לא רק רשימת שגיאות סטטית שנכתבה מראש.
אתגר נוסף הוא זיהוי מתי המשתמש בעצם סיפק כמה שדות בבת אחת בתשובה אחת חופשית, לעומת מתי הוא ענה על שדה בודד. משתמש שכותב "קוראים לי דנה כהן, ת.ז 123456789" סיפק שני שדות במשפט אחד, וסוכן טוב צריך לזהות זאת ולסמן את שניהם כמולאים במקום להמשיך לשאול על השם בנפרד. פרקטית, כדאי לתכנן את הסכימה כך שכל שדה מסומן במפורש כ"טרם נשאל", "נשאל וממתין לתשובה", או "מולא ואומת" — ולא רק כריק או מלא — כדי שהסוכן ינווט נכון גם כשמשתמשים עונים בסדר לא צפוי.
שדות נגזרים ועקרון האי-חזרה
כלל מעשי חשוב בעיצוב Agentic Forms הוא עקרון האי-חזרה: אם המידע כבר נמסר בשלב כלשהו בשיחה, אסור לבקש אותו שוב. משתמש שאמר בתחילת השיחה "אני מתקשר בשם חברת הייטק בתל אביב" לא צריך להישאל שוב "מהי העיר שלך" כשהטופס מגיע לשדה כתובת עסקית. זה נשמע טריוויאלי אבל דורש תכנון מפורש: כל שדה בסכימה צריך להיות מסומן כניתן להיגזר משדות אחרים או מהקשר קודם, כדי שמנוע השיחה יידע לדלג עליו אוטומטית ולמלא אותו כברירת מחדל שהמשתמש רק מאשר, במקום לשאול מחדש. הפרה של העיקרון הזה היא הסיבה הנפוצה ביותר לתחושת "הבוט הזה לא זוכר כלום" שהורגת אמון במהירות, גם אם כל שדה בנפרד אומת נכון.
נגישות ותאימות לאחור
לא כל משתמש רוצה או יכול למלא טופס בשיחה חופשית — חלק מעדיפים ורואים טוב יותר שדות מפורשים על המסך, וחלק מהמשתמשים מסתמכים על טכנולוגיות מסייעות שדורשות מבנה טופס צפוי. לכן טופס אגנטי חייב תמיד לתמוך גם במעבר לתצוגת טופס רגיל באמצע התהליך, בלי איבוד מידע — כל מה שנאסף בשיחה ממופה מיד לשדות מוצגים, והמשתמש יכול להמשיך למלא בצורה הרגילה. זו דרישה שמתחברת ישירות לעקרונות נגישות WCAG: ממשק שכופה ערוץ אינטראקציה יחיד תמיד יוציא קבוצת משתמשים מסוימת מהמשחק, ואילו יכולת מעבר חלקה בין השניים היא בדיוק סוג ה-Progressive Enhancement שהופך תכונה מתקדמת לתוספת ולא לחסם.
מדידה: מה מצליח בפועל
ההצדקה לבנות Agentic Forms היא בדרך כלל שיפור שיעור השלמה (completion rate), ולכן חשוב למדוד את זה ישירות ולא להסתמך על תחושת בטן. מדדים שכדאי לעקוב אחריהם כוללים את אחוז השדות שהמודל חילץ נכון בפעם הראשונה בלי לשאול שוב, מספר סיבובי ההבהרה הממוצע לכל שדה, ואחוז המשתמשים שעברו לתצוגת טופס רגיל באמצע השיחה — מדד שיכול להצביע על כך שהניסוח הדינמי לא ברור מספיק. בניגוד לטופס סטטי, שאפשר לבדוק פעם אחת ולסמוך עליו, טופס אגנטי דורש ניטור מתמשך כי דפוסי הניסוח של משתמשים אמיתיים משתנים ומגלים מקרי קצה חדשים כל הזמן.
מתי לא כדאי להפוך טופס לשיחה
לא כל טופס מרוויח מהמרה לשיחה, וכדאי להיזהר מלהחיל את הגישה באופן גורף. טפסים קצרים עם שדה או שניים (חיפוש, הרשמה לניוזלטר) לא מרוויחים דבר מרובד שיחה — הם רק מוסיפים חיכוך וזמן המתנה לתגובת מודל במקום קלט מיידי. גם טפסים שדורשים דיוק מספרי גבוה מאוד, כמו הזנת פרטי כרטיס אשראי, עדיפים בממשק גרפי קבוע: משתמש שמקליד תשעה עשר ספרות רוצה לראות אותן מתעדכנות מיידית על המסך, לא לחכות לפרשנות של מודל. כלל אצבע טוב הוא לשמור שיחה לטפסים שבהם המורכבות נמצאת בהבנת ההקשר ולא בדיוק הקלט עצמו — פרטים אישיים מורכבים, תיאור בעיה, בקשה עם תנאים מרובים — ולהשאיר טפסים גרפיים רגילים לכל מה שדורש הזנה מדויקת ומהירה. דרך מהירה לבדוק אם טופס מסוים מתאים להמרה היא לשאול: כמה מהשדות שלו תלויים זה בזה, וכמה מהם דורשים פרשנות של ניסוח חופשי כדי להתמלא נכון? ככל שהתשובה גבוהה יותר, כך הסיכוי שהמרה לשיחה תשפר את שיעור ההשלמה ולא רק תוסיף שכבת מורכבות מיותרת.
תגיות: Agentic Forms · Conversational UI · Structured Outputs · UI as Data · Accessibility · Form Validation