ננתח את תהליך המכירות שלכם ו נציע ארכיטקטורה
קטלוג, הזמנות, תשלומים וחילופין עם המערכת החשבונאית — בתרשים, לפני תחילת הפיתוח.
מערכת מסחר אלקטרוני מלווה את המוצר מכרטיס בקטלוג ועד הזמנה משולמת שנמסרה. להלן מודולי המערכת, התהליכים שהיא סוגרת והקשר עם CRM, ERP, מחסן וקופות.
תוכנה למסחר אלקטרוני — מערכת ששומרת נתונים על מוצרים, מחירים ומלאי, מקבלת הזמנות דרך האינטרנט, מבצעת תשלום ומעבירה את ההזמנה לביצוע: למחסן, למשלוח ולהנהלת החשבונות.
מאתר רגיל היא נבדלת בכך שהיא מפעילה לא עמודים אלא אובייקטים חשבונאיים: מוצר, מחיר, מלאי, הזמנה, תשלום, משלוח, החזרה — רשומות שלכל אחת מצב והיסטוריה משלה. אותה הזמנה עצמה עשויה להגיע מאפליקציה, ממכונה אוטומטית, ממנהל מכירות או ממרקטפלייס.
זהו מעגל חשבונאי מעל החזית, ולא החזית עצמה. אפשר להחליף את החזית או להוסיף שנייה בלי לכתוב מחדש את החשבונאות.
שש משימות שלמענן מטמיעים פלטפורמת מסחר אלקטרוני. לפני ההטמעה כל אחת מהן נסגרת ידנית — בגיליונות, בהתכתבות ובשיחות.
מאפיינים, תמונות, מחיר ומלאי נשמרים במקום אחד ומתפזרים לכל ערוצי המכירה. אין פערים בין האתר, האפליקציה והקופה.
ההזמנה נוצרת, נבדקת ומשולמת אוטומטית, מסביב לשעון. אדם נחוץ היכן שנדרשת החלטה: משלוח חריג, החזרה שנויה במחלוקת, סיטונאות.
שריון בעת סיום ההזמנה מונע מכירה כפולה של אותו מוצר. ביטולים בשל היעדר מוצר במחסן מצטמצמים למקרים בודדים.
מחירים והנחות נקבעים בכללים ולא בעריכה ידנית של כרטיסים. תמחור מחדש של קטלוג בן אלפי פריטים אורך דקות והוא הפיך.
הזמנה, תשלום ומשלוח מגיעים להנהלת החשבונות ולניהול המחסן בלי הזנה חוזרת. ההתאמה חדלה להיות עבודה נפרדת.
רואים מה קונים, מה מחפשים ולא מוצאים, היכן נוטשים את סיום ההזמנה ואילו מוצרים מוחזרים. המבחר מתוכנן לפי נתונים.
ייעול אינו «רובוט במקום מוכר», אלא העברת פעולות חוזרות לכללים שהמערכת מיישמת בעצמה ורושמת את התוצאה בהיסטוריה.
הכלל תקף כל עוד תנאיו לא שונו. הבקרה נשמרת: לכל פעולה אוטומטית יש מבצע, זמן וערך קודם ביומן.
מה עובר למצב אוטומטי:
| זמן | מה המערכת עשתה בעצמה |
|---|---|
| 09:41 | תוספת מחיר 18%: חושבו מחדש 1 240 פריטים |
| 10:00 | מבצע «−15% על תה» הופעל לפי לוח הזמנים |
| 10:03 | ביטול הזמנה מס' 14 190: +2 יח' למלאי |
| 10:06 | מלאי נמוך SKU 77-1043: התראה לרכש |
קטלוג — מאגר מובנה של נתוני מוצרים: מה נמכר, במה המוצרים נבדלים זה מזה ולפי אילו סימנים מוצאים אותם.
ממה מורכב קטלוג עובד:

