טפסים באתר נשברים על לוגיקה מותנית ותשלום
טופס עם לוגיקה מותנית הוא לא "להציג שדה אם נבחרה אפשרות". זה עץ תלויות, שבו כל כלל נשען על הקודם: בחרת חברה — הופיעו פרטי החברה ושדה למספר, בחרת איסוף עצמי — נעלמה כתובת המשלוח.
די בכך שתנאי אחד יתייחס לשדה שהוא עצמו מוסתר, והלוגיקה מתפרקת: הלקוח רואה בלוק ריק או שולח טופס עם נתוני חובה לא מלאים. בתרחיש בדיקה זה לא עולה — זה עולה בתנועה אמיתית, כשמדובר בעשרות פניות ביום.
היקר ביותר הוא לא הקוסמטיקה, אלא קריעת השרשרת לאחר השליחה. הפנייה יוצאת למייל, אבל לא מגיעה ל-CRM: שדה לא תאם, webhook נפל, מסנן חובה פעל. המנהל לומד על הלקוח אחרי יממה או לא לומד כלל — ובינתיים הלקוח כבר כתב למתחרה.
שגיאות בעיבוד פניות כמעט אף פעם לא נראות בממשק: הטופס מציג "תודה", המייל יוצא, ורשומה במערכת אין.
סיפור נפרד — קבלת תשלומים באתר. הטופס אוסף נתונים, מעביר אותם לשער תשלום וצריך להחזיר את האדם לעמוד עם אישור, ואת הסטטוס — ל-CRM ולמייל. אם החזרה בקישור הולכת לאיבוד או שהסכום לא תואם לסל, התשלום עובר, אבל ההזמנה במערכת לא נוצרת. צריך לברר ידנית, לפי דף חשבון, וכל מקרה כזה — בזבוז זמן ומוניטין.
אינטגרציה של טפסים עם CRM נשברת בשקט: שינו את שם השדה בצד הטופס, הוסיפו מאפיין חובה ב-CRM, עדכנו תוסף — וחלק מהפניות הפסיקו להיווצר. אף אחד לא שם לב עד שההמרה מתחילה לרדת.
לכן אנחנו קודם כל בונים מפת שדות וכללים, בודקים כל ענף של לוגיקה מותנית ושמים בקרה על המסלול המקצה-לקצה "שליחה → CRM → תשלום", כדי שתקלה תהיה גלויה מיד, ולא לפי תלונת לקוח.
מה נותנת טופס מוגדר: האפקט במספרים
טופס מוגדר הוא לא "שדות יפים", אלא ההבדל בין מספר השליחות למספר הבקשות שהגיעו למנהל. ב-Gravity Forms הפער הזה נסגר ברמת הלוגיקה: ענפים מותנים מציגים רק שדות רלוונטיים, החובה מוגדרת לפי תרחיש ולא כברירת מחדל, ולכן המבקר לא נוטש את המילוי בשלב החמישי.
לפי הניסיון שלנו, שיעור השליחות שהושלמו עד הסוף גדל פי 1.5–2 — הודות לכך שהטופס מפסיק לשאול את המיותר.
אובדן בקשות כמעט תמיד יושב לא בעיצוב, אלא במסירה. המייל נשלח לספאם, המייל הולך לאיבוד כאשר שירות הדואר אינו זמין, המייל נשלח "לאין", כי הנמען הוא אחד והוא בחופשה.
אנחנו סוגרים את זה כך: הרשומה נשמרת במסד הנתונים לפני שליחת ההתראה, המסירה מתבצעת דרך שירות חיצוני עם אישור, בעת כשל מופעל ניסיון חוזר, והעתק נשלח ל-CRM ולכתובת גיבוי. סוג הכשל "הייתה בקשה, אבל אף אחד לא ראה אותה" מפסיק להתקיים — לכל שליחה יש סטטוס שניתן לבדוק.
מהירות עיבוד הבקשה — האפקט המדיד השני. כאשר הנתונים מהטופס מגיעים ל-CRM עם מבנה מוכן, ולא נשלחים מחדש במייל, המנהל לא מבזבז זמן על העברה וברור. המענה לבקשה טיפוסית מואץ משעות לדקות, ושיעור הבקשות שעובדו באותו יום גדל באופן צפוי — זה נראה בדוח, ולא במילים.
אמינות השליחה נשענת על שלושה דברים: הגנה מפני שליחות חוזרות, בדיקת נתוני הקלט לפני השמירה ויומן אירועים של הטופס. אנחנו מגדירים אותם יחד עם האינטגרציות — תשלומים, CRM, תפוצות — כדי שהטופס יעבוד כחלק מהתהליך, ולא כדף נפרד. בהמשך נפרק ממה מורכבת הגדרה כזו.
דרכי מימוש: אמצעים מובנים ושירותים חיצוניים
נוח להכריע את הפיצול לפי המקום שבו הלוגיקה נמצאת: בתוך הטופס, בהרחבה בצד האתר או בשירות חיצוני. האמצעים המובנים של Gravity Forms מכסים תצוגה מותנית של שדות, חישובים, התראות ורישום בסיסי למסד נתונים — זה מספיק כל עוד הכללים אינם תלויים בנתונים מחוץ לטופס.
ברגע שמופיע אישור לפי תפקידים, סנכרון עם CRM או ולידציה מורכבת מול מאגרים חיצוניים, מתחיל אזור ההרחבות והמעבדים החיצוניים.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| יכולות מובנות | לוגיקה מותנית, חישובים, התראות, קבלת תשלומים, רישום פשוט של פניות | הלוגיקה מוגבלת לשדות הטופס; אין אישורים וסנכרון עם מערכות חיצוניות "מהקופסה" |
| הרחבות לטופסים | תרחישים חוזרים: טפסים רב-שלביים, העלאת קבצים, אינטגרציות עם דיוור ומחסנים | תלות בקוד צד שלישי: עדכוני הליבה עלולים לשבור תאימות, חלק מההרחבות מתנגשות זו בזו |
| מעבדים חיצוניים | אישור לפי תפקידים, סנכרון עם CRM ומערכות חשבונאות, ולידציה לא סטנדרטית, ביקורת פעולות | דורשים תמיכה בצד שלך: טיפול בשגיאות, שליחות חוזרות, הפרדת הרשאות |
כיצד לבחור גישה
לא סופרים את מספר השדות, אלא את מספר ההסתעפויות והתלויות החיצוניות. אם כלל נקרא בשורת תנאי אחת ואינו מושך נתונים מבחוץ — משאירים אותו באמצעים המובנים: פחות קוד, פחות נקודות כשל בעת עדכון. אם התרחיש חוזר על עצמו בכמה טפסים, הרחבה זולה יותר בתמיכה מאשר העתקה של הלוגיקה בכל אחד.
מעבד חיצוני מוצדק כאשר הטופס הופך לחלק מתהליך: הפנייה עוברת ל-CRM, עוברת אישור, ומחזירה סטטוס. אז חשובים אידמפוטנטיות השליחה, יומן שינויים והתנהגות ברורה כאשר המערכת החיצונית אינה זמינה — אחרת נוצרות כפילויות של פניות ופניות אבודות.
אנחנו מתעדים את הבחירה בסכמה: אילו כללים נשארים בטופס, מה מוציאים להרחבה, ואילו קריאות יוצאות החוצה. זה מסיר את הסיכון העיקרי — לוגיקה מרוחה בין תוסף לשירות חיצוני, שאף אחד כבר לא יכול לקרוא בשלמותה.
איך אנחנו מיישמים: מביקורת ועד מסירה
את העבודה מתחילים בספירת מלאי: אוספים את כל הטפסים באתר, מתעדים לאן עוברים הנתונים, אילו שדות הם חובה, ואיפה כרגע הולכות לאיבוד פניות. בשלב הזה רואים אילו טפסים משכפלים זה את זה, ואילו נשברים במובייל — זו המפה לתכנון.
- ביקורת טפסים. עוברים על כל טופס כמו משתמש: ממלאים, שולחים, בודקים מיילים ורשומות. מסמנים התראות שבורות, שדות ללא ולידציה, התנגשויות תוספים וטפסים שלא נשלחים כשהסקריפט מושבת.
- תכנון הלוגיקה. מפרקים את התרחישים לפי תנאים: אילו שדות מוצגים בהתאם לתשובה, איפה נדרשים חישובים, שלבים, קבצים, הסכמות. מאשרים את סכמת ההסתעפויות לפני תחילת ההגדרה — תיקונים על הנייר זולים מתיקונים בפרודקשן.
- הגדרת אינטגרציות. מחברים קולטי נתונים: CRM, שירותי דואר, טבלאות, שערי תשלום. בודקים שהפנייה לא הולכת לאיבוד בעת כשל של שירות חיצוני ושההתראות נשלחות לנמענים הנכונים.
- בדיקת תרחישים. מריצים כל ענף לוגי, כולל מקרי קצה: שדות ריקים, פורמט שגוי, שליחה חוזרת, סירוב תשלום. בודקים מה רואה המשתמש ומה מקבל המנהל.
- מסירת הפתרון. מוסרים את הטפסים המוגדרים, סכמת הלוגיקה, רשימת האינטגרציות והוראות לתיקונים. מראים איך להוסיף שדה או לשנות תנאי בלי מפתח.
כל שלב מסתיים בתוצאה ניתנת לבדיקה, ולא בדוח. אם בביקורת מתברר שחלק מהטפסים קל יותר לכתוב מחדש מאשר לתקן — אומרים זאת מיד, לפני תחילת העבודה.
מה נשאר לכם לאחר העבודה
לאחר מסירת הפרויקט נשארת בידיכם לא "אוסף טפסים", אלא מערכת עובדת עם מבנה שקוף. אנו מוסרים את כל הנדרש לתפעול ולפיתוח עצמאי: קונפיגורציה, תרשימים, כללי גישה ותיעוד. להלן מה בדיוק אתם מקבלים.
- קונפיגורציית טפסים — קונפיגורציות מיוצאות של Gravity Forms עם כל השדות, הלוגיקה המותנית, הוולידציה והקשרים בין הטפסים. כל כלל מתועד: מה הוא בודק, באיזה תנאי הוא פועל, ולאן הוא מעביר את הנתונים.
- תרשימי זרימת נתונים — מפת מסלול הפנייה מרגע השליחה ועד לנמען: אילו אינטגרציות מעורבות, אילו שדות לאן עוברים, היכן פועלות התראות ו-webhooks, והיכן הנתונים נשמרים.
- כללי גישה ותפקידים — מטריצת הרשאות: מי מהעובדים רואה פניות, מי יכול לשנות קונפיגורציה, מי מייצא נתונים. בנפרד — כללים לעיבוד נתונים אישיים ותקופות שמירתם.
- תיעוד הטפסים — תיאור של כל שדה, לוגיקת ההסתעפות והאינטגרציות בשפה אנושית. עובד חדש יבין ללא פנייה אלינו.
- נהלי תמיכה — מה לעשות בעת כשל בשליחה, כיצד לבדוק מסירת התראות, כיצד להחזיר קונפיגורציה לגרסה קודמת, ולמי לפנות בעת תקלה.
- הוראות לתשלומים — אם חוברו תשלומים: כיצד מוגדרים התרחישים, כיצד מאמתים סטטוסים של עסקאות, וכיצד מטפלים בהחזרים ובתשלומים שלא הושלמו.
- צ'ק-ליסט קבלה — רשימת בדיקות שלפיהן אתם מקבלים את העבודה: שליחות בדיקה, מקרי קצה, והתנהגות בעת אי-זמינות של שירותים חיצוניים.
כל זה במקום אחד, בפורמט שנקרא ללא עזרתנו. אינכם כבולים לספק: המערכת מתועדת במידה כזו שניתן להעבירה לצוות אחר או לפתח אותה בכוחות עצמכם.
מקרה בוחן: כיצד מנענו אובדן לידים בטופס
מה היה לפני
הלקוח — חברת שירות עם זרם לידים ממספר דפי נחיתה. הטפסים נבנו על Gravity Forms, אך הלוגיקה הייתה "שטוחה": בד ארוך אחד של שדות, שדות חובה ללא תנאים, שליחה לתיבה משותפת אחת. בפועל הדבר יצר שלושה סוגי כשלים.
הראשון — ולידציה: המשתמש מילא הכל, נתקל בשדה שאינו הכרחי במהותו ועזב. השני — תשלומים: התשלום התבצע בשלב נפרד, ובחזרה מדף התשלום נתוני הטופס אבדו, והליד לא נרשם מחדש. השלישי — ניתוב: הלידים נפלו לתור משותף, וחלקם אבדו בעת המיון.
מה שינינו
בנינו מחדש את הטופס עם לוגיקה מותנית: שדות מופיעים בהתאם לתשובות, חובה מופעלת רק עבור הענף הרלוונטי, ושדות לא הכרחיים מוסתרים עד לבחירה המתאימה. שילבנו את התשלום בתוך הטופס עצמו — סטטוס העסקה נרשם ברשומה ולא בתהליך נפרד, ולכן חזרת המשתמש אינה מאפסת עוד את הנתונים.
הוספנו ולידציה בצד השרת והגנה מפני שליחות חוזרות, ואת ניתוב הלידים פיצלנו לפי אחראים באמצעות כללים לפי ערכי השדות.
מה התוצאה
שיעור השליחות המוצלחות עלה מ-61% ל-89% — עיקר השיפור נבע מהיציאה מ"חובתיות כוזבת" ומהצגת שדות לפי תנאי. כשלים בתשלום, שבהם הליד אבד בחזרה, נעלמו לחלוטין: הסטטוס כעת מקושר לרשומת הטופס.
זמן הטיפול בליד בודד הצטמצם כמעט בחצי — המפעיל מקבל ליד מסומן עם השדות הנדרשים, ללא בירור ידני. בנפרד הסרנו את סיכון הכפילויות: שליחה חוזרת בעת רענון הדף אינה יוצרת עוד רשומה שנייה.
מדוע זה ניתן לשחזור
המדדים כאן הם תוצאה לא של "טופס יפה", אלא של ניתוח היכן בדיוק הולכים לאיבוד הלידים. אנו בוחנים את המשפך שלב אחר שלב, מאתרים את נקודות הנשירה וסוגרים אותן בלוגיקה, ולא בשכנועים "מלאו בבקשה הכל". ניתוח כזה ניתן להעביר לכל זרם לידים: השדות והכללים משתנים, הגישה נשארת אותה גישה.
במה שונה לוגיקה מותנית ממילוי דינמי?
לוגיקה מותנית שולטת במה להציג ומתי: היא מעריכה את תשובות המשתמש ולפי כללים מוגדרים מסתירה, מציגה או מסמנת שדות, מקטעים ושלבים שלמים בטופס. מילוי דינמי פותר משימה אחרת — הוא מציב ערכים בשדות שכבר גלויים: שולף נתונים מהפרופיל, מתשובה קודמת, ממקור חיצוני או מהאפשרות הנבחרת. הראשון משנה את מבנה הטופס תוך כדי, השני — את תוכנו.
ההבדל מתגלה ברגע ההפעלה. לוגיקה מותנית בונה מחדש את הטופס עם ההתקדמות במילוי: בחרת "ישות משפטית" — הופיעו שדות עם פרטי זיהוי ומספר עוסק מורשה, בחרת "יחיד" — הם נעלמו, ואיתם גם החובה למלא אותם.
מילוי דינמי פועל אחרת: השדה נשאר במקומו, אבל כבר הוצב בו ערך — למשל, העיר מכתובת המשלוח מועברת לבלוק התשלום, ושם החברה מוצב בשדה החשבון. המשתמש רואה נתונים מוכנים או מאשר אותם, או מתקן.
מכאן גם תרחישי השימוש השונים. לוגיקה מותנית שמים במקום שבו הסתעפות השאלון תלויה בבחירה: מחשבונים, בקשות לשירותים עם מערכי שדות שונים, סקרים רב-שלביים, טפסים עם חובת מילוי שונה לקטגוריות שונות של לקוחות.
מילוי דינמי נחוץ במקום שבו חשוב לא להעביר אדם שוב ושוב על אותן שאלות: הזמנה חוזרת, רישום עם פרטי קשר שכבר ידועים, חישוב שבו חלק מהפרמטרים נלקחים מהתעריף הנבחר.
בפועל שני הגישות כמעט תמיד פועלות יחד. לוגיקה מותנית קובעת איזה ענף של הטופס פעיל, ומילוי דינמי ממלא את הענף הזה בנתונים בלי הקלדה חוזרת. אם לבנות רק לוגיקה, המשתמש יקליד את מה שהמערכת כבר יודעת; אם רק מילוי — הטופס לא יוכל להתאים את עצמו לקטגוריות שונות של מגישים.
מבחינה הנדסית אלה שני רבדים בלתי תלויים: כללי הנראות והחובה מצד אחד, מקורות ועדיפויות הצבת ערכים — מצד שני. ההפרדה ביניהם מפשטת את התחזוקה: כשמשנים תרחיש הסתעפות, לא נוגעים בלוגיקת ההצבה, ולהפך.
ספקות טכניים נפוצות
טופס ב-Gravity Forms הוא רשומה באותן טבלאות כמו שאר התוכן, ולכן תאימות עם ערכות נושא, תוספי מטמון ובוני עמודים נפתרת ברמת הסימון וסדר טעינת הסקריפטים, ולא בשכתוב הטופס.
אם האתר כבר אוסף פניות דרך תוסף אחר, אנו מעבירים את מבנה השדות וההתראות תוך שמירה על כתובות המטפלים הקיימות — קישורים ישנים וסימניות ממשיכים לעבוד.
אבטחה אנו סוגרים בצד השרת: בדיקת אסימון סשן חד-פעמי, הגבלת קצב שליחות לפי כתובת וטביעת אצבע של הדפדפן, שדה honeypot וקפצ'ה מופעלים באופן סלקטיבי — במקומות שבהם הטופס באמת אוסף ספאם.
לוגיקה מותנית וחישוב תשלום מבוצעים מחדש בעת העיבוד, ולכן החלפת שדות מוסתרים בדפדפן אינה מאפשרת לשלוח פנייה עם סכום שגוי או תשובה חובה שהוחמצה.
האם הטופס יפסיק לעבוד לאחר עדכון של ערכת הנושא או התוסף?
אנו מתעדים את תצורת הטפסים ואת לוגיקת העיבוד במודול נפרד, ולא בקבצי ערכת הנושא, — עדכון העיצוב אינו משפיע עליהם. לפני עדכונים אנו מריצים שליחת טפסי בדיקה לפי כל תרחיש: ענפים מותנים, תשלומים, התראות. אם משהו אינו תואם, אנו מחזירים את השינוי באופן ממוקד.
האם הטופס יעמוד בעומס שיא, למשל בקמפיין פרסומי?
עיבוד פנייה הוא פעולה קצרה, וצוואר הבקבוק בדרך כלל אינו בה, אלא בהתראות דואר ובשירותים חיצוניים. אנו מכניסים את שליחת המיילים לתור, כדי שפרץ פניות לא יחסום את העמוד, ומפרידים בין קליטת הנתונים לבין העברתם ל-CRM. עם גידול בתעבורה הטופס נשאר מגיב, ופניות אינן הולכות לאיבוד בעת אי-זמינות זמנית של מערכת חיצונית.
מה עם גישה לפניות ונתונים אישיים?
הנתונים נשמרים במסד הנתונים של האתר, והגישה מופרדת לפי תפקידים: מפעיל רואה רק את הטפסים הנדרשים, וייצוא ומחיקה — הרשאה נפרדת. אנו מגדירים תקופת שמירה וניקוי אוטומטי של רשומות מיושנות, ואת ההעברה ל-CRM ולמסרים מיידיים אנו מבצעים בערוץ מאובטח.
מי מתחזק את הטפסים לאחר ההשקה?
אנו מלווים את התצורה: מוסיפים שדות וענפי לוגיקה, משנים תנאי תשלומים, עוקבים אחר מסירת התראות ומטפלים בכשלי שליחה. תיקונים אנו מבצעים דרך סביבת בדיקה, ולכן הטופס הפעיל אינו נשאר ללא השגחה לא בזמן השינויים ולא אחריהם.
נדון במשימה שלכם ונחזור עם תוכנית
כדי שההערכה תהיה מדויקת ולא "בעין", אנחנו צריכים מכם מינימום הקשר: היכן הטפסים נמצאים כעת (אתר נוכחי, CMS, שירות נפרד), אילו שדות ותרחישים כבר עובדים, ולאן צריכים להגיע הפניות והתשלומים.
אם עדיין אין טפסים — די בתיאור התהליך: מי ממלא, אילו ענפי שאלות מתעוררים, ומה קורה לאחר השליחה. זה מספיק כדי להציע ארכיטקטורה של לוגיקה מותנית ואינטגרציות, ולא לנחש.
לאחר מכן אנחנו מפרקים את המשימה לשלבים וחוזרים עם תוכנית עבודה: אילו טפסים וענפי לוגיקה אנחנו מתכננים, אילו אינטגרציות מחברים (CRM, שירותי דואר, תשלומים, אנטי-ספאם), כיצד מגדירים התראות ואחסון פניות.
בנפרד מפרטים מה אנחנו עושים על הבסיס הקיים ומה דורש השלמה — כדי שתראו את גבולות העבודה ולא תשלמו על מיותר.
מה כדאי להכין לדיון:
- רשימת טפסים ותרחישים שצריכים לעבוד;
- תיאור ענפי הלוגיקה המותנית: אילו תשובות משנות את השדות הבאים;
- רשימת אינטגרציות ולאן צריכים להגיע נתוני הפניות;
- דרישות לתשלומים: חד-פעמיים, מנויים, מטבע, החזרים;
- גישות לאתר, ל-CMS ולפאנלים של שירותים, אם הטפסים כבר קיימים;
- דוגמאות למכתבים והתראות שצריכים להישלח לפונה ולכם;
- מגבלות זמנים ועדיפויות: מה קריטי בראש ובראשונה.
בסיום הדיון אתם מקבלים הערכה, תוכנית עבודה לפי שלבים וצעדים הבאים ברורים: מה אנחנו עושים, מה נשאר בצד שלכם, ובאיזה סדר אנחנו יוצאים לדרך. אם במהלך הדרך יתגלו סיכונים — למשל, התנגשות עם תוספים נוכחיים או מגבלות אחסון — נאמר זאת מיד, לפני ההתחלה, ולא תוך כדי התהליך. תארו את המשימה בפורמט נוח — נחזור עם הערכה ותוכנית ונדון בפורמט של שיתוף פעולה.
