מדוע הגדרת תעריפים במרקטפלייס נשברת עם גידול המוכרים
כל עוד המוכרים נספרים בעשרות, התעריפים חיים בראש של המנהל: מי באיזו תוכנית, למי יש הנחה, למי העלו את מגבלת הפרסום. הגדרת תעריפים ברגע זה נראית כמו כמה כללים בפאנל הניהול.
ברגע שהמוכרים הופכים למאות, והקטגוריות לעשרות, התמחור הידני מפסיק להסתדר: הכללים מתכסים בחריגים, מגבלות המוכר משוכפלות בכמה מקומות, ואף אחד כבר לא יכול לומר מדוע מוכר מסוים משלם בדיוק סכום זה.
מכאן נשבר חיוב המוכרים. כללי תעריפים שנכתבו עבור קטגוריה אחת, בעת העברה לקטגוריה סמוכה, יוצרים חיוב כפול או, להפך, פספוס תשלום. מגבלות המוכר — לפי מספר מוצרים, לפי נפח הזמנות, לפי גישה לקידום — חיים בנפרד מהתעריף ומתעדכנים ידנית.
במרקטפלייס עם מאות מוכרים זה הופך להתאמה בדיעבד: הנהלת החשבונות מגלה אי-התאמות כעבור חודש, המוכר רואה חיוב שאינו יכול להסביר, והתמיכה אינה יכולה לשחזר את החישוב.
המחיר של צוואר בקבוק כזה — לא רק סכומים שנויים במחלוקת. אלו פעולות ידניות בכל שינוי תעריף, חוסר היכולת להשיק קטגוריה חדשה בלי שינויים בקוד, והסיכון המתמיד שמגבלות והתעריף יתפצלו.
ככל שהמרקטפלייס גדל מהר יותר, כך גדל הפער בין האופן שבו התעריפים מתוכננים לבין האופן שבו הם באמת מחושבים.
מפרקים כיצד זה נסגר: כללי תעריפים אחידים, מגבלות המוכר כחלק מהתעריף, וחיוב שמחשב לפי כללים ולא לפי הזיכרון של המנהל.
מה נותן חיוב מנוהל: מהירות, דיוק, צפיות
חיוב מנוהל — זה כאשר התעריף, כללי החיוב, המגבלות והחיובים חיים במעגל אחד, ולא מפוזרים בין מודול המרקטפלייס, סקריפטים עצמאיים וטבלאות שמישהו עורך ידנית.
עבור 1С-Битрикс ו-Битрикс24 זה אומר: התעריף מתואר באופן הצהרתי, החיוב מחושב על ידי מנוע לפי אירועי הזמנה, ופערים מתגלים לפני סגירת התקופה, ולא אחרי תלונות המוכר.
מהירות הוצאת תעריף
תעריף חדש או שינוי תנאים — זו קונפיגורציה, לא פיתוח. המהנדס מתאר את הרכב המנוי, הספים וכללי החישוב מחדש, מריץ על מעגל בדיקה ומפרסם. ההוצאה מפסיקה להיות משימה לספרינט ומסתכמת בשעות, כולל בדיקה על הזמנות היסטוריות.
דיוק החיובים
שגיאות חיוב כמעט תמיד מקורן בחוסר סנכרון: אירוע הזמנה עובד פעמיים, מגבלה חויבה לפי גרסה ישנה של התעריף, עריכה ידנית עקפה את היומן.
מעגל חיוב אחיד מחשב חיובים באופן אידמפוטנטי וכותב כל שינוי ליומן בלתי ניתן לשינוי — שיעור החיובים השנויים במחלוקת יורד למקרים בודדים, ועבור כל אחד מהם נראה איזה כלל ואיזה אירוע יצרו אותו.
סגירת תקופה צפויה
סגירת התקופה מפסיקה להיות בהלה: ההתאמה מתבצעת לפי יומן הפעולות, פערים נראים שורה אחר שורה ומטופלים לפני סיום. זמן הסגירה מתקצר מימים של התאמות ידניות לכמה שעות, והדוח למוכר נבנה מאותם נתונים שמהם נבנה החיוב — פערים בין החיוב לדיווח לא נוצרים.
מה זה נותן בסך הכל
שלושת האפקטים קשורים: מהירות הוצאת תעריף בלי לאבד דיוק, דיוק בלי התאמות ידניות, סגירת תקופה בלי בהלה. מעגל חיוב אחיד מסיר את עצם האפשרות לפער בין מה שחויב למוכר לבין מה שהוא רואה בדוח.
דרכים להגדרת תעריפים: השוואת גישות
הגדרת תעריפים עבור מרקטפלייס כמעט תמיד נתקלת באותה בחירה: להחזיק את הלוגיקה בתוך הפלטפורמה או להוציא אותה החוצה. בפנים — כללים בממשק הניהול שהצוות שלכם רואה ועורך. בחוץ — שירות תעריפים נפרד, שאליו הפלטפורמה שולחת אירועים ובחזרה מקבלת סכומים מוכנים. ביניהם — שילוב היברידי, שבו החישוב מתבצע בשירות, והניהול והדיווח נשארים בממשק הניהול.
הבחירה נקבעת לא לפי "אופנתיות" של הגישה, אלא לפי תדירות שינוי הכללים וכמה מוכרים עוברים דרכם. להלן — השוואה לפי תנאי התאמה ומגבלות, כדי שההחלטה תתקבל לפי הנתונים שלכם, ולא לפי המלצה כללית.
| גישה | מתי מתאימה | מגבלות |
|---|---|---|
| כללים בממשק הניהול | 1-2 רשתות תעריפים, שינויים נדירים, עד כמה מאות מוכרים, נדרש אתחול מהיר | תרחישים מורכבים (מדרגות, ספים, תנאים אישיים) הופכים לכללים מסורבלים; עם גידול בעומס, החישוב מחדש נופל על הפלטפורמה |
| שירות תעריפים חיצוני | תעריפים ומבצעים רבים, שינויים תכופים, תנאים אישיים למוכרים גדולים, נדרש היסטוריית חיובים | קו מתאר נפרד שצריך לתחזק; כאשר השירות אינו זמין, החיובים נעצרים — נדרשת תור ועיבוד חוזר |
| סכמה היברידית | התעריפים משתנים לעתים קרובות, אך הניהול והדיווח צריכים להישאר אצל הצוות שלכם | דורש גבול ברור: מה מחושב בשירות, מה בממשק הניהול; נדרש סנכרון של ספרי התעריפים |
בפועל, לרוב מגיעים להיברידי: כללים וספרי תעריפים נערכים בממשק הניהול, והחישוב והחיובים עוברים דרך שירות שיודע לחשב מחדש בדיעבד ולשמור היסטוריה. כך הצוות לא תלוי במפתח בכל עריכה של תעריף, והפלטפורמה לא נחנקת מחישובים מחדש עם גידול במספר המוכרים.
מגבלה שכדאי לזכור בכל אחד משלושת המסלולים: תעריף הוא לא רק מספר, אלא גם כללי היישום שלו (מה כלול, ממתי הוא תקף, כיצד מחושב מחדש בעת ביטול). אם זה לא מתועד במודל הנתונים, כל גישה תביא לפערים בחיובים. תארו כיצד התעריפים שלכם בנויים ומי משנה אותם, — נחזור עם הערכה ותוכנית למקרה שלכם.
כיצד אנו מיישמים תמחור: שלבי העבודה
יישום תמחור אינו "הפעלת מודול", אלא העברת ההסכמות הקיימות עם המוכרים לכללי חיוב עובדים. לכן אנו מתחילים בביקורת: משווים מחירונים, תנאים לפי קטגוריות, ספי פרסום חינם והנחות אישיות שחיו שנים בטבלאות ובהתכתבויות. בתום התהליך — מפת כללים, שבה עבור כל מוכר נראה איזה תעריף ועמלה חלים עליו ועל איזה בסיס.
בהמשך אנו מתכננים את מודל התמחור: מפרקים את הכללים לרמות (בסיס, קטגוריה, תנאים אישיים), קובעים את סדרי העדיפויות של החלתם ואת הנקודות שבהן החיוב תלוי בסטטוס ההזמנה. כאן גם מגדירים מה קורה בעת החלפת תעריף באמצע תקופה וכיצד לחשב החזרים.
- ביקורת הכללים הקיימים: אוספים מחירונים, חוזים וחריגים, מוצאים סתירות ביניהם.
- תכנון מודל התמחור: רמות הכללים, סדרי עדיפויות, התנהגות בעת החלפת תעריף ובהחזרים.
- הגדרה במערכת החיוב: מקימים תעריפים, שיוכים לקטגוריות ולמוכרים, לוחות זמנים לחישוב מחדש.
- העברת נתונים היסטוריים: טוענים מוכרים, חוזים ויתרות, משווים סכומים שורה אחר שורה.
- בדיקת חיובים על נתונים היסטוריים: מריצים תקופות קודמות ומשווים את התוצאה לחשבוניות בפועל.
- טיפול בפערים: מפרקים כל סטייה עד לשורשה — טעות בכלל או טעות בנתוני המקור.
- מסירת נהלים: מתארים כיצד לשנות תעריף, להוסיף מוכר ולטפל בחיובים שנויים במחלוקת.
בדיקה על נתונים היסטוריים היא שלב מפתח. אנו מריצים תקופות סגורות דרך המודל החדש ומשווים את התוצאה למה שהוצא בפועל: סטייה של אגורות על פני מאה מוכרים מעידה על טעות בסדר העדיפויות של הכללים, ויש למצוא אותה לפני ההשקה, ולא אחרי החשבוניות הראשונות.
לאחר מכן אנו מוסרים את הנהלים ונשארים בתמיכה — תיקוני תעריפים וטיפול בחיובים מתבצעים לפי התהליך המתואר, ולא מהתחלה מאפס.
מה הלקוח מקבל לידיו: קונפיגורציות, תרשימים, נהלים
הפרויקט מסתיים לא בהדגמה, אלא בהעברת חבילה שלפיה הבילינג ממשיך לחיות בלעדינו. כל מה שהוגדר במערכת מתועד בצורה של כללים, תרשימים ונהלים — כדי שבעת החלפת מהנדס או גידול במספר המוכרים לא יהיה צורך לשחזר את ההיגיון מתוך הלוגים.
- כללי תעריפים מוגדרים. תוכניות תעריפים, מגבלות, ספי מעבר בין רמות, תנאי חישוב מחדש וחיובים — בצורה של קונפיגורציה, ולא "ככה זה התפתח היסטורית". ניתן לשנות כלל ולבדוק אותו על מוכר בדיקה, בלי לגעת בנתוני הייצור.
- תרשים זרימות החיובים. מפה מוסכמת: מהיכן מגיע אירוע המכירה, היכן מחושבת העמלה, באיזה רגע נוצרת החשבונית, כיצד משתקפים החזרים וסטורנו. התרשים עונה על השאלה "מדוע למוכר יש בדיוק סכום כזה" בתוך דקה, ולא בתוך חצי יום של בירור.
- מדיניות גישה. תפקידים למוכר, למנהל, להנהלת חשבונות ולתמיכה: מי רואה חיובים, מי יכול לבצע התאמה, מי רק קורא. כל פעולה עם היתרה מותירה עקבה — מי, מתי ועל איזה בסיס שינה את הסכום.
- נוהל התאמות. סדר סגירת התקופה: אילו דוחות מתאימים זה לזה, אילו פערים נחשבים לנורמה, מה עושים בעת פער. ההתאמה מפסיקה להיות פעולה ידנית "בסוף החודש".
- הוראות לתמיכה. פניות טיפוסיות — "הסכום לא התאים", "התשלום לא עבר", "נדרש חישוב מחדש" — עם סדר פעולות מוכן וגבול שמעבר לו מתחבר מהנדס.
- תיעוד הבילינג. תיאור מודל התעריפים, מדריך סטטוסים של חשבונית ותשלום, יומן שינויים בכללים: מה ומתי שינו, כדי שעריכה חדשה לא תשבור הסכמה קודמת עם המוכר.
- תוכנית נסיגה. כיצד להחזיר גרסה קודמת של הכללים, אם התעריפים החדשים הניבו תוצאה בלתי צפויה, ובאיזה רגע הנסיגה עוד בטוחה.
החבילה נשארת אצלכם: היא מספיקה כדי לפתח את רשת התעריפים בכוחות עצמכם או להעביר לקבלן אחר בלי לאבד את ההקשר. תארו את המשימה — נחזור עם הערכה ותוכנית, באיזה היקף הארטיפקטים האלה נדרשים דווקא לכם.
מקרה בוחן: כיצד מרקטפלייס העביר את התמחור למעגל אחיד
מרקטפלייס על 1С-Битрикс עם כמה אלפי מוכרים חישב עמלות בשני מקומות: הוויטרינה חייבה לפי כללים שנכתבו בקוד, והנהלת החשבונות איחדה את אותן פעולות ב-1С. כל שינוי בתעריף — קטגוריית מוצר חדשה, הנחה מדורגת לפי מחזור, תנאים נפרדים למוכרים גדולים — עבר לפיתוח והמתין לריליס. אי-התאמות בחיובים צפו כבר בשלב ההתאמה, ועד רבע מהסעיפים השנויים במחלוקת טופלו ידנית.
מה שינו
התעריפים הועברו למעגל נפרד: כללי האחסון, החישוב והחישוב מחדש של העמלות הפכו לנתונים ולא לקוד. הוויטרינה ומערכת הנהלת החשבונות קוראות את אותה תצורה, ולכן החיוב והרישום נוצרים ממקור אחד.
תעריף חדש מתואר כעת כמערכת תנאים ומפורסם ללא הוצאת ריליס — עם תאריך כניסה לתוקף וגרסאות, כך שתקופות קודמות מחושבות מחדש לפי הכללים שהיו בתוקף במועד הפעולה.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| שיעור אי-ההתאמות בחיובים | עד 6% מהפעולות | פחות מ-0,5% |
| זמן הוצאת תעריף חדש | 2-3 שבועות דרך ריליס | יום אחד בכוחות השירות הפיננסי |
| סגירת תקופת החישוב | 8-10 ימי עבודה | 2-3 ימים |
| טיפול בסעיפים שנויים במחלוקת ידנית | כל רביעי | מקרים בודדים |
המפתח התברר לא כחישוב עצמו, אלא כהתאמה: המעגל מריץ מדי יום את החיובים מול מערכת הנהלת החשבונות ומראה אי-התאמות לפני סגירת התקופה, ולא אחריה. השירות הפיננסי קיבל כלי שבו תעריף חדש מוגדר ונבדק על נתונים היסטוריים לפני שהוא נכנס לפרודקשן.
במה שונה תעריף המוכר מעמלת הקטגוריה?
אלו שתי רמות שונות של מערכת חישוב אחת, ואסור לבלבל ביניהן. עמלת הקטגוריה היא כלל ברירת המחדל של מרקטפלייס: היא משויכת לקבוצת המוצרים וחלה על כל המוכרים שאין להם תנאים אישיים.
תעריף המוכר הוא סט תעריפים אישי שמחליף את ההיגיון הקטגוריאלי עבור חשבון מסוים: תעריף משלו עבור פרסום, אחוז משלו מהמכירה, תנאים משלו בלוגיסטיקה ובאחסון.
הצטלבות תעריפים נוצרת כאשר המוכר סוחר בכמה קטגוריות עם תעריפים שונים, וחלק מהפריטים נופלים תחת מבצע או הסכם אישי. כאן פועל סדר העדיפויות של הכללים: תחילה נבדק החריג האישי לפי מוצר, לאחר מכן תעריף המוכר, לאחר מכן עמלת הקטגוריה, ורק בסוף — התעריף הבסיסי של הפלטפורמה.
הכלל הראשון שמופעל סוגר את החישוב, והשאר אינם מיושמים. בלי סדר קבוע וקשיח, אותה הזמנה בדיוק הייתה מחושבת אחרת בהרצה חוזרת.
היגיון החישוב נשען על ניהול גרסאות: כל שינוי בתעריף הוא רשומה חדשה עם תאריך תחילת תוקף, ולא עריכה של רשומה קיימת. הזמנה שבוצעה ברגע שינוי התנאים מחושבת לפי הגרסה שהייתה תקפה בתאריך האירוע, ולא בתאריך החישוב מחדש.
זה מסיר את הכאב העיקרי — פערים בדוחות, כאשר המוכר רואה סכום אחד באזור האישי, והנהלת החשבונות רואה אחר בכתבי הסגירה.
בפועל, הגדרת תעריפים מצטמצמת לכך שהכללים יתוארו באופן הצהרתי וייבדקו לחפיפות לפני הפרסום. אנחנו מריצים את התנאים החדשים על הזמנות היסטוריות ומראים למי ישתנה החיוב ובכמה — לפני שהתעריף עולה לפרודקשן.
ספקות טכניים בנוגע לחיוב מרקטפלייס
חיוב מרקטפלייס הוא החלק במערכת שבו טעות עולה ביוקר רב ביותר: עמלה שנגבתה באופן שגוי נראית גם למוכר וגם לקונה, והתיקון נעשה בדיעבד. לכן, לפני תחילת העבודה, אנו מתעדים את התשובות לשאלות שעולות לרוב בשלב הקבלה.
כיצד מתבצעת הגירת תעריפים ללא עצירת מכירות?
כללי התעריפים מוציאים לשכבה נפרדת של קונפיגורציה, שאינה קשורה לקוד הוויטרינה. תעריפים חדשים מופעלים באמצעות דגל עבור חלק מהמוכרים, החיוב מתבצע במקביל לפי הלוגיקה הישנה והחדשה, ופערים נבדקים שורה אחר שורה. כאשר אין פערים — מעבירים את השאר. מכירות וביצוע הזמנות אינם נעצרים בזמן זה.
מה עם תאימות לאחור של הזמנות שכבר בוצעו?
ההזמנה קובעת את התעריף ברגע ביצועה, ולא ברגע החיוב. לכן שינוי רשת התעריפים אינו מחשב מחדש עסקאות סגורות: הזמנות ישנות ממשיכות בתנאים הקודמים, וחדשות מתנהלות לפי התעריפים העדכניים. זה מסיר את המקור העיקרי לחיובים שנויים במחלוקת בעת המעבר.
האם ניתן לבטל שינויים בתעריפים?
כן. כל גרסה של רשת התעריפים היא תמונת מצב בלתי ניתנת לשינוי עם תאריך כניסה לתוקף. ביטול הוא מעבר לתמונת המצב הקודמת, ולא עריכה ידנית של חיובים. חיובים שכבר בוצעו נשמרים כפי שהם, והתאמות מתבצעות כפעולות היפוך נפרדות עם ציון הסיבה.
כיצד נבדקת תקינות החיובים?
ביקורת החיובים מבוססת על התאמה: הסכום לפי הזמנות, הסכום לפי כללי התעריפים והסכום בחשבון המוכר חייבים להתאים עד האגורה האחרונה. פערים נכנסים לדוח עם קישור להזמנה ולכלל הספציפי. הדוח מיוצא לפי לוח זמנים, כך שהסטייה נראית באותו יום, ולא בסוף החודש.
האם נדרש גישה לתשתית שלנו?
להגדרת תעריפים מספיקה גישה לסביבת בדיקה וייצוא הזמנות אנונימיות. עבודה בסביבת הייצור תתואם בנפרד ותתבצע בחלון עומס נמוך. אם אין סביבת בדיקה — נפרוס אותה כחלק מהפרויקט, כדי לבדוק תרחישי תעריפים לפני העלייה לאוויר.
נדון במשימה שלכם לתמחור מרקטפלייס
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים נתוני קלט על מודל התמחור שלכם. תארו את המשימה בצורה חופשית — בהמשך נבהיר את החסר ונבנה תוכנית עבודה.
מה שולחים להתחלה:
- הלוגיקה הנוכחית של התעריפים: אילו מסלולים קיימים, מה כלול בכל אחד, איך מחושבת החיוב;
- מאיפה מגיעים הנתונים על המוכרים וההזמנות — קטלוג, אזורים אישיים, מערכת חשבונאות חיצונית;
- איך כיום מונפקות חשבוניות ונרשמות התשלומים, ואיפה זה נשבר;
- דוגמאות למצבים שנויים במחלוקת: החזרות, ביטולים, החלפת מסלול באמצע התקופה;
- תפקידים והרשאות: מי מהעובדים והמוכרים רואה ומה משנה;
- מגבלות לוחות זמנים ומה שאסור לגעת בו במתאר הנוכחי.
מה נבהיר בשיחה עם המהנדס: תדירות החיובים וכללי חישוב מחדש, ההתנהגות בעת החלפת מסלול ובמצב של חוב, האם נדרשת חסימה אוטומטית של שירותים, איך התעריפים קשורים לעמלה על הזמנות ולתשלומים למוכרים. בנפרד נדון בדיווח — אילו חתכים נדרשים לכם ואילו רואה המוכר.
השלב הבא הוא כזה: אנחנו מנתחים את החומרים שלכם, שואלים שאלות ממוקדות וחוזרים עם הערכה ותוכנית — שלבים, הרכב העבודות ומה יידרש מצדכם. אם במהלך הדרך יתברר שחלק מהלוגיקה פשוט יותר לסגור בהגדרה של המתאר הקיים, ולא בפיתוח נוסף, נגיד זאת ישירות.
תארו את המשימה — נחזור עם הערכה ותוכנית.