יחידת הבסיס של הקטלוג היא פריט מסחרי עם מק"ט ייחודי (SKU): נתונים בלתי משתנים, תיאור הניתן לעריכה ואובייקטים מקושרים — תמונות, מסמכים, מחירים, מלאי.
פעולות המוניות מתבצעות בייבוא וייצוא: קובץ, API או ייצוא ממערכת חשבונאית. הייבוא עובר תמיד בדיקה: מה ייווצר, מה ישתנה, מה יידחה ומדוע.
נדחה: מק"ט כפול — 9, מאפיין חובה «מותג» ריק — 5, קטגוריה לא מוכרת — 3. עד לאישור לא נכתבה בקטלוג אף שורה.
מחיר — אינו שדה בכרטיס המוצר, אלא תוצאת חישוב לפי כללים ברגע הבקשה. למוצר אחד קיימים בו־זמנית כמה מחירים, והמערכת בוחרת את החל עליו.
לכן אין צורך לתקן מחיר באלפי כרטיסים: די לשנות את הכלל או את מחירון הבסיס.
שכבות התמחור:
כל שינוי מחיר נרשם בהיסטוריה: מי, מתי, לפי איזה כלל ומה היה הערך. עליה נשענים דוחות הרווחיות והבירור של הזמנות שנויות במחלוקת.
הכללים מוכרעים לפי עדיפות ולא נסכמים בעיוורון. סדר חישוב מחיר פריט טיפוסי:
התאימות מוגדרת במפורש: אילו הנחות מצטברות, אילו סותרות זו את זו, ומהו המחיר המזערי המותר. מגבלת המחיר המזערי מונעת מכמה הנחות תקינות יחד להוריד פריט להפסד.
מבצע — כלל שהמערכת מיישמת בעצמה על הזמנות מתאימות. קוד קופון — אותו כלל, שהקונה מפעיל במילת קוד. שניהם מתוארים באותו אופן: תנאי, מנגנון, תקופה, מגבלות.
מה צריך להיות בהזמנה: מוצרים, קטגוריה, מותג, סכום מזערי, אופן משלוח, פלח לקוח, ערוץ מכירה, שעה ביום או יום בשבוע.
אחוז, סכום קבוע, מחיר חדש, הנחה על המוצר הזול ביותר בערכה, משלוח חינם, מתנה, נקודות במקום הנחה.
תאריכי התחלה וסיום, חלונות חוזרים (למשל כל יום שישי), הפעלה ועצירה אוטומטיות בלי מעורבות עובד.
מכסת שימושים כוללת, מכסה ללקוח, קודים אישיים חד־פעמיים, איסור הצטלבות עם מבצעים אחרים, מחיר מזערי לפריט.
קוד יחיד לדיוור או מנה של קודים ייחודיים לנמענים. המנה מיוצאת כקובץ ונעקבת לפי כל קוד.
לכל מבצע רואים: כמה הזמנות, סכום ההנחה, ההכנסה והרווחיות בהתחשב בהנחה, כמה קודים הופעלו וכמה נותרו.
עגלת קניות — טיוטת הזמנה: אוסף פריטים שטרם יצר התחייבות לא לקונה ולא לחנות. המוצר בה אינו משוריין, המחיר אינו מקובע, ולכן העגלה מחושבת מחדש בכל פתיחה.
החישוב מחדש בודק ארבעה דברים: המוצר נמכר, יש ממנו די במחסן, המחיר לא השתנה, ההנחות בתוקף. את השינויים הקונה רואה לפני התשלום, ולא אחרי חיוב הכסף.
מה על העגלה לדעת לעשות:
סיכום לסיום ההזמנה: 3 פריטים, 11 640 סום. שני הפערים הוצגו לקונה לפני התשלום, ולא אחרי חיוב הכסף.

