Automatic Pricing: Where Manual Repricing Breaks
While the catalog has hundreds of items, manual price editing looks workable: an operator goes around competitors once a day, checks storefronts, and updates values.
At several thousand SKUs, this process stops adding up — not because of people's qualifications, but because of volume: the catalog generates more changes than a couple of hands can process.
The first thing to break is reaction time. Between a competitor's price change and our card update, several hours to a day pass, and during a sale window that is enough for an item to lose impressions and drop to the end of search results.
The operator sees the market at the moment of checking, not at the moment of publication, so there is nothing to close the delay with.
Next, catalog repricing diverges across marketplaces. We sell the same item on several marketplaces with different commissions, logistics, and comparison base — a manually entered price leaves margin somewhere and goes negative elsewhere.
Margin sag shows up separately: the rule "be a little lower than the neighbor" is applied without accounting for delivery cost and return rate; sales grow, but profit per unit falls.
The third failure is operator errors at scale. A mixed-up digit, a discount not removed after a promotion, a price copied into the wrong row: each such edit sells the item below cost, and it is found days later, when orders have already shipped. Automatic pricing removes these bottlenecks — we break down how this is addressed.
What Changes After Implementation: Effect in Measurable Metrics
Before starting, we fix a baseline: for two to four weeks, we capture metrics on a live catalog and traffic without changing anything in prices.
Without this reference point, there is nothing to discuss the implementation effect with — we take four indicators that are equally clear to commerce and engineers.
| Indicator | How we capture it before start | What we record after |
|---|---|---|
| Reaction speed to market | delay between a competitor's price change and our response | response fits within minutes and does not depend on a manager's presence |
| Share of manual edits | how many items a person edits per week | a disputed share remains manual, the rest is handled by rules |
| Margin control | how many items sold below minimum margin | minimum margin is not breached; deviation is only a conscious decision |
| Class of eliminated failures | repeated failures: price rollback, channel mismatch, forgotten promotion | failures become one-off and are visible in a single change log |
We calculate each metric from the price change log and order history, not "by eye" — the value can be rechecked and disputed.
The minimum margin rule and price step limit act as a fuse: automation will not drive an item into loss, even if the market signal turns out to be false.
We leave part of the catalog under manual control for a time — this is the control group. It answers the inconvenient question of what exactly the algorithm delivered, rather than the season or competitors' actions.
On large marketplaces, including Amazon, a seller without automatic price recalculation physically cannot keep up with the market.
Automatic Pricing Modes: Comparison of Approaches
The recalculation mode determines how quickly the catalog reacts to the market and how much work it creates for adjacent systems.
Below are three schemes that are actually chosen between: batch recalculation on a schedule, event-driven recalculation, and a hybrid with manual confirmation. Each covers its own class of tasks and has its own cost — in delay, load, or manual operations.
| Option | When it fits | Limitations |
|---|---|---|
| Scheduled recalculation | Tens of thousands of items, rare competitor changes, even load on the accounting system matters | Reaction lags by the interval between runs; during a sharp market move, the price is incorrect part of the time |
| Event-driven recalculation | A high-turnover product group, the market moves during the day, reaction within minutes is needed | A burst of events creates a queue and repeated writes; duplicate suppression and protection from a recalculation avalanche are needed |
| Hybrid scheme with manual confirmation | Expensive or rare items where a price error is noticeable and margin is thin | Speed is limited by a person; a request queue and escalation rules are needed |
Algorithm Limitations Common to All Modes
Regardless of the scheme, protective rules operate on top of it: a minimum price change step, a margin threshold, a "freeze" window after an edit, and a daily limit on changes per item. Without them, any mode degenerates into price jitter and extra records in the accounting system.
Choosing a mode is a trade-off between reaction delay and volume of manual operations. During task analysis, we look at competitor change frequency, catalog size, and acceptable lag — and select the scheme based on this data.
How We Implement a Repricer: Engineering Work Stages
Implementing a repricer begins not with an algorithm but with an inventory: which price and stock sources are available, with what delay data arrives, and where current rules contradict each other.
The work order below is also the risk removal order: each next stage relies on the previous result, so an error is visible before entering the production environment.
- Data source audit — supplier price lists, warehouse stock, competitor prices, order history. We record update frequency, completeness, and acceptable delay for each stream, and mark fields that cannot be trusted without verification.
- Pricing rules audit — we analyze how minimum margin, rounding, discount thresholds, and category exceptions are currently calculated. The output is a rules map: what is automated, and what remains on manual decisions and requires separate approval.
- Logic design — price is composed of base cost, rules, and hard constraints: margin threshold, minimum change step, and prohibition on going below purchase cost. We set the boundaries before launch so the repricer does not fall into dumping.
- Test run on historical data — we run the rules over past periods of demand and prices and see how revenue, share of won items, and profitability would have changed. This stage filters out logic that looks good on paper and harms on real data.
- Shadow mode — the system calculates prices but does not apply them. We analyze discrepancies with current policy one by one: some indicate a rule error, some indicate data problems.
- Handover to operations — we fix the procedure for reactions to anomalies, responsible persons, category switches, and the order of rollback to previous rules.
- Support — once a quarter, we compare market behavior and profitability, and update thresholds and the exception list.
This sequence provides a manageable repricer implementation: price changes appear only after a rule has been tested on history and in shadow mode.
Handover Package: Rules, Integration Schemes, and Procedures
The package is assembled so that the system can be supported without us: every rule, every data exchange, and every action in case of failure is described in a document rather than left in chat. Below is what the customer receives along with working automation.
- Pricing rules matrix. A table with priorities: which rule triggers first, which categories and product groups it affects, what recalculation step and frequency are applied. It shows why a specific item received exactly this price.
- Allowed price boundaries. Lower and upper corridor for each category — calculated from purchase price and market environment. The system's behavior at the boundary is described separately: stop and hand the item to a human instead of going negative.
- Integration scheme. Which systems send data and in which direction, how often the catalog, stock, orders, and market prices are polled, what happens when product identifiers mismatch, and how duplicate cards are matched.
- Change log. For each price edit, the previous and new value, the rule that triggered, time, and initiator — system or employee — are stored. The log is exported and serves as the basis for resolving disputed situations with suppliers.
- Failure procedure. If a data source is unavailable or no response arrives, the price freezes at the last confirmed value, and the responsible person receives a notification. The procedure for manually stopping automation for an item or category and returning to normal mode is described.
- Roles, access, and escalation. Who can change rules, who disables automation, to whom price conflicts are escalated, and how often rules are reviewed.
- Category manager instructions and acceptance checklist. Step-by-step scenarios for typical tasks and a list of checks by which you accept the work: control items, edge cases, recovery after a source disconnection.
Such a package removes the main risk — that automatic pricing turns into a "black box" that no one can hand over when the team or contractor changes.
Case Study: Eliminated Margin Erosion and Manual Price Edits
A catalog of 40,000 items was sold on three marketplaces, including Amazon, and the price on each had to be maintained separately: its own commissions, promotions, and competitor mix in search results.
Repricing was done manually in spreadsheets — the list was reviewed once a day, so the catalog reacted to a neighbor's dumping with a delay of up to 20 hours.
What It Was Like Before Implementation
The rule "lower the price to hold the item" worked without accounting for cost: the share of items trading below target margin reached 18% of the assortment.
Decisions on the same item across different marketplaces were made by different people, prices diverged — both buyers and comparison algorithms saw this.
What We Changed
The rules were moved into a single service: it collects competitor prices, sales history, and stock, and calculates the decision for each item using a common model. A hard margin floor was set — the price does not go lower, even if the item loses the top of search results.
The change step was limited to avoid starting price wars, and a hold window was added: after an edit, the price is not recalculated for a set time. The exception is only items with ending stock.
Reaction to a competitor's price change dropped from 20 hours to 5 minutes, the share of items below target margin — from 18% to 3%, and the share of decisions without human involvement reached 94%.
Manual edits per week remained around 40 instead of 600 — managers spend them on promotional items. Daily price fluctuations decreased fourfold, and margin stability no longer depended on whether someone managed to update the spreadsheet.
What to Do If Prices Are Already Managed Manually on Marketplaces?
The transition begins not with turning off manual control but with shadow mode: the system calculates price in parallel with a human. From sales and manual edit history, it reconstructs the rules managers applied on marketplaces, and then issues a recommendation for each product.
Discrepancies with the current price are collected into a single report — it shows where the rule works and where it breaks on promotions or stock.
The launch proceeds in stages. First, one marketplace is taken — Ozon — with the largest share of turnover, so as not to master several incompatible export formats at once.
Then the others are connected: each has its own rounding rules, set of promotions, and price application delay. While the new marketplace works in shadow mode, the previous ones live on manual control — sales do not stop for a day.
Roles are separated before the first automatic price application. The category manager sets boundaries — floor and ceiling, minimum margin, change step, and recalculation frequency — and remains the owner of exceptions.
The system holds the rules and recalculates prices; engineers monitor data consistency between marketplace accounts and the accounting system, and monitor the decision log.
Sharp jumps are protected against by mechanics, not by agreement: the change step is limited, the price approaches the target over several cycles, and there is a manual stop and rollback to the previous price profile for a product group.
A marketplace is switched to automatic mode not by calendar but when the share of manager edits stays at isolated cases for several weeks in a row.
Technical Concerns: Limitations, Risks, and Control
The algorithm errs where the input breaks: a competitor set a price below cost, the card went "out of stock", a supplier delivered a price list late.
Without protections, the repricer drives the price beyond the profitability boundary or starts swinging after others' mistakes. That is why the logic is built not around "beat any competitor" but around a corridor within which changes are allowed.
Boundaries are set at the category and individual item level: the lower threshold is calculated from purchase cost and target margin, the upper — from demand elasticity and positioning.
The recalculation step is limited, sharp fluctuations are smoothed, and flagship products are placed in a separate list with manual confirmation.
Who confirms price changes?
Rules define the corridor and automation within it. Everything that goes beyond the framework — going below minimum margin, participating in a promotion, an abnormal drop in demand — enters the exception queue.
They are confirmed by a designated employee: a category manager or commercial director. Each action is recorded in the log with author, reason, and previous price value.
What happens if a data source is unavailable?
The repricer switches to hold mode: the last confirmed price remains, new values are not applied, and a notification is sent to the responsible person.
The same mode turns on when the price list structure differs from expected or when there is an abnormal jump in competitor prices. After the source is restored, the data is verified, and only then does recalculation resume — without catch-up jumps.
Can changes be rolled back?
Yes. Price history is stored with links to the rule and signal source, so rollback is done in a targeted way — by item, category, or period. If after a rules update the price went the wrong way, returning to the previous state takes minutes rather than manual recalculation.
Such a scheme leaves routine to automation — thousands of recalculations per day — and gives disputed decisions to a human. Below we discuss the remaining engineering questions that arise before the start.Let's Discuss the Task: What Is Needed for a Correct Start
For the estimate to rely on facts rather than assumptions, a minimal but sufficient set of data and access is needed. It is not necessary to collect everything in advance: we will start with discussing the task, note what is already at hand, and gather the rest along the way.
- Sales and price history over several seasons: SKU, price change date, promo, sales volume — it shows demand elasticity.
- Cost and margin rules: lower and upper price boundary, rounding, prohibition on going below the threshold.
- Stock, delivery times, and procurement plan — so the system does not raise the price on an item that will run out tomorrow.
- Competitor price sources: list of marketplaces and regions, update frequency, and binding to a specific seller.
- Access to sales channels: a separate read/write price key, test environment, restricted permissions.
- Contractual restrictions: supplier minimum price, fixed contract prices, marketplace requirements.
- 10–20 manual pricing decisions: where they raise, where they hold, where they lower — the basis for checking the logic.
The presence of a test environment largely determines launch timelines: with a sandbox, a pilot on one category starts faster than with edits directly in the production channel.
Describe the task and what you already have — we will return with an estimate and work plan: stages, responsible persons, and a timeline guide.
