עיצוב הזמנה מותאם אישית ב-Bitrix: היכן נשבר התרחיש הסטנדרטי
תרחיש עיצוב ההזמנה הסטנדרטי ב-1С-Bitrix מיועד לסל פשוט: פריט אחד — מחיר אחד, המלאי נמחק באופן סינכרוני, התשלום מתבצע מיד לאחר האישור. ברגע שבקטלוג מופיעות הצעות מסחריות, רזרבות ממספר מחסנים, הנחות התלויות בהרכב הסל, או תשלום בתשלומים — מתחיל חוסר סנכרון.
הסל מציג כמות אחת, המחסן מרזב כמות אחרת, ובחישוב מחדש לאחר שינוי שיטת המשלוח חלק מהפריטים נעלמים בשקט מההזמנה — הלקוח רואה שורה ריקה במקום המוצר ועוזב.
השגיאה היקרה ביותר בעיצוב הזמנה היא אובדן פריטים בחישוב מחדש. המטפל הסטנדרטי מרכיב מחדש את הסל בכל שינוי בתנאים, ואם מוצר מותאם אישית, פריט מתנה או מוצר בהזמנה מראש אינו מתואר בכללי החישוב מחדש, הוא נושר מההזמנה ללא שגיאה בלוג.
ההזמנה יוצאת למחסן חלקית, הלקוח מקבל לא את מה ששילם עליו, והמנהל לומד על כך משיחת טלפון. נקודת כשל נפוצה שנייה היא שלב התשלום: מערכת התשלומים מחזירה סטטוס שהמודול אינו מתאים לסטטוס הפנימי של ההזמנה, והקונה נתקע בעמוד ההמתנה, אף שהכסף כבר חויב.
הכשל השלישי — חוסר סנכרון בין הסל למחסן בהזמנות מקבילות. שני קונים מבצעים בו-זמנית הזמנה על היחידה האחרונה, הרזרבה נרשמת לשניהם, אך המחיקה עוברת רק באחד — ההזמנה השנייה נופלת לשגיאה כבר לאחר התשלום. הלוגיקה הסטנדרטית של הרזרבה אינה מיועדת לתרחישים כאלה ללא התאמה.
אנו מפרקים כל אחד מהכשלים הללו בפרויקט קונקרטי: בוחנים היכן בדיוק הולך לאיבוד הפריט, כיצד מתנהג הסל בחישוב מחדש ומה קורה בשלב התשלום.
לאחר מכן מתארים את הלוגיקה של עיצוב הזמנה מותאם אישית עבור הקטלוג שלך וכללי המכירה — עם טיפול מפורש ברזרבות, אישור תשלום אידמפוטנטי ותיעוד כל שינוי בסל, כך שאובדן פריטים ייראה מיד, ולא במחסן.
מה נותן עיצוב הזמנה מחודש
עיצוב הזמנה מחודש אינו החלפה של מראה הטופס, אלא החלפה של לוגיקת מעבר סל הקניות. תבנית ברירת המחדל של 1С-Битрикс מובילה את הקונה בשרשרת שלבים קבועה ודורשת הרשמה לפני התשלום; אם אין בכך צורך, כל מסך מיותר הוא נקודה שבה חלק מהאנשים נוטשים.
עיצוב הזמנה מותאם אישית ב-Битрикс בונה מחדש את המסלול בהתאם לתרחיש הרכישה האמיתי: שדות נמשכים מהפרופיל, כתובת ואמצעי משלוח מוזנים לפי מיקום גיאוגרפי או הזמנה קודמת, והתשלום זמין מיד לאחר אישור ההרכב.
האפקט המדיד הראשון — מהירות העיצוב. כאשר הקונה עובר את הסל במסך אחד במקום שלושה-ארבעה, הזמן עד לתשלום מתקצר פי כמה, ושיעור הסלים הנטושים יורד: הסיבה העיקרית לנטישה אינה "שינה את דעתו", אלא עייפות מצטברת מהשלבים, מההזנה החוזרת ומההרשמה החובה. אנחנו מסירים בדיוק את הנקודות האלה, ולא "מפשטים את העיצוב".
האפקט השני — סוג הכשלים בתשלום. שער התשלום, שירות המשלוח והמחסן מגיבים באופן אסינכרוני, ובמקרה של כשל באחד מהם ההזמנה לא צריכה "להיתקע" בסטטוס לא מוגדר.
מטפלי האירועים של הסל וההזמנה מתעדים את התוצאה של כל שלב, חוזרים על הבקשה שנכשלה ומציגים לקונה מצב מובן במקום שגיאה טכנית — ההמרה של הסל מפסיקה להיות תלויה בכשלים חד-פעמיים של אינטגרציות.
האפקט השלישי — ניהוליות. לוגיקת השלבים, מערך השדות, תנאי משלוח חינם וכללי ההנחות מוצאים להגדרות, ולא לקוד התבנית: השיווק משנה את תרחיש העיצוב בלי ריליס, והצוות לא מבזבז מחזור על תיקון המרקם לכל מבצע. בהמשך נפרק כיצד זה בנוי ומה נדרש מצד הצוות שלכם.
דרכים לבניית תהליך הזמנה לא סטנדרטי
בחירת הדרך קובעת לא רק את לוחות הזמנים להפעלה, אלא גם עד כמה תהליך ההזמנה ישרוד באופן צפוי עדכונים של הפלטפורמה וגידול בעומס. רכיב מובנה, מודול עצמאי ושירות חיצוני פותרים משימה אחת בכלים שונים — ונבדלים זה מזה בעלות התמיכה לאורך זמן.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| התאמה אישית של הרכיב המובנה | הלוגיקה קרובה לטיפוסית: שדות משלך, שלבים, רמזים, חישוב משלוח | שינויים בתבנית ובמטפלים נמחקים בעת עדכון, אם אינם מופרדים לשכבה נפרדת |
| מודול הזמנה עצמאי | לוגיקה לא טיפוסית: תרחיש רב-שלבי, מספר סלים, אישור, כללי הנחה משלך | זמן רב יותר בהתחלה, דורש תכנון של סכימת נתונים ומיגרציות |
| שירות הזמנה חיצוני | נדרש ממשק נפרד, עומס גבוה, אינטגרציה עם מערכות חיצוניות | שני מקורות אמת להזמנות, סנכרון סטטוסים ומלאי, מעגל הרשאות נפרד |
התאמה אישית של הרכיב המובנה נותנת את התוצאה המהירה ביותר כאשר תרחיש הרכישה אינו משתנה באופן מהותי. אנו מפרידים לוגיקה מותאמת אישית לשכבה משלנו מעל הטיפוסי — ואז עדכון הליבה אינו שובר את תהליך ההזמנה, והשינויים נשארים ניתנים לניהול.
מודול עצמאי מוצדק כאשר כללי ההזמנה הופכים לחלק מהמודל העסקי: מספר מחסנים, תשלום דחוי, אישור בקשה. כאן חשובה סכימת הנתונים והמיגרציות — אחרת העברת הזמנות בין גרסאות הופכת לעבודה ידנית.
שירות חיצוני נלקח עבור עומס וממשק לא סטנדרטי, אך הוא דורש סנכרון כן: סטטוסים, מלאי ותשלומים חייבים להתכנס בנקודה אחת. אנו בוחרים את האפשרות לפי המשימה, ולא להפך — ומתעדים כיצד הפתרון יתנהג בעת עדכון הפלטפורמה.
שלבי יישום: מביקורת ועד מסירה
אנחנו מתחילים את העבודה בביקורת של תרחיש ההזמנה: בודקים אילו שלבים הקונה עובר כיום, היכן הסל הולך לאיבוד, אילו מאפיינים וסטטוסים של ההזמנה מעורבים, וכיצד בנויות ההצמדות למחסנים ולשירותי המשלוח.
בפלט — מפה של התרחיש הנוכחי עם צווארי בקבוק ורשימה של מה שמפריע לעסק: תנאי משלוח לא סטנדרטיים, תשלום בתשלומים, הזמנה בקליק אחד ללקוחות קבועים.
בהמשך מתכננים את הסכימה הרצויה: מפרקים את התשלום לשלבים, קובעים כללי ולידציה לשדות, התנהגות בעת תקלות ונקודות אינטגרציה עם מערכת הנה"ח. את הסכימה מאשרים לפני כתיבת הקוד — תיקונים על הנייר זולים יותר מתיקונים בפרודקשן.
- ביקורת של תרחיש ההזמנה. מנתחים את מסלול הקונה הנוכחי, את לוגיקת הסל, מאפייני ההזמנה והסטטוסים, ומוצאים שלבים עם אובדן קונברסיה.
- תכנון הסכימה. מתארים את שלבי התשלום, כללי ולידציה, תפקידי משתמשים, תרחישי תשלום ומשלוח, ונקודות החלפה עם מערכת הנה"ח.
- הגדרת התשלום. בונים שלבים ושדות מותאמים אישית, מחברים מערכות תשלום ושירותי משלוח, ומגדירים חישוב עלות ותנאים.
- אינטגרציות. מקשרים את ההזמנה למערכת הנה"ח, למחסן ול-CRM: העברת פריטים, הזמנות רזרבה, סטטוסים, התראות.
- בדיקת ההזמנה. מריצים את התרחישים בשלמותם — מהוספה לסל ועד למסמכי סגירה, כולל סירובי תשלום והזמנות חוזרות.
- בדיקת עומס. בודקים את התנהגות התשלום בעת פעילות שיא: הזמנות במקביל, תחרות על מלאי, שליחה חוזרת של טפסים.
- מסירה והדרכה. מוסרים תיעוד, סכימות והוראות, ומראים לצוות כיצד לשנות כללים ולהוסיף שלבים חדשים.
כל שלב מסתיים בתוצאה שאפשר לבדוק: מפת התרחיש, סכימה מאושרת, שלב תשלום עובד, דוח ריצה. כך הלקוח רואה התקדמות בפרויקט, ולא "תהליך פיתוח" מופשט.
מה הלקוח מקבל לידיו
אנחנו מוסרים לא "אתר מוכן", אלא ערכה שלפיה ניתן להפעיל ולפתח את המערכת בלעדינו. כל ארטיפקט מכסה סוג משלו של משימות: הגדרה, אינטגרציה, הרשאות גישה, הדרכת צוות.
- קונפיגורציות של ביצוע הזמנה — הגדרות מיוצאות של חוקי סל הקניות, הנחות, משלוח ותשלומים. מאפשרות לפרוס את הלוגיקה בסביבת בדיקה ולהשוות את ההתנהגות לזו שבסביבת העבודה.
- תרשימי אינטגרציות — כיצד ביצוע ההזמנה מחליף נתונים עם מערכת הנהלת החשבונות, המחסן, שירותי המשלוח ושערי התשלום: כיווני הזרימות, נקודות כשל, שליחה חוזרת בעת תקלה.
- מדיניות גישה — מטריצת תפקידים עבור מנהלי מערכת, מנהלים וקבלנים: מי משנה את חוקי ביצוע ההזמנה, מי רואה נתונים אישיים של קונים, מי רק קורא הזמנות.
- נהלי ביצוע הזמנה — תרחישים שלב-אחר-שלב למצבים טיפוסיים: עריכת תנאי משלוח, הוספת אמצעי תשלום, טיפול בהזמנה תקועה.
- תיעוד ההזמנה — תיאור הלוגיקה המותאמת אישית: אילו בדיקות מופעלות, באיזה סדר, מה קורה כאשר שירות חיצוני נכשל.
- הוראות לצוות — כיצד מנהל עובד עם הזמנות לא שגרתיות ולאן להסתכל כאשר יש אי-התאמה בנתונים.
- יומן שינויים — מה ולשם מה שונה בביצוע ההזמנה, כדי שהעדכון הבא לא ישבור את הקודם.
- תוכנית נסיגה — נקודות שחזור של הקונפיגורציה וסדר הפעולות אם עדכון פגע בהמרות של ביצוע ההזמנה.
הערכה נשארת אצלכם: קבלן חדש או מהנדס מן המניין נכנס לפרויקט לפי התיעוד, ולא לפי הזיכרון של הצוות הקודם. תארו את המשימה — נחזור עם הערכה ותוכנית.
מקרה בוחן: קיצור זמן השלמת ההזמנה
הלקוח — חנות מקוונת לציוד תעשייתי על 1С-Битрикс: מפרטים ארוכים, סלי קניות עם עשרות פריטים, תשלום בחשבונית ובכרטיס. תהליך השלמת ההזמנה המקורי עבר בשלושה שלבים עם חובת הרשמה לפני בחירת משלוח. בשלב התשלום המשתמש חזר לסל בעת שינוי שיטת המשלוח — חישוב העלות אופס, וחלק מההזמנות לא הגיעו לאישור.
מה היה לפני
מדדנו מדדים במשך שבועיים: זמן השלמה ממוצע — 4 דקות ו-20 שניות, שיעור התשלומים המוצלחים מתוך הזמנות שהחלו — 61%, נקודת היציאה הנפוצה ביותר — שלב בחירת המשלוח (38% נטישות). ההרשמה לפני התשלום הרתיעה קונים עם רכישות חד-פעמיות.
מה שינינו
כתבנו מחדש את רכיב ההשלמה בלוגיקה מותאמת אישית: חישוב המשלוח והתשלום הועברו לשכבה נפרדת, שמחושבת מחדש ללא אובדן הנתונים שהוזנו. ההרשמה הועברה לסוף — ניתן להשלים הזמנה כאורח, והחשבון נוצר אוטומטית לאחר התשלום. הוספנו ולידציה של שדות בזמן אמת ושמירת טיוטת סל, כדי שחזרה להזמנה לא תתחיל מאפס.
מה התוצאה
זמן ההשלמה הממוצע הצטמצם ל-1 דקה ו-50 שניות. שיעור התשלומים המוצלחים עלה מ-61% ל-84% — חישוב המשלוח הפסיק להתאפס בעת שינוי השיטה. הנטישות בשלב המשלוח ירדו מ-38% ל-9%. טיוטת הסל החזירה למשפך חלק מהמשתמשים שיצאו לבירור המפרט וחזרו מאוחר יותר.
המדדים נמדדו על אותו טראפיק ואותן קבוצות מוצרים — ההשוואה תקינה.
במה שונה עיצוב מותאם אישית מעיצוב סטנדרטי?
עיצוב הזמנה סטנדרטי הוא בונה עם סט קבוע של שלבים: סל קניות, פרטי קשר, משלוח, תשלום. כל עוד החנות מוכרת ללקוחות פרטיים עם משלוח לכתובת, זה מספיק.
ברגע שמופיע סוג שני של קונה, איסוף עצמי ממחסן של שותף או תשלום בחשבונית עם דחייה, מתחילות דרכי עקיפין: מאפייני הזמנה מיותרים, טיפול ידני של מנהל, פתרונות מאולתרים בתבנית. ההיגיון נשאר בראש של העובד, ולא במערכת.
עיצוב מותאם אישית הוא כאשר תרחיש ההזמנה מתוכנן עבור מודל המכירות שלכם, ולא מותאם אליו. השלבים נבנים באופן דינמי: בחירת ישות משפטית מושכת פרטי חשבון ותנאי דחייה, בחירת איסוף עצמי מסירה את בלוק הכתובת ומוסיפה בחירת נקודה, סל קניות עם מוצר בעל מידות גדולות מציע משלוח עם מנוף. המשתמש רואה רק את השדות הרלוונטיים למקרה שלו — הטופס לא מפחיד ולא מכריח למלא דברים מיותרים.
גמישות ההיגיון באה לידי ביטוי בבדיקות ובחישובים. הנחה יכולה להיות תלויה בסכום, בקטגוריית המוצר, בהיסטוריית הקונה ובמחסן המשלוח בו-זמנית. עלות המשלוח מחושבת לפי אזורים, משקל, מידות ואופן הפריקה. קוד קופון מוגבל למוצרים, לאזורים ולסוג הלקוח. כל זה עובד בצד השרת, ולכן לא ניתן לעקוף את הכללים על ידי עריכת הדף בדפדפן.
אינטגרציות — החצי השני של המשימה. ההזמנה עוברת ל-1С עם פרטי חשבון תקינים וסטטוס, מבצעת הזמנה מראש של המוצר במחסן הנדרש, רושמת עסקה ב-CRM, שולחת חשבונית והתראה למנהל האחראי.
אם ההחלפה אינה זמינה, ההזמנה לא הולכת לאיבוד: היא נכנסת לתור ועוברת שוב, והקונה רואה סטטוס מובן במקום שגיאה.
תרחישים לא סטנדרטיים — זה בדיוק לשמם לרוב מזמינים את ההתאמה: הזמנה למספר כתובות, משלוח חלקי, אישור חשבונית, רכישה בליסינג, עיצוב בשם מחלקה. המודול הסטנדרטי לא תומך בענפים כאלה, וכל ניסיון לעקוף אותו ידנית — זה סיכון לטעות ולהזמנה שאבדה.
ספקות טכניים נפוצים
עיצוב הזמנה מותאם אישית חי בתוך הליבה של 1С-Битрикс, ולא לצידה: שלבים, שדות וכללי חישוב משלוח משלו מחוברים דרך אירועים סטנדרטיים ודריסת תבנית הרכיב. לכן עדכוני הפלטפורמה אינם שוברים את הלוגיקה — בתנאי שהשינויים בוצעו בתבנית הבת ובמודול, ולא בקבצי הליבה. להלן — הספקות שעולים לרוב לפני תחילת העבודה.
האם עדכוני Битрикс ימחקו את הלוגיקה המותאמת אישית שלנו?
לא, אם הקוד נמצא בשכבה הנכונה. אנחנו לא נוגעים בקבצי הליבה וברכיבים הסטנדרטיים, אלא מוציאים את הלוגיקה למודול נפרד ולתבנית בת, ונרשמים לאירועים דרך מטפלים. עדכון הפלטפורמה משנה את הליבה — הקבצים שלנו נשארים ללא שינוי.
לפני כל עדכון אנחנו מריצים את תהליך ההזמנה בתרחיש בדיקה על עותק, כדי לתפוס קונפליקטים לפני הפרודקשן.
איך checkout מותאם אישית ישרוד עומס במבצע מכירות?
צוואר הבקבוק בדרך כלל אינו ההזמנה עצמה, אלא חישוב המשלוח וההנחות, שפונה לשירותים חיצוניים. אנחנו שומרים במטמון ספרי עזר, מוציאים בדיקות כבדות למשימות מושהות ומגבילים את מספר הבקשות הסינכרוניות לשירותי המשלוח. הסל והתהליך עובדים על מטמון סטנדרטי עם תגים — בעת שינוי מוצר מתאפס רק הבלוק המקושר, ולא כל העמוד.
האם ניתן להעביר תהליך הזמנה ממנוע אחר?
כן, אנחנו מעבירים את לוגיקת השלבים, כללי החישוב והקשרים למוצרים, מחסנים ושירותי משלוח. תחילה מתעדים את תרחישי ההזמנה הנוכחיים, לאחר מכן משחזרים אותם בצד Битрикс ומשווים את התוצאה על הזמנות בדיקה. נתוני לקוחות והיסטוריית הזמנות מועברים בשלב נפרד עם בדיקת שלמות.
האם עיצוב מותאם אישית תואם ל-1С ול-Битрикс24?
החלפה עם 1С מתבצעת דרך פרוטוקול סטנדרטי: הזמנות, סטטוסים ומלאי מסונכרנים לפי לוח זמנים, ולא ברגע ההזמנה, כדי לא לעכב את הקונה. אם ההזמנה צריכה לעבור ל-Битрикс24, אנחנו מחברים אותו כערוץ נפרד — העסקה נוצרת לאחר תשלום מוצלח, וכפילויות נמנעות לפי מזהה ההזמנה.
נדון במשימה שלכם בנושא עיצוב ההזמנה
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים מכם מינימום של נתוני פתיחה. נאסוף אותם בהודעה אחת — זה יספיק כדי לדון בצורה עניינית במשימה ולציין לוחות זמנים.
- תרחיש עיצוב ההזמנה הנוכחי: רכיב סטנדרטי, תבנית מותאמת אישית או הרכבה במספר שלבים — ומה בדיוק בו לא מתאים.
- לוגיקת העסק של ההזמנה: תנאי משלוח ותשלום, כללי הנחות, סכום מינימלי, שיוך למחסנים ולאזורים.
- אינטגרציות: 1С, מערכות תשלום, שירותי משלוח, CRM, מחסן — מה כבר מחובר ומה צריך להוסיף.
- מגבלות: גרסת הפלטפורמה, המהדורה, התאמות אישיות של קבלנים חיצוניים שאסור לגעת בהם.
- גישות: סביבת בדיקות, מאגר קוד, ייצוא בסיס הנתונים — כדי שההערכה תתבסס על קוד ולא על השערות.
- סדרי עדיפויות: מה קריטי באיטרציה הראשונה ומה אפשר להעביר לשנייה.
- התוצאה הצפויה: המרת סל הקניות, מהירות עיצוב ההזמנה, צמצום פעולות ידניות — לפי אילו מדדים תמדדו הצלחה.
לפי הסעיפים האלה ננתח את הלוגיקה הנוכחית, נעריך את היקף העבודה ונחזור עם תוכנית: שלבים, סדר העלייה לאוויר, נקודות חזרה לאחור. אם חלק מהנתונים אינו זמין — אמרו לנו, ונעזור לאסוף אותם בלי לעצור את המכירות.