לצד העגלה חיות רשימות שאינן מובילות לרכישה: מועדפים, רשימת המתנה, השוואה לפי מאפיינים, חזרה על הזמנה קודמת. הן מופרדות במכוון — אחרת סיכום ההזמנה חדל להיות חד־משמעי.
רוב העגלות אינן הופכות להזמנה. המערכת שומרת אותן עם חותמת זמן ויודעת להחזיר את הקונה: תזכורת בדוא"ל או במסרון, קישור לשחזור ההרכב, הצעה אישית.
התזכורת נשלחת פעם אחת לפי אירוע ואינה הופכת לדיוור — הסרה מרשימת התפוצה עולה יותר מהזמנה שהוחזרה.
הזמנה — מסמך המקבע את הרכב הרכישה, את המחירים ברגע היצירה, את הקונה ואת תנאי המשלוח והתשלום. משם ההזמנה חיה לפי מערך סטטוסים סופי, וכל מעבר נרשם.
מחירים והנחות מקובעים בעת סיום ההזמנה: שינוי מחיר או סיום מבצע לא ייגעו בהזמנה שכבר נוצרה — אחרת הסכום לתשלום היה נבדל מהסכום בקבלה.
סיום ההזמנה שלב אחר שלב:

סטטוסים טיפוסיים: חדש ← ממתין לתשלום ← שולם ← בליקוט ← נמסר למשלוח ← נמסר ← הושלם. במקביל רצים ענפי ביטול והחזרה. המערך מותאם לתהליך של החברה, אך נשאר סופי ומפורש.
עריכת הזמנה היא פעולה נפרדת עם הרשאות: הוספת פריט, החלפת מוצר, שינוי כמות, תשלום נוסף או החזר חלקי. כל תיקון שומר את הגרסה הקודמת של ההרכב.
מוקד טלפוני — אינו תוכנה נפרדת, אלא עמדת עבודה מעל אותו תור הזמנות. הנציג רואה את אותם אובייקטים שהקונה רואה באזור האישי, ובנוסף פעולות שסגורות בפני הלקוח: עריכת הרכב, הנחה בגבולות מכסה, שחרור שריון, החזר כספי.
פנייה היא רשומה עם סטטוס והיסטוריה בדיוק כמו הזמנה: יש לה ערוץ, נושא, הזמנה מקושרת, אחראי ומועד מענה. לכן השיחה אינה הולכת לאיבוד במסירה בין משמרות, ותוצאתה נראית בכרטיס הלקוח.
מסלול הפנייה שלב אחר שלב:
העבודה היוצאת בנויה באותו אופן: אישור הזמנה לפני ליקוט, שיחה על משלוח חריג, חזרה לעגלה נטושה, טלפון בעניין החזרה שנויה במחלוקת. כל מגע נכתב לאותה היסטוריה שאליה נכתבות הפניות הנכנסות.

החנות אינה שומרת נתוני כרטיסים ואינה מבצעת את התשלום בעצמה: היא מעבירה את הקונה לספק הסליקה, מקבלת את תוצאת הפעולה ומקשרת אותה להזמנה. כל השאר הוא ניהול מחזור חיי התשלום.

