WildberriesOzonMonsterBot - marketplace promotion automation

Overview

Sergey came to me with a fulfilment business and a separate team that promotes other sellers’ products on Wildberries and Ozon. Marketplace promotion rests on buyer signals: the more activity around a product, the higher the algorithm ranks it. Before automation, the team reproduced all of that activity by hand.

I built WildberriesOzonMonsterBot - a universal multi-mode bot on Browser Automation Studio that runs the whole cycle on auto and scales to 200 threads.

Problem

Point A was fully manual labour. Managers prepared accounts, filled them in, attached data, warmed them, ran buyouts and handled reviews. The bottleneck here is physical: one manager comfortably runs one browser tab and one account at a time, switching between them in turn. A person does not work around the clock, and tires.

The numbers show the scale of the routine. Creating one account took 8–10 minutes (SIM card, receiving an SMS, filling in), warming about a day, and promoting a single product end to end around 14 days. At that pace the team’s turnover from one client capped out at roughly 500,000 ₽ - nothing more could be squeezed out by hand.

Solution

The bot is built as a set of modes for each stage of the process, toggled in the settings: profile creation, warming (“cookie seasoning”), product buyouts, pickup-point data collection after purchase, review collection and handling, cart clearing and a manual mode. The service (Wildberries or Ozon) is selected in the same place.

Control is through Excel: a list of products with article, search keyword, size and action. The script walks it with a Foreach loop, parses each row and branches on the action - adding an article to the buyout list, for instance. That way one tool serves any volume of products and both marketplaces.

The main technical win is parallelism. Where a manager ran one account in one tab, the bot scales to 200 threads. That is what removes the physical “one person = one tab” limit the team’s entire economics was built around.

Features

• Multi-mode operation: profile creation, warming, buyouts, pickup-point data collection, review handling, cart clearing, manual mode
• Support for Wildberries and Ozon with service selection in the settings
• Scaling to 200 threads instead of “one manager, one tab”
• Account creation with SMS registration and profile filling
• Profile warming (visiting sites for human-likeness) on auto
• Excel-driven control: article, search keyword, size, action
• Pickup-point data collection after purchase for reporting back to sellers
• Anti-detect profiles and a proxy pool
• Telegram notifications on progress

Development Process

The architecture grew straight out of the bottleneck. The team’s whole prior economics came down to “one manager = one tab = one account”, so parallelism was solved first: an engine that holds many threads and many anti-detect profiles at once. Everything else - the per-stage modes - was built on that foundation.

Splitting into modes rather than a monolith was the second deliberate decision. Profile creation, warming and buyouts differ in pace and logic, and keeping them as separate buttons is better than stitching them into one rigid scenario: the team turns on the stage it needs for the volume it has.

Excel-driven control closed the system: the product list with its parameters lives in a spreadsheet, and the bot executes it in a loop. That makes the tool indifferent to volume - one product or hundreds, Wildberries or Ozon.

Results

Figures are as reported by the client:

• Service throughput rose 108x
• Working speed rose 12x
• Account creation sped up 4-5x - from 8–10 minutes to 1–1.5 minutes with filling
• Profile warming sped up 6x - from a day to 6 hours
• Turnover from one client grew from 500,000 to 1,734,000 ₽
• Any volume became takeable, and service cost fell

What Was Learned

Sergey did not replace his managers with the bot - he gave each of them the tool, and throughput rose because the physical limit was lifted. That is the main takeaway: automation here is not “fire people” but remove the bottleneck the economics is built around. While the ceiling is “one person = one tab”, scale is capped by hiring; once you have 200-thread parallelism, the same headcount does many times more.

The second takeaway is an engineering one that recurs across the portfolio: Excel-driven control plus an engine that holds threads and profiles turns scattered manual work into one operable tool. The same principle - the site is a config, the core holds parallelism - later grew into the full RPA Automation Panel.