עיצוב הזמנה בעמוד אחד ב-1С-Битрикс: היכן הולכים לאיבוד הקונים
הצ'קאאוט הסטנדרטי ב-1С-Битрикс בנוי כרצף של שלבים נפרדים, וכל מעבר ביניהם הוא נקודה שבה הקונה יכול לנטוש. הסל, ההזדהות, כתובת המשלוח והתשלום נמצאים בעמודים שונים: הנתונים מועברים לסשן, וברענון או בחזרה אחורה חלק מהמצב הולך לאיבוד, והאדם רואה טופס ריק במקום טופס שכבר מולא.
לפי הניסיון שלנו, על פערים כאלה נופל עיקר הסלים הנטושים — לא מפני שהלקוח התחרט, אלא מפני שהעיצוב אילץ אותו להתחיל מחדש.
צוואר הבקבוק השני הוא הוולידציה. שגיאות בשדות כמו טלפון או מיקוד צצות לא מיד, אלא לאחר שליחת השלב, לעתים קרובות בצורה כללית, בלי לציין את השדה הספציפי. הקונה לא מבין מה בדיוק לתקן, מנסה שוב, מקבל את אותה שגיאה וסוגר את הלשונית. בשלב האחרון, לפני אישור התשלום, זה עולה ביוקר מכול: הסל מלא, המשלוח נבחר, אבל ההזמנה לא נוצרת.
הסיבה השלישית היא הפיצול של השלבים כשלעצמו. ככל שהאדם עובר יותר מסכים, כך גדל הנשירה המצטברת, וכך קשה יותר להבין באיזה שלב בדיוק הולכת לאיבוד ההמרה של הצ'קאאוט. הסטטיסטיקה הסטנדרטית מראה את העובדה של סל נטוש, אבל לא מראה היכן בדיוק הקונה מעד.
עיצוב הזמנה בעמוד אחד ב-1С-Битрикс מאגד את הסל, פרטי הקשר, המשלוח והתשלום למסך אחד עם בדיקת שדות חיה ושמירה של מה שהוזן בכל רענון. להלן נבחן כיצד זה בנוי ומה זה נותן להמרה של הצ'קאאוט.
מה נותן מסך עיצוב אחיד
המעבר מעיצוב שלב-אחר-שלב למסך הזמנה אחיד מסיר את מצבי הביניים של סל הקניות: במקום ארבעה-חמישה מעברים בין עמודים, הקונה עובר מסלול אחד — הרכב ההזמנה, משלוח, תשלום ואישור נאספים בטופס אחד.
מספר השלבים החובה מצטמצם מחמישה-שישה לשניים-שלושה, וכל מסך מיותר מפסיק להיות נקודה שבה הקונה סוגר את הלשונית.
שיעור ההזמנות שהושלמו גדל בזכות העובדה שהנתונים אינם הולכים לאיבוד בין השלבים. כאשר הרכב הסל, הכתובת ואמצעי המשלוח חיים במצב טופס אחד, ולא נאספים מחדש בכל עמוד, הקונה רואה את הסכום הסופי והתנאים מיד — ואינו חוזר אחורה כדי לתקן משהו. בפועל זה מסיר את הסיבה העיקרית להזמנות שנקטעו: עלות משלוח בלתי צפויה או תנאים נסתרים בשלב האחרון.
מהירות טעינת הסל משפיעה ישירות על ההמרה: מסך אחיד מוגש בבקשה אחת במקום שרשרת מעברים, וחישוב מחדש של עלות המשלוח וההנחות מתבצע ללא טעינה מחדש מלאה של העמוד. פעולות כבדות — בדיקת מלאי, חישוב משלוח, החלת קופונים — עוברות לבקשות רקע, והקונה אינו ממתין שהטופס "יחשוב".
אפקט נפרד — יכולת השליטה. שדות הטופס, חובת המילוי, סדר הבלוקים והלוגיקה של החישוב מוגדרים ללא שכתוב התבנית, ולכן שינויים בתנאי המשלוח או התשלום אינם הופכים למשימת פיתוח נפרדת.
אנו מתעדים מדדים לפני ואחרי: מספר השלבים, שיעור הסלים הנטושים, זמן התגובה של הטופס — ולפיהם נראה היכן בדיוק הולכות לאיבוד הזמנות.
אפשרויות מימוש: מודול מובנה, התאמה אישית, שירות חיצוני
הבחירה בגישה קובעת כמה לוגיקה תישארו לשלוט בה וכמה מהר תוכלו לשנות את כללי התשלום. המודול המובנה מספק עמוד יחיד "מהקופסה", אך התנהגותו נקבעת על ידי המוצר: סדר השלבים, הרכב השדות והלוגיקה של חישוב המשלוח ניתנים לשינוי רק באמצעות אירועים ודריסת תבניות של הרכיב.
התאמה אישית של התבנית מסירה את המגבלות הללו — אתם שולטים בסימון, בסדר הבלוקים ובוולידציה, אך יחד עם הגמישות אתם לוקחים על עצמכם גם את התמיכה: כל עדכון של הליבה צריך להיבדק להתאמה לשינויים שלכם.
שירות הזמנות חיצוני מוציא את התשלום מחוץ למוצר ומתחבר לקטלוג ולמלאי דרך החלפה, מה שמוצדק בלוגיקה לא סטנדרטית, אך מוסיף נקודת כשל ועיכוב בסנכרון.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| מודול תשלום מובנה | תרחיש טיפוסי: סל קניות, משלוח, תשלום ללא כללים מיוחדים | את הלוגיקה של השלבים והשדות משנים רק באמצעות אירועים, חלק מההתנהגות סגור |
| התאמה אישית של התבנית | נדרש סדר בלוקים משלכם, ולידציה לא סטנדרטית, אינטגרציות בשלב התשלום | השינויים חיים בתבנית — עדכוני הליבה דורשים בדיקת רגרסיה |
| שירות הזמנות חיצוני | תשלום מחוץ למוצר, לוגיקה מורכבת, מספר ערוצי מכירה | החלפה עם הקטלוג והמלאי, עיכוב בסנכרון, נקודת כשל נפרדת |
בפועל לרוב בוחרים בהיברידי: המודול המובנה כבסיס, וההתאמה האישית — ממוקדת לשלבים שבהם נדרשת לוגיקה משלכם. כך עדכוני הליבה עוברים בצורה צפויה, ותרחישים לא סטנדרטיים לא שוברים את המסלול הטיפוסי של הקונה. נבחן כיצד לבחור את הגבול בין הגישות הללו בהתאם לתהליך התשלום שלכם.
כיצד אנו מטמיעים תהליך הזמנה בעמוד אחד ב-1С-Битрикс
את ההטמעה אנו מתחילים בסקירה של סל הקניות ותהליך ההזמנה הנוכחיים: בוחנים אילו שלבים עובר הקונה, היכן אובדות עמדות, כיצד בנויים כללי המשלוח, ההנחות והמיסים.
בשלב זה אנו מתעדים אילו בדיקות וחישובים כבר קיימים במערכת, ואילו יהיה צורך להוסיף כדי שתהליך ההזמנה בעמוד אחד לא ישבור את הלוגיקה הקיימת.
לאחר מכן אנו עובדים בשלבים — מהניתוח ועד למסירת התהליך המוגדר.
- סקירת סל הקניות ותהליך ההזמנה הנוכחי: מנתחים את מבנה ההזמנה, המאפיינים, השיוך למחסנים ולשירותי המשלוח, מאתרים צווארי בקבוק ושלבים מיותרים.
- תכנון התהליך: מגדירים את הרכב הבלוקים בעמוד אחד — פרטי קשר, משלוח, תשלום, אישור — ואת סדר מילוים.
- הגדרת תבנית תהליך ההזמנה: מרכיבים את רכיב ההזמנה, מציגים את השדות ואת אפשרויות המשלוח, מגדירים חישוב מחדש של העלות ואימות ללא רענון העמוד.
- חיבור אמצעי תשלום ומשלוח: מקשרים בין אמצעי התשלום הזמינים לאפשרויות המשלוח, ומגדירים כללים להצגתם בהתאם לתנאי ההזמנה.
- בדיקת ההזמנה: מריצים תרחישים עם סלים, כתובות ואמצעי תשלום שונים, בודקים את החישובים, את ההודעות ואת העברת הנתונים למערכת החשבונאית.
- בדיקה במכשירים ניידים ובערוצים איטיים: מוודאים שהשלבים אינם אובדים, ושהטופס פועל כראוי בחיבור חלש.
- מסירה והדרכה: מוסרים את התהליך המוגדר, מתארים את הלוגיקה של השדות ואת הכללים, ומראים כיצד לשנות את הרכב הבלוקים ללא מפתח.
בכל שלב אנו משווים את התוצאה לדרישות המקוריות: ההזמנה צריכה לעבור במלואה, הסכומים והמשלוח צריכים להיות מחושבים נכון, והנתונים — להגיע למערכת החשבונאית ללא תיקונים ידניים. סדר עבודה זה מאפשר להטמיע תהליך הזמנה בעמוד אחד מבלי לשבור תהליכי מכירה קיימים.
שדות טופס, ולידציה וקשרים ל-1С
שדות הטופס הם לא "שם וטלפון", אלא סט של מאפיינים שעובר למערכת החשבונאית. ההרכב המינימלי לעבודה: איש קשר, אמצעי התקשרות, כתובת משלוח עם בחירה מתוך השלמות, אמצעי תשלום ומשלוח, הערה, הסכמה לעיבוד נתונים. כל שדה מקושר למאפיין הזמנה ב-1С-ביטריקס, אחרת בעת הייצוא הערך יאבד או יעבור לעמודה הלא נכונה.
- חובת מילוי השדות מוגדרת לפי תרחיש: עבור איסוף עצמי הכתובת מוסתרת ואינה חוסמת את השליחה, עבור משלוח — היא הופכת לחובה.
- הוולידציה מתבצעת בשני רבדים: צד הלקוח (מסכת טלפון, פורמט דואר אלקטרוני, מיקוד) וצד השרת — זה שמגן באמת מפני זבל בבסיס הנתונים.
- הבדיקה מקושרת למאפייני ההזמנה באמצעות כללים, ולא לתצוגה — בעת החלפת ערכת עיצוב הכללים נשארים פעילים.
- קשרי השדות מתוארים באמצעות תלויות: בחירת אזור מושכת את רשימת הערים, בחירת משלוח — את נקודות האיסוף הזמינות.
- ההסכמה לעיבוד נתונים נרשמת כמאפיין נפרד עם חתימת זמן — זה נדרש לצורך ניקיון משפטי של ההזמנה.
הסנכרון עם המערכת החשבונאית מבוסס על החלפה דרך CommerceML ומנגנוני החלפת ההזמנות הסטנדרטיים. ההזמנה עוברת ל-1С עם מזהה ייחודי, ובחזרה מגיע הסטטוס: שולם, נאסף, נשלח. אם ההחלפה אינה זמינה, ההזמנה אינה הולכת לאיבוד — היא נשארת בתור ועוברת עם שחזור הקשר, והמנהל רואה אותה בפאנל.
1С-ביטריקס שומר היסטוריית שינויים של סטטוס, ולכן אי-התאמה בין האתר למערכת החשבונאית נראית מיד, ולא צפה במהלך התאמה. קו מתאר כזה מסיר העברה ידנית של הזמנות ומבטל סוג של שגיאות שבו הלקוח שילם, אבל ב-1С ההזמנה כלל לא הופיעה.
מקרה בוחן: צמצום עגלות נטושות במרקטפלייס
הלקוח — מרקטפלייס למוצרי בית עם כמה אלפי פריטים פעילים ותהליך השלמת הזמנה בארבעה שלבים: עגלה, בחירת משלוח, הזנת פרטי מקבל, אישור. כל מעבר בין שלבים — טעינת עמוד נפרדת, ונתוני הקונה ואמצעי המשלוח הנבחר נשמרו בסשן.
במובייל, שבו התרחשו כשני שלישים מהתנועה, הסשן נותק בעת מעבר בין אפליקציות: האדם יצא להביא מספר כרטיס או כתובת וחזר לעגלה ריקה.
1С-Битрикс בתצורה כזו אינו מפריע, אך גם אינו מסייע: רכיב השלמת ההזמנה הסטנדרטי מיועד לתרחיש שלב-אחר-שלב, וכל לוגיקת הבדיקות וחישוב המשלוח מפוזרת בין מטפלי השלבים.
העברנו את תהליך ההשלמה לתרחיש של עמוד אחד עם מצב הזמנה אחיד: פריטים, כתובת, אמצעי משלוח וקוד קופון חיים באובייקט אחד, השלבים מתחלפים ללא רענון, והמצב הביניים נשמר בשרת ומשוחזר בעת חזרה לעמוד.
בנפרד סגרנו את חישוב עלות המשלוח — קודם הוא הופעל רק במעבר לשלב הבחירה, כך שהקונה ראה את הסיכום רק לאחר הזנת הכתובת ולעיתים קרובות נטש את ההזמנה בנקודה זו.
כעת העלות מחושבת מחדש בעת שינוי העגלה או הכתובת ומוצגת מיד בבלוק הסיכום, ושגיאות ולידציה מוצגות לצד השדה, מבלי לאפס את מה שכבר הוזן.
| מדד | לפני | אחרי |
|---|---|---|
| שיעור הזמנות שהושלמו | 41% | 63% |
| זמן השלמה ממוצע | 4 דק' 20 שנ' | 1 דק' 50 שנ' |
| שיעור הזמנות ממובייל | 58% | 67% |
| פניות לתמיכה בנושא השלמה | ~90 בשבוע | ~25 בשבוע |
העלייה בשיעור ההזמנות שהושלמו הוסיפה להכנסות ללא הגדלת תקציב הפרסום: אותה תנועה החלה להתמיר טוב יותר באופן ניכר. חודש לאחר ההשקה הוספנו שמירת טיוטת הזמנה לקונים מאומתים — שיעור ההשלמות עלה בעוד כמה נקודות, והזמנות חוזרות החלו להתבצע כמעט בקליק אחד.
במה שונה עיצוב עמוד אחד מעיצוב שלב-אחר-שלב?
עיצוב שלב-אחר-שלב מפצל את הרכישה לשלבים: סל קניות, אמצעי משלוח, תשלום, אישור. כל שלב הוא עמוד נפרד או טעינה של בלוק, עם בדיקת נתונים לפני המעבר הלאה. המשתמש תמיד רואה היכן הוא נמצא, והטופס נשאר קצר.
הצד השני — קליקים מיותרים ונקודות שבהן אפשר לסגור את הלשונית: כל עמוד ביניים מאבד חלק מהקונים, ובמובייל עם משפך ארוך ההפסדים מורגשים יותר.
עיצוב עמוד אחד מרכז את כל השדות על מסך אחד: פרטי קשר, משלוח, תשלום, הרכב ההזמנה. המשתמש ממלא את הטופס מלמעלה למטה ומאשר את הרכישה בפעולה אחת. הרווח — פחות מעברים ופחות סיבות לעזוב, ההפסד — טופס ארוך וסיכון שהאדם לא יבין אילו שדות חובה. לכן checkout בעמוד אחד כמעט תמיד דורש ולידציה מחושבת ורמזים ישירות בתוך הטופס.
מנקודת המבט של המימוש ההבדל הוא באופן שבו בנוי חילוף הנתונים. תרחיש שלב-אחר-שלב שומר מצב בין השלבים — בסשן, בקוקיז או בהזמנת ביניים, — ובכל מעבר מרכיב מחדש את הסל ומחשב מחדש את המשלוח.
הגרסה של עמוד אחד מחזיקה הכל בבקשה אחת: השדות, שירות המשלוח הנבחר, אמצעי התשלום והסכום הסופי מחושבים מחדש בזמן אמת, ללא רענון. זה משנה גם את נקודות הכשל: בשלב-אחר-שלב נשבר שלב מסוים, בעמוד אחד — כל הטופס כולו, ולכן עיבוד השגיאות מתוכנן אחרת.
הבחירה תלויה במוצר ובקהל. עבור פריט אחד-שניים עם משלוח פשוט, עיצוב עמוד אחד נותן פחות חיכוך והמרה גבוהה יותר. עבור הזמנות מורכבות — פריטים רבים, כמה כתובות, אמצעי קבלה שונים, — תרחיש שלב-אחר-שלב מובן יותר: הוא לא מעמיס על המסך ומאפשר לבדוק נתונים בהדרגה. לעתים קרובות הפתרון העובד הוא היברידי: שלב ראשון קצר עם פרטי קשר ומשלוח, ואחריו מסך תשלום אחיד.
מבחינה טכנית שתי הגרסאות מיושמות על אותו מנוע ואינן דורשות כתיבה מחדש של הקטלוג או אינטגרציות עם 1С. משתנים התבניות של רכיב עיצוב ההזמנה, לוגיקת הוולידציה וכללי חישוב מחדש של הסל.
אנחנו קודם בוחנים כיצד מתנהג המשפך הנוכחי והיכן בדיוק הולכים לאיבוד הקונים, ורק אחר כך מציעים לעבור לתרחיש של עמוד אחד או להשאיר את השלב-אחר-שלב.
שאלות טכניות נפוצות בנוגע להגדרת תהליך התשלום
תהליך תשלום בעמוד אחד ב-1С-Битрикс כמעט תמיד נשבר לא בגלל ה-HTML, אלא במפגש עם הלוגיקה הקיימת של החנות: תבנית מותאמת אישית, מאפייני הזמנה ייחודיים, סנכרון עם 1С. להלן מה שצף לרוב בשלב ההטמעה וכיצד זה נפתר ברמת הקונפיגורציה, ולא באמצעות "פתרונות טלאי".
האם תהליך תשלום בעמוד אחד תואם לתבנית ולרכיבים הנוכחיים?
כן, אם בונים מחדש לא את כל התבנית, אלא את שכבת תהליך התשלום. רכיב התשלום מציג את המאפיינים, הסל והמשלוח כבלוקים נפרדים — מאחדים אותם לעמוד אחד באמצעות תבנית רכיב מותאמת אישית, תוך שמירה על ההרחבות והמטפלים הסטנדרטיים.
מאפייני הזמנה מותאמים אישית וכללי הסל נשארים פעילים: אנו מעבירים את התצוגה שלהם לסימון החדש, ולא כותבים מחדש את הלוגיקה. אם התבנית מותאמת אישית במידה רבה, תחילה מפיקים מפת תלויות — אחרת תיקונים נסתרים יצופו כבר לאחר ההשקה.
כיצד תהליך תשלום בעמוד אחד משפיע על המהירות וההמרה?
העיקר — להסיר רענונים מיותרים ובקשות סינכרוניות. שלבי התשלום מתחלפים ללא רענון מלא של העמוד, חישוב המשלוח וההנחות עובר לקריאות נדחות, בדיקות כבדות אינן חוסמות את הקלט.
בפועל זה מקצר את המסלול מהסל ועד לאישור ומפחית את שיעור ההזמנות הנטושות בשלב האחרון — שם שבדרך כלל הולך לאיבוד הקונה.
האם הסנכרון של הזמנות עם 1С לא יישבר?
הסנכרון מבוסס על סטטוסים ומאפייני הזמנה, ולא על סימון העמוד. אנו שומרים על מיפוי השדות, הפרטים והסטטוסים, ולכן הייצוא ל-1С מתבצע כמו קודם. בנפרד בודקים תרחישים: הזמנה עם סט מאפיינים חדש, תשלום חלקי, ביטול — כדי שבמערכת החשבונאית לא יופיעו כפילויות ופריטים "תקועים".
האם ניתן לחזור אחורה אם משהו ישתבש?
כן. העבודה מתבצעת על עותק, והתרחיש הישן של התשלום נשאר זמין עד לאישור. המעבר הוא מבוקר, עם אפשרות להחזיר את הגרסה הקודמת ללא אובדן הזמנות. לפני ההשקה מריצים את המסלולים המרכזיים: אורח, קונה מאומת, תשלום, משלוח, סנכרון עם 1С.
אם הספק שלכם אינו מופיע כאן — תארו את המשימה, ונחזור עם הערכה ותוכנית המותאמת לתבנית שלכם ולקונפיגורציית הסנכרון.
נדון במשימה שלך לביצוע ההזמנה
הדיון מתחיל לא מתבנית, אלא מהתרחיש הנוכחי שלך לביצוע ההזמנה: אילו שדות ממלא הקונה, היכן הוא נעצר, אילו אמצעי משלוח ותשלום מעורבים, וכיצד בנוי חילוף הנתונים עם 1С. מכך תלוי גם היקף העבודה, וגם אילו בדיקות יש להטמיע בלוגיקה החדשה.
לאחר מכן אנו מקבעים את תוכנית העבודה ואת הערכת הפרויקט — עם שלבים, לוחות זמנים ותחומי אחריות. אתה רואה מה בדיוק משתנה בתבנית, אילו מודולים אנו נוגעים בהם, כיצד תתבצע העברת הנתונים ומה יישאר בתמיכה.
- מנתחים את תהליך ביצוע ההזמנה הנוכחי ואת צווארי הבקבוק: שלבים מיותרים, שדות חובה, התנהגות בעת שגיאות ולידציה.
- מתאמים סכימה סופית של ביצוע הזמנה בעמוד אחד: הרכב הבלוקים, הסדר, לוגיקת חישוב המשלוח והמיסים.
- מגדירים נקודות אינטגרציה עם 1С: ייצוא הזמנות, מלאי, סטטוסי תשלומים, סנכרון נומנקלטורה.
- מכינים תוכנית עבודה עם שלבי הטמעה, נקודות ביקורת וסדר העלאה לסביבת הייצור.
- נותנים הערכת פרויקט לפי משאבי עבודה ולוחות זמנים, ומציינים בנפרד סיכונים ותלויות במערכות חיצוניות.
- מפרטים כיצד תיבנה החזרה לאחור ומה ייכלל בתמיכת האחריות לאחר ההשקה.
כדי לחזור עם קונקרטיקה ולא עם מילים כלליות, מועיל לנו לראות את האתר שלך, גישה לפאנל הניהול ותיאור של האופן שבו ההזמנות מגיעות כעת ל-1С. אם אין גישות — יספיקו צילומי מסך וסיפור קצר על התהליך: זה מספיק כדי להעריך את היקף הטמעת ביצוע ההזמנה.
תאר את המשימה — נחזור עם תוכנית עבודה והערכת פרויקט.