| הזמנה | פעולה | סכום | סטטוס |
|---|---|---|---|
| 14 208 | הקפאת סכום | 12 480 | הקפאה |
| 14 201 | חיוב | 6 350 | בוצע |
| 14 177 | החזר | 2 100 | בוצע |
| 14 206 | שחרור ההקפאה | 3 940 | שוחרר |
| 14 209 | סירוב בנק 05 | 890 | ניסיון חוזר |
ההקפאה שוחררה בלי תשלום החזר: המוצר לא נמצא במחסן. שליחה חוזרת של הבקשה לפי מפתח האידמפוטנטיות אינה יוצרת שורה שנייה.
כרטיס אשראי, QR ומערכת תשלומים מהירים, ארנקים אלקטרוניים, תשלום בעת הקבלה, חשבון בנקאי לחברות, פריסה לתשלומים ואשראי, תשלום בנקודות.
תחילה הקפאה: הסכום נחסם בכרטיס אך אינו מחויב. החיוב — לאחר ליקוט ההזמנה. אם המוצר לא נמצא, החסימה משוחררת בלי תשלום החזר.
תוצאת הפעולה מגיעה בבקשת שרת נפרדת, ולא בחזרת הקונה לאתר. דפדפן שנסגר אינו שובר את התשלום: הסטטוס יתעדכן לפי ההתראה.
שליחה חוזרת של אותה בקשת תשלום אינה יוצרת תשלום שני. לכל פעולה יש מפתח שלפיו הספק והמערכת מזהים כפילות.
לאחר התשלום הקופה המקוונת מפיקה חשבונית מס ושולחת אותה לקונה. בהחזרה מופקת חשבונית זיכוי על הפריטים שהוחזרו.
השוואה יומית של הפעולות במערכת מול רשימת הספק ודף חשבון הבנק. הפערים נכנסים לרשימה נפרדת ומבוררים ידנית.
מלאי — כמות המוצר הזמינה למכירה ממש עכשיו. זו אינה הכמות הפיזית במחסן: חלק משוריין להזמנות, חלק בדרך, חלק חסום כפגום.
זמין למכירה = מלאי פיזי − שריונים − חסימות + אספקות מאושרות בדרך (אם מותרת הזמנה מראש).
בכמה מחסנים ונקודות המלאי נספר לכל מחסן בנפרד, ולחזית מוצג הסכום מהמחסנים שמהם אפשרי משלוח לאזור שנבחר.
כיצד בנוי החילופין:
לשריון תמיד יש משך חיים: הזמנה שלא שולמה בזמן משחררת את המוצר בחזרה למכירה — אחרת עגלות נטושות «אוכלות» את כל המלאי הזמין.
| מחסן | בפועל | שריון | פגום | זמין |
|---|---|---|---|---|
| מרכזי | 1 420 | 310 | 24 | 1 086 |
| חנות «מזרח» | 96 | 12 | — | 84 |
| נקודת איסוף מס' 3 | 40 | 8 | 2 | 30 |
| אספקה בדרך | 600 | — | — | 600 |
| זמין למכירה | 2 156 | 330 | 26 | 1 800 |
בפועל הוא המלאי הפיזי, פגום הוא הכמות החסומה. אספקה בדרך נכנסת לזמין רק היכן שמותרת הזמנה מראש. לחזית מוצג הסכום מהמחסנים שמהם אפשרי משלוח לאזור שנבחר.
המשלוח מתואר בשלושה אובייקטים: אופן משלוח, אזור ותעריף. החזרה היא תהליך הפוך עם מסמך משלה, ולא «ביטול בדיעבד».
שליח עד הכתובת, נקודת איסוף, לוקר, איסוף עצמי, חברת הובלה למשלוחים גדולים, משלוח דיגיטלי למוצרים אלקטרוניים.
העלות תלויה באזור, במשקל, בנפח ובסכום ההזמנה. הכללים קובעים סף למשלוח חינם, תוספות להעלאה ולמידות חריגות.
תאריכים וחלונות זמן מחושבים לפי לוח הזמנים של המחסן, זמן הליקוט ולוח הזמנים של המוביל. משבצות תפוסות נסגרות אוטומטית.
ההזמנה נמסרת למוביל דרך API, המערכת מקבלת מספר משלוח וסטטוסי תנועה ומציגה אותם באזור האישי.
הקונה בוחר פריטים וסיבה, המערכת בודקת את המועד ואת זכאות ההחזרה לפי סוג המוצר ומפיקה מסמך עם הוראות.
לאחר הקליטה המוצר חוזר למלאי או נגרע כפגום, הכסף חוזר לאמצעי התשלום המקורי ומופקת חשבונית זיכוי.
החזרה חלקית היא הנורמה: מההזמנה מחזירים פריט אחד מתוך חמישה. לכן ההחזרה נספרת לפי פריטים, וההנחה על כל ההזמנה מתחלקת ביניהם באופן יחסי — אחרת סכום ההחזר ייבדל מהקבלה.
מחסנאי — עובד שמזיז את הסחורה פיזית: קולט אספקה, מניח אותה בתא, מוציא פריטים עבור הזמנה ומוסר את הקופסה שנארזה לשליח. המערכת יודעת על הפעולות האלה לא מפי העובד: כל פעולה מאושרת בסריקת ברקוד.
ההבדל עקרוני. סימון «בוצע» ברשימה מאשר כוונה, הסריקה מאשרת עובדה: מק"ט מסוים, תא מסוים, עובד מסוים, זמן בדיוק של שנייה. שגיאת הקלדה במק"ט צפה בספירת מלאי כעבור חודש; ברקוד שגוי האפליקציה כלל אינה מקבלת.
מה המחסנאי עושה במשמרת:

כל סריקה היא פקודת יומן: המלאי בתא משתנה ברגע הפעולה ולא בערב בעת העברת ניירת. החזית, הקופה והמוקד קוראים את אותו מלאי, ולכן «באתר יש, על המדף אין» חדל להיות מצב עבודה.
דיוק הליקוט — 99,4%: 7 חסימות סריקה במשמרת, כולן תוקנו במקום. הנתונים נלקחים מאותן פקודות יומן ולא מגיליון נפרד.
שליח — החוליה האחרונה בביצוע והעובד היחיד שהקונה רואה אישית. האפליקציה שלו פותרת שתי משימות: להוביל במסלול ולקבע את המסירה כך שלא יידרש לאשר את העובדה אחר כך בשיחות.
הפעולה המרכזית היא סריקת קוד QR במסירה. הקוד מודפס על תווית ההזמנה או מוצג בידי הקונה מהמסך. הסריקה עונה על שאלה שאחרת נפתרת בוויכוח: האם זו ההזמנה שנמסרה, האם לנמען הנכון ובאיזו דקה.
לוגיסטיקן עובד בקצה השני של אותה אפליקציה: מרכיב מסלולים לפי אזורים, משקל, נפח וחלונות זמן, משבץ שליחים, רואה את מפת המשמרת ומברר כשלים — איחור, אי־מענה, סירוב בפתח.
משמרת השליח שלב אחר שלב:

את אותו סטטוס שקבע השליח רואה הקונה באזור האישי, והנציג — בכרטיס ההזמנה. אין «יומן שליח» נפרד: האירוע אחד, ושלושת הצדדים קוראים אותו.
המחסנאי והשליח עובדים באפליקציות שונות ובמקומות שונים, אך מלווים את אותה הזמנה. מקשרים ביניהם לא דוחות בסוף היום, אלא שישה כללים משותפים.
משימת הליקוט, רשימת האריזה ודף המסלול אינם ניירות עצמאיים, אלא תצוגות של הזמנה אחת. פריט שהוסיף נציג מגיע למחסנאי בלי הנפקה מחדש.
הסחורה עוברת מהמחסן לשליח ומהשליח לקונה בסריקה. בכל רגע רואים אצל מי ההזמנה נמצאת פיזית ומאיזו דקה.
את הסימון קובע מי שביצע את הפעולה, ובמקום שבו ביצע. המוקדן אינו מעביר סטטוסים ידנית, ולכן בין העובדה לרישום אין פער של כמה שעות.
שתי האפליקציות כותבות פעולות לתור מקומי ומשלימות אותן כשהקשר חוזר. לכל פעולה יש מפתח, ולכן שליחה חוזרת אינה יוצרת ליקוט שני או מסירה שנייה.
חוסר בקליטה, ערבוב, שבר, סירוב חלקי בכתובת — כל מקרה הופך לרשומה נפרדת עם סיבה ואחראי, ולא לתיקון מלאי שקט.
פריטים בשעה בליקוט, דיוק הליקוט, שיעור המשלוחים בתוך חלון הזמן, זמן בכתובת, שיעור הסירובים החלקיים. העומס והבונוס נספרים לפי הנתונים האלה ולא לפי תחושה.
מכאן גם הדרישה להטמעה: את המחסן ואת המשלוח מחברים למערכת יחד. אפליקציית מחסנאי בלי אפליקציית שליח נותנת מלאי מדויק שאינו מגיע לשום מקום מעבר למסירה.
אזור אישי — גישת הקונה לנתוניו בלי לפנות לנציג: הזמנות, מסמכים, כתובות, אמצעי תשלום, החזרות. כל שאלה שהאזור האישי סוגר היא שיחה שלא הגיעה לתמיכה.
האזור האישי אינו שומר נתונים משלו: הוא מציג את אותם אובייקטים שהנציג רואה בלוח הניהול, אך רק את רשומות הלקוח הזה ורק את הפעולות המותרות לו.
מה יש בו:
ב‑B2B האזור האישי מורכב יותר: לארגון יש כמה עובדים עם הרשאות שונות. הרכש מרכיב הזמנה, המנהל מאשר, והנהלת החשבונות לוקחת את מסמכי הסגירה. ההזמנה אחת, הפעולות מופרדות.
כניסה בקוד חד־פעמי או בסיסמה, גורם שני בפעולות כספיות ובשינוי פרטי קשר, יומן הפעלות עם ניתוק מכשיר זר. שינוי דוא"ל או טלפון מאושר בכתובת הישנה ובחדשה.
את אותן רשומות רואה הנציג בכרטיס ההזמנה: האירועים משותפים, ואין יומן נפרד לאזור האישי. הקבלה ותעודת המשלוח נמצאות במדור «מסמכים».
אינטגרציה — חילופי נתונים מוסכמים עם תוכנה חיצונית: מה מועבר, באיזה פורמט, באיזו תדירות, מי הבעלים של הנתונים ומה קורה בתקלה.
עם מה המערכת מתחברת:

ההחלטה המרכזית באינטגרציה היא האחריות על הנתונים. לכל ישות נקבעת מערכת־בעלים: רשימת הפריטים והמחירים מגיעים מ‑ERP, הלקוחות — מ‑CRM, המלאי — מהמחסן, וההזמנות נולדות במסחר האלקטרוני. עריכה דו־כיוונית של אותו שדה בשתי מערכות מייצרת פערים קבועים, ולכן נמנעים ממנה.
| מערכת | מה מעבירה | הודעות | תוצאה |
|---|---|---|---|
| ERP | רשימת פריטים, מחירים | 4 120 | בלי שגיאות |
| מחסן | מלאי, שריונים | 18 640 | 2 חזרות |
| CRM | לקוחות, פלחים | 1 305 | בלי שגיאות |
| מרקטפלייס | הזמנות, מלאי | 2 470 | 1 בבירור |
אינטגרציה אינה נשברת בהפעלה, אלא כעבור חצי שנה — כשהמערכת החיצונית התעדכנה, כשהערוץ נעלם לשעה או כשלספר הנתונים נכנס ערך בלתי צפוי. שישה כללים קובעים אם החילופין ישרוד אירועים כאלה.
סיום ההזמנה אינו ממתין לתשובת המערכת החיצונית: ההודעה מונחת בתור ומטופלת בנפרד. מחסן שאינו זמין אינו עוצר את המכירות.
העברה שנכשלה נשנית במרווח הולך וגדל. הודעה שלא עברה אחרי כל הניסיונות נכנסת לתור בירור ואינה אובדת.
הודעה שנמסרה שוב אינה יוצרת הזמנה שנייה ואינה גורעת מלאי פעמיים. המקבל מזהה כפילות לפי מפתח הפעולה.
שינוי פורמט יוצא בגרסה חדשה, והישנה ממשיכה לעבוד. הצרכנים החיצוניים עוברים אליה לפי לוח הזמנים שלהם.
כל הודעה נשמרת עם גופה, זמנה, תוצאתה ומספר הניסיונות. בירור תקרית נשען על היומן ולא על זיכרונות.
התאמה סדירה של מדדי מפתח: הזמנות, סכומי תשלום, מלאי. פער הופך למשימה במקום להתגלות בספירת מלאי.
קטלוג והזמנות
תשלומים
מלאי ומחסן
אנליטיקה
האנליטיקה נבנית על נתוני מכירות והתנהגות עצמיים, ולא רק על מוני תנועה חיצוניים. המונה יודע על צפיות, המערכת — על כסף, מוצרים והחזרות.
הדוחות נספרים לפי חתכים: תקופה, ערוץ מכירה, קטגוריה, מותג, מחסן, אזור, פלח לקוח, מבצע. כל מדד זמין בכל חתך ומיוצא לקובץ או למחסן נתונים.

