How We Built an AI Pricing Engine That Lifted Revenue 77%

The Problem with Vendor Pricing

The client — a major UK fashion e-commerce retailer — was paying £75,000 per year for an external pricing vendor. The vendor's system operated as a black box: product data went in, price recommendations came out, and nobody inside the business understood the logic between those two steps.

This created three problems. First, the recommendations were generic. The vendor's model was trained across their entire client base, not on this specific business's data. A fashion retailer with consignment stock from 196 marketplace sellers has fundamentally different pricing dynamics than a direct-to-consumer brand, but the vendor treated them the same.

Second, there was no feedback loop. When a price recommendation failed — a product was marked down too aggressively and margin evaporated, or too conservatively and stock sat unsold — there was no mechanism to learn from the outcome. The vendor's model updated on its own schedule, disconnected from the client's real-time sales data.

Third, the vendor had no understanding of the business's broader promotional strategy. They would recommend markdowns on products that were simultaneously being promoted via discount codes, effectively double-discounting. Margin leaked through these conflicts constantly, and nobody could see it happening until the monthly P&L review.

Two Engines, Two Cadences

We built two separate pricing engines, each optimised for a different inventory type.

The warehouse engine runs weekly across 15,000+ owned-stock products. It uses price elasticity modelling to generate markdown recommendations for products approaching end-of-life or season-end. The model calculates the optimal discount depth by analysing historical sell-through rates at different price points, current stock levels, weeks of cover remaining, and category-level demand curves.

The elasticity model is not a single regression. Each product category has its own demand curve, estimated from transaction-level data in the Snowflake warehouse. Dresses behave differently from outerwear. Premium brands behave differently from value brands. The model captures these differences by training category-brand segments separately, then applying Bayesian shrinkage to handle sparse data in long-tail segments.

The consignment engine runs daily across approximately 1,600 marketplace products with two-way pricing logic. This is the more unusual of the two engines. For zero-sellers — products that have been listed but have not sold a single unit in a defined window — the engine recommends price cuts. For fast movers — products selling above the 90th percentile velocity — it recommends price increases.

The two-way logic is critical for consignment stock because the business does not own the inventory. There is no cost of holding, but there is an opportunity cost of page real estate. A zero-seller occupying a category listing position is suppressing a product that might convert. The daily cadence means the engine catches zero-sellers within 48-72 hours of listing, rather than letting them sit for weeks.

The 7-Check Real-Time Monitor

Building a pricing engine is the easy part. Keeping it from doing damage is the hard part. We deployed a real-time pricing monitor that runs every 15 minutes, executing seven automated checks against the live product catalogue.

Check 1: Demand shift detection. If a product's conversion rate changes by more than two standard deviations from its trailing 7-day mean, the monitor flags it. A sudden spike might mean a viral social media mention — the engine should pause markdowns. A sudden drop might mean a competitor has undercut on a key line.

Check 2: Stock velocity alerts. Products selling faster than the model predicted trigger a review. The model may be underpricing, leaving margin on the table. Products selling slower than predicted trigger a different review — the markdown may need to go deeper, or the product may have a merchandising problem unrelated to price.

Check 3: Discount code conflict detection. This was the single most valuable check. The monitor cross-references every active discount code, flash sale, and promotional campaign against the engine's price recommendations. If a product is already subject to a 20% site-wide promotion, the engine will not layer an additional markdown on top. This check alone prevented an estimated £180K in annual margin leakage.

Check 4: Zero-seller wave detection. If the number of zero-sellers across a marketplace seller's catalogue exceeds a threshold, the monitor flags the entire seller for review rather than processing products individually. A wave of zero-sellers usually indicates a systemic problem — poor imagery, incorrect sizing data, or uncompetitive pricing at the seller level.

Check 5: Margin floor enforcement. No recommendation can take a product below a minimum gross margin threshold defined per category. The floor is set by the buying team and reviewed monthly. The engine optimises within the constraint rather than violating it.

