פיתוח מודרציה של מוצרי מוכרים במרקטפלייס — turnkey

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

פיתוח ותחזוקה של כל סוגי האתרים:

אתרי מידע או יישומי אינטרנט
אתרי תדמית, דפי נחיתה, אתרי חברה, קטלוגים מקוונים, חידונים, אתרי קידום, בלוגים, מקורות חדשות, פורטלי מידע, פורומים, אגרגטורים
אתרי מסחר אלקטרוני או יישומי אינטרנט
חנויות מקוונות, פורטלי B2B, שווקים, בורסות מקוונות, אתרי קאשבק, בורסות, פלטפורמות דרופשיפינג, מנתחי מוצרים
יישומי אינטרנט לניהול תהליכים עסקיים
מערכות CRM, מערכות ERP, פורטלים ארגוניים, מערכות ניהול ייצור, מנתחי מידע
אתרי שירות אלקטרוני או יישומי אינטרנט
פלטפורמות מודעות, בתי ספר מקוונים, בתי קולנוע מקוונים, בוני אתרים, פורטלים לשירותים אלקטרוניים, פלטפורמות אירוח וידאו, פורטלים נושאיים

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

השירותים שאנו מציעים
מציג 1 מתוך 1כל 2062 השירותים
פיתוח מודרציה של מוצרי מוכרים במרקטפלייס — turnkey
בינוני
~5 ימים
שאלות נפוצות

ניהול מוצרים בשוק המקוון: היכן התהליך נשבר

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

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

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

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

מה נותנת מודרציה מנוהלת של מוצרים

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

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

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

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

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

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

בדיקה אוטומטית, ידנית והיברידית

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

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

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

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

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

אנחנו מתאימים את המצב לזרימה שלכם ולפרופיל ההפרות, ולא לפי תבנית — נדון במשימה ונחזור עם הערכה ותוכנית.

שלבי הטמעת מודרציה במפתח סופי

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

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

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

  1. ביקורת מודרציה — אוספים סטטיסטיקה על הכרטיסים הקיימים, מאתרים צווארי בקבוק ושגיאות אופייניות של מוכרים.
  2. תכנון סכימת הבדיקה — מפצלים את הבדיקות בין אוטומציה למודרציה ידנית, מתארים את סטטוסי הכרטיס ואת סיבות הדחייה.
  3. הגדרת כללים — מגדירים כללים לפי קטגוריות, מגדירים עדיפויות ותור לבדיקה ידנית.
  4. אינטגרציה — מחברים את המערכת לקטלוג של המוכר ולפאנל של המ�oderator, מגדירים התראות למוכר על סיבת הדחייה.
  5. בדיקות — מריצים כרטיסים אמיתיים ומקרי קצה, בודקים התראות שווא ומהירות עיבוד התור.
  6. הפעלה ניסיונית — מפעילים על חלק מהקטגוריות, משווים החלטות של האוטומציה לבדיקה ידנית, מתקנים ספים.
  7. מסירת נהלים — מוסרים תיעוד של הכללים, הנחיות ל-moderators ולמוכרים, וסדר שינוי הכללים.

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

מה הלקוח מקבל לידיו

מודרציה של מוצרים היא לא "כפתור אישור", אלא אוסף של נכסים שלפיהם המערכת חיה ומתפתחת בלעדינו. להלן מה שנשאר בדיוק בידי הצוות שלכם לאחר ההשקה.

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

תארו את סכימת הקטגוריות שלכם ואת זרימת הבדיקה הנוכחית — נחזור עם הערכה ותוכנית עבודה.

איך צמצמנו את המודרציה הידנית פי שלושה

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

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

מה שינינו

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

השניים הראשונים נסגרים ללא מפעיל, השלישי עובר לתור עם הקשר שכבר נאסף — היסטוריית המוכר, החלטות דומות, סיבת ההפעלה.

מדדים לפני ואחרי

מדד לפני אחרי
שיעור הבדיקה הידנית 100% ~30%
זמן עד הפרסום עד 24 שעות דקות
טיפול במקרה שנוי במחלוקת ללא הקשר עם היסטוריה ורמז

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

במה שונה מודרציה לפני פרסום מפוסט-מודרציה?

פרה-מודרציה היא בדיקה של כרטיס המוצר לפני שהוא הופך לגלוי לקונים. המוכר שולח את המוצר, המערכת והמודרט בודקים מאפיינים חובה, תמונות, קטגוריה, עמידה בכללי הפלטפורמה, ורק לאחר אישור הכרטיס מתפרסם.

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

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

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

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

הבחירה נקבעת לא על ידי אידיאולוגיה, אלא על ידי קטגוריית המוצר ומחיר הטעות. במקום שבו פרסום מוצר אסור משמעו תביעות מצד הרגולטור ומכה תדמיתית, פרה-מודרציה הכרחית. במקום שבו חשובים מהירות הכניסה של המוכר לפלטפורמה והיקף המבחר, פוסט-מודרציה עם הסרת כרטיס מהירה נותנת יותר.

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

ספקות טכניים נפוצים

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

להלן הספקות הטכניים שעולים לרוב בשלב ההערכה: הם נוגעים לעומס, לחיבור עם מערכות קיימות, לעמידות החוקים בפני עקיפות ולעלות השינויים.

האם המודרציה תעמוד בזרם השיא של העלאות?

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

כיצד המודרציה תשתלב באזור האישי ובמערכות החשבונאות שלנו?

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

מה מונע מהמוכר לעקוף את החוקים?

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

עד כמה יקר לשנות דרישות לאחר ההשקה?

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

תארו כיצד אצלכם מאורגנת קליטת הבקשות ואילו בדיקות כבר קיימות — נחזור עם הערכה ותוכנית אינטגרציה.

נדון במשימת המודרציה שלכם

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

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

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

תארו את המשימה — נחזור עם הערכה ותוכנית, נסמן לוחות זמנים וצעדים הבאים.

הכישורים שלנו:

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1393
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1368
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1139
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1152
  • פיתוח אתר עבור SBH Partners
    פיתוח אתר עבור SBH Partners
    1231
  • פיתוח אתר עבור Red Pear
    פיתוח אתר עבור Red Pear
    641