הנפילה החדה ביותר היא בין העגלה לסיום ההזמנה: שם מבררים את שלב ההרשמה, חישוב המשלוח ואמצעי התשלום.
האבטחה נשענת על שלושה דברים: נתוני התשלום אינם מגיעים למערכת החנות, נתונים אישיים נשמרים במידה מוגבלת ותחת בקרה, וכל פעולה בכסף ובהזמנות מותירה עקבות.
מספר הכרטיס מוקלד אצל ספק מוסמך ואינו מגיע למערכת החנות. לחיובים חוזרים נשמר אסימון ולא הכרטיס.
כל התעבורה — ב‑HTTPS. שדות רגישים במסד הנתונים מוצפנים, וגיבויים נשמרים מוצפנים בנפרד מהמעגל הראשי.
מודל תפקידים: מנהל תוכן אינו רואה תשלומים, נציג אינו משנה מחירים. כניסת ניהול — באימות דו־שלבי.
מי שינה מחיר, מי ביטל הזמנה, מי ייצא את מאגר הלקוחות. הרשומות בלתי ניתנות לשינוי ונשמרות בנפרד מנתוני העבודה.
היקף נתונים מזערי הכרחי, משך שמירה, מחיקה לפי בקשה, הסכמות לעיבוד ולדיוור עם תאריך ומקור.
הגבלת תדירות הבקשות, הגנת טפסים מפני ניחוש, בקרה על שימוש חוזר בקודי קופון, בדיקות אנטי־הונאה להזמנות לפני הליקוט.
מעגל נפרד הוא השחזור. גיבויים חסרי תועלת כל עוד לא נבדק שחזורם: פריסת בדיקה נעשית לפי לוח זמנים, ולא ברגע התקלה.
הרחבה היא היכולת לעמוד בצמיחה בלי כתיבה מחדש. שלושה גדלים גדלים: היקף הקטלוג, מספר המבקרים בו־זמנית וכמות ההזמנות בשעה.
הקטלוג נתקל בחיפוש ובסינון, תעבורת השיא — במסירת עמודים, וזרם ההזמנות — במסד הנתונים ובאינטגרציות החיצוניות. גם הפתרונות שונים ומוטמעים לפי הצורך.
שיטות שמיושמות בפועל:
| מדד | נמדד | סף |
|---|---|---|
| תגובת הקטלוג, p95 | 180 מ"ש | 400 מ"ש |
| הזמנות בשעה בשיא | 3 000 | 2 400 |
| תשובות מהמטמון | 86% | 70% |
| אינדוקס מחדש של הקטלוג | 9 דק' | 20 דק' |
| שחזור מגיבוי | 22 דק' | 60 דק' |
המערכת מורכבת ממודולים: כל אחד סוגר את תחום הנתונים והפעולות שלו, והקשרים ביניהם מתוארים במפורש. הפרויקט מושק בחלקים — תחילה קטלוג והזמנות, אחר כך נאמנות, אנליטיקה וערוצים חיצוניים.
פריטים, מק"טים, תיאורים, סטטוסי פרסום, גרסאות כרטיסים וארכיון מוצרים שהוסרו מהמכירה.
עץ מדורים, שיוך מוצר לכמה ענפים, מיון, עמודי נחיתה לאוספים ולמדורים עונתיים.
ספר תכונות עם סוגי נתונים וכללי תצוגה — הבסיס למסננים, להשוואה ולייצוא למרקטפלייסים.
מידות, צבעים ונפחים בכרטיס אחד עם מק"טים ומלאי נפרדים. מארזים הגורעים כמה פריטים.
תמונות, וידאו ומסמכים, הפקה אוטומטית של פורמטים ורזולוציות, סימני מים, שיוך למוצרים.
מחירונים, כללי תוספת מחיר, סולמות כמות, מחירים אישיים וחוזיים, מטבעות, עיגול, מיסים, היסטוריה.
תנאי הפעלה, מנגנוני הנחה, לוח זמנים, מכסות, הפקת מנות קודים, תאימות, מחיר מזערי.
עגלה בין מכשירים, חישוב מחירים וזמינות מחדש, שלבי סיום ההזמנה, הזמנת אורח, חזרה לעגלה נטושה.
תור אחיד להזמנות מכל הערוצים, סטטוסים ומעברים, תיקוני הרכב, תשלומים נוספים, פיצול למשלוחים, ביטולים.
חיבור ספקים, הקפאה וחיוב, החזרים חלקיים ומלאים, טיפול בהתראות, התאמה.
קבלות מכירה והחזרה, חילופין עם קופות מקוונות, שליחת קבלה לקונה, בקרה על מסמכים שלא נשלחו.
מלאי לפי מחסנים, שריונים עם משך חיים, חסימת פגומים, קליטת אספקות והחזרות, ספי מלאי נמוך.
אופני משלוח, אזורים, תעריפים, חלונות זמן ומשבצות, יצירת משלוחים, מעקב סטטוסים, הדפסת מסמכים.
בקשות לפי פריטים, בדיקת מועדים וזכאות, קליטה, החזר כספי, החזרה למלאי או גריעת פגום.
חשבונות, כתובות, ישויות משפטיות וחוזים, היסטוריית הזמנות, פלחים, הסכמות לעיבוד נתונים.
נקודות, דרגות, כללי צבירה ומימוש, תוקף הנקודות, הצעות אישיות, הפניות.
אינדקס חיפוש, נטיות ומילים נרדפות, שגיאות כתיב, מסננים לפי מאפיינים, מיונים, שאילתות ללא תוצאות.
מוצרים נלווים ודומים, «קונים יחד עם זה», אוספים ידניים וכללים על בסיס היסטוריית ההזמנות.
עמודים, מאמרים, באנרים, תגיות מטא וכתובות עמודים, סימון מובנה של מוצרים, מפת אתר, פידי מוצרים.
דוא"ל, SMS, מסרונים ו‑push לפי אירועי ההזמנה, תבניות הודעות, לוח זמנים, יומן מסירה.
דוחות מכירות, רווחיות, מלאי, משפך והחזרות, חתכים חופשיים, ייצוא, חלונות נתונים.
חילופין עם CRM, ERP, מחסן, קופות, שירותי סליקה ולוגיסטיקה, מרקטפלייסים. API, וובהוקים, תורים.
תפקידים והרשאות לפי מדורים ופעולות, אימות דו־שלבי, יומן פעולות העובדים.
כמה חזיתות על ליבה אחת, ריבוי שפות ומטבעות, כמה ישויות משפטיות ומחסנים, אזורים.
את המערכת אין משיקים במלואה בגרסה אחת. הסדר שלהלן משקף תלויות: כל שלב נשען על נתונים שהופיעו בקודם.
התהליכים הקיימים, ספרי הנתונים והמערכות שבבעלותן הנתונים. התוצאה — תרשים ישויות ומפת אינטגרציות.
העברת רשימת הפריטים, הגדרת מאפיינים וקטגוריות, חילופי מחירים ומלאי. בדיקה על נתונים אמיתיים.
סיום הזמנה, סטטוסים, ספק סליקה, הפקת חשבוניות מס, העברה לביצוע. השקה על חלק מהמבחר.
משלוח והחזרות, נאמנות, אנליטיקה, ערוצי מכירה חדשים. כל בלוק הוא גרסה נפרדת עם מדידה.
תארו מה כבר עובד אצלכם: מערכת חשבונאית, מחסן, קופות, החזית הנוכחית. ננתח את התהליך ונציע ארכיטקטורה לפתרון.