Raising Wildberries Pickup-Point Ratings

Overview

A Wildberries pickup point has a rating, and it hits the owner twice: the worse it is, the higher the fines, and below 4 the point simply stops showing on the map - throughput falls, sometimes into a loss. Yet anything can lower the rating: untidiness, noise, loud music. The point’s owner is largely hostage to other people’s moods.

For owners of problem points I built, on Browser Automation Studio, an all-in-one that buys cheap goods routed to the target point, collects order codes and statuses, and posts ratings with reviews automatically - so the point stays visible on the map even through random negativity.

Problem

Wildberries mechanics are such that you can only rate a point after receiving an order there. So to raise a problem point’s rating, real orders have to pass through it: buy a cheap item delivered specifically to that point, wait for the “ready for pickup” status, collect it, and leave a rating.

By hand that is a multi-stage chain per order - prepare a profile, buy, track the status, collect, rate - all of which must be tracked and not lost: which order at which point, with which code, at which stage. Without bookkeeping the system falls apart on day two.

Solution

The bot is built as an all-in-one with modes for each stage of the cycle: convert cookies to profile, product buyouts, collect pickup-point codes and statuses, collect awaiting ratings, leave reviews and ratings for a point, and a test pickup-point selection.

Input data is prepared in Excel - a table of profiles and products with delays - and loaded into the bot. From there everything runs through a database, and that is the key decision: each purchase is written to a report (profile, article, point, status, time and price), codes and order statuses are collected separately, and point ratings separately so problem ones can be found. The final step is the rating-with-review, and its result lands in the same database with Excel export.

The database log is exactly what turns a set of actions into a manageable process: at each stage you can see which order is where, and the code-and-status reporting can be handed to the point’s owner.

Features

• Modes for the whole cycle: buyouts, pickup-point code and status collection, awaiting-rating collection, rating-with-review posting
• Converting cookies into anti-detect profiles
• Input prepared in Excel with configurable delays
• Auto-buyout of cheap goods delivered to a specific pickup point
• Collection of pickup codes and order statuses for reporting to the point owner
• Collection of point ratings and detection of problem points
• Automatic 5-star rating with review after pickup
• Full database log with Excel export
• Proxy pool and anti-detect profiles

Development Process

The platform’s mechanics dictated the logic: you can only rate after actually receiving an order. So the bot is not “post a rating” but the full chain of “buyout → delivery to the target point → status tracking → pickup → rating”, and most of the work went into linking those stages rather than the final action.

Hence the central role of the database. When dozens of orders run in parallel through several points at different stages, there is no way to tell what is where and what has already been rated without a log. So every stage writes to the database: the purchase report, codes and statuses, awaiting ratings, posted ratings. That is bookkeeping for yourself, reporting for the point owner, and protection against processing one order twice.

Splitting into modes lets the cycle run in parts: buyouts today, status collection a day later, ratings later still once orders have arrived. It is the same scheduled re-check pattern as other tasks with deferred status.

Results

• The whole rating cycle - from buyout to rating - runs on auto
• Orders pass through the target points, and a rating is posted only after actual pickup
• The database log keeps dozens of parallel orders under control by stage
• The point owner receives code-and-status reporting
• The point stays visible on the map even through random negativity

What Was Learned

Technically this is a case about bookkeeping mattering more than the target action. Posting a rating is one step; keeping dozens of orders across several points at different stages under control is where the real work is, and it is solved by a database, not by click logic. The log here is at once the system’s memory, its duplicate protection, and its outward reporting.

The second takeaway is about platform mechanics as the source of architecture. The “rate only after pickup” constraint turned a task that is simple on paper into a multi-stage cycle with deferred statuses, and that constraint is what decided what the bot had to be. The same deferred, scheduled re-check logic shows up in iHerb + PochtaGlobal.