Check 6: Rate-of-change limiting. No product can have its price changed by more than a defined percentage in a single cycle. This prevents the engine from making dramatic price jumps that confuse customers or trigger price-match guarantees with marketplace sellers.

Check 7: Cross-category cannibalisation detection. If a markdown on one product is expected to cannibalise sales of a higher-margin product in the same category, the monitor flags the conflict. The merchandising team makes the final call, but they make it with data rather than intuition.

Curious what your margin opportunity looks like?

Beyond the Engine: The Pricing Ecosystem

The engines and monitor are the core, but they operate within a broader pricing ecosystem that we built simultaneously.

Personalised voucher codes tied to CDP segments deliver different discount depths to different customers. A full-price buyer gets no voucher. A lapsing customer gets a deep discount. The voucher system feeds back into the pricing engine — if a segment is receiving vouchers, the engine accounts for the effective price when calculating elasticity.

Dynamic badging on product pages shows social proof and urgency signals: "23 people viewing this," "Only 3 left," "Selling fast." These badges are driven by real inventory and session data, not fabricated. They increase conversion without requiring price reductions, which means the engine can be less aggressive on markdowns for badged products.

Bundle pricing spreads discounts across items to protect per-unit margin. A "3 for £50" offer on items priced at £22 each gives the customer the perception of a discount while maintaining a higher per-unit margin than a straight 25% off promotion would.

Discount code optimization prevents stacking and leakage. Before our intervention, the business was running an average of 4.2 concurrent discount codes at any time, with no system to prevent stacking. Customers routinely combined codes, achieving effective discounts of 40-50% on products that were already marked down. We implemented a hierarchical code system with mutual exclusion rules and priority logic.

The Results

By week five of deployment, the results were unambiguous. Compared to the prior week: +80% units sold, +77% revenue, and +72% gross profit. These are not annualized projections. These are actual week-over-week comparisons from the live system.

The revenue uplift came from three sources. First, the consignment engine's two-way logic was pricing fast movers up, capturing margin that the old system left on the table. Second, the warehouse engine's category-specific elasticity models were finding optimal markdown depths instead of applying blanket percentages. Third, the discount conflict detection eliminated double-discounting, which had been silently eroding margin across thousands of transactions per week.

The gross profit improvement of 72% — slightly below the revenue uplift of 77% — reflects the fact that some of the unit growth came from deeper markdowns on slow-moving stock. This is by design. Moving dead stock at a lower margin is better than holding it at full price indefinitely. The margin floor checks ensure that even the deepest markdowns contribute positively to gross profit.

The annualized value of the pricing workstream across all 9 initiatives is £734K. That is roughly ten times the cost of the vendor we replaced, delivered by a system that the business owns, understands, and can modify without external dependencies. This vendor replacement pattern — swapping expensive SaaS for in-house AI — was one of the highest-ROI plays across the entire transformation programme.

What We Learned

Three lessons from this build that apply to any AI pricing system.

The monitor matters more than the engine. A pricing engine that makes good recommendations 95% of the time will destroy margin on the other 5% unless you have a safety system. The 7-check monitor caught an average of 340 conflicts per week in the first month. Without it, those would have been £180K+ in annual margin erosion.

Category-specific models beat global models. The vendor's global model was not wrong — it was imprecise. When we disaggregated to category-brand segments, the predictive accuracy of the elasticity models improved by 31%. That precision translates directly to margin: less over-discounting on elastic products, less under-discounting on inelastic ones.

The feedback loop is the product. The engines improve every week because they ingest the results of their own recommendations. A static model deployed once and left running will degrade. A model that learns from its outcomes will compound its advantage over time. After 12 weeks, the model's average pricing error had decreased by 44% from its initial deployment.

If you are paying a vendor six figures a year for a black box that makes pricing decisions you cannot explain, audit, or improve, there is a better way.