We replaced a £75K/year pricing vendor with an engine we built on 3.6 million transactions. Elasticity modelling across 37,800 products. Real-time monitoring every 15 minutes. This is what it looks like in production.
The client was paying £75K/year for a pricing vendor that generated recommendations based on industry-wide averages rather than their actual customers' behaviour. The recommendations were slow, opaque, and impossible to audit. When a markdown did not perform, there was no feedback loop — just another flat recommendation the following week.
Their customers had price sensitivities unique to their categories, their brand, their inventory cycles. The vendor's generic model missed all of it. So we built a replacement.
Four interconnected systems. We built the whole thing and now we run it.
We processed 3.6 million transactions across 37,800 products with 151 distinct price points to build category-level price elasticity curves. This tells us exactly how price changes affect demand in each product category — not industry averages, their actual customers.
Weekly automated pricing across 15,000+ products. The engine calculates sell-through percentage, maps closing stock targets, determines required rate of sale, applies elasticity adjustments, and outputs optimal markdown recommendations with confidence scoring.
Daily pricing across approximately 1,600 products with two-way logic — price cuts for zero-sellers sitting on the shelf, price increases for fast movers where demand outstrips supply.
Every 15 minutes, a 7-check system runs: demand shift detection, stock velocity tracking, discount code conflict alerts, zero-seller wave identification, margin floor enforcement, category-level anomaly detection, and pricing override logging. Our team watches the alerts.
An unconstrained optimisation model will find the global maximum for a single metric and destroy everything else. Every recommendation from our engine hits hard constraints before it reaches the pricing team:
| Constraint | Rule | Purpose |
|---|---|---|
| Margin Floor | Minimum 20% on every recommendation | Prevents selling below cost or eroding brand value |
| Weekly Price Decrease Cap | Maximum 20% reduction per week | Avoids race-to-bottom dynamics and customer anchoring |
| Warehouse Price Increases | Zero price increases on warehouse stock | Contractual obligation with consignment partners |
| Volume Threshold | Human review for 500+ unit recommendations | Prevents automated errors at scale |
These constraints are enforced at the engine level before any recommendation reaches the pricing team. The customer data platform feeds additional constraints based on segment-level discount suppression, ensuring full-price buyers never see unnecessary markdowns.
These results were measured against a controlled baseline at a major UK e-commerce retailer operating 37,800 products across multiple categories. The pricing agent was one part of a broader engagement that delivered £6.4M in annualised value creation. The pricing workstream alone contributed £734K in full-year impact.
Every Monday morning, the warehouse engine runs against the full 15,000+ product catalogue. It segments products into three liquidation tiers based on time remaining in the selling window — early stage gets minimal adjustments, mid-stage gets active optimisation, end-stage gets aggressive markdowns to clear stock before deadline.
The sell-through calculation is specific to each product's lifecycle. A product live for 3 weeks with 40% stock remaining is in a different position than one live for 8 weeks with 40% remaining. The engine maps these against elasticity curves, producing recommendations that account for both urgency and likely demand response at each price point.
The consignment engine operates daily on a different principle. Products from third-party sellers have a zero-seller problem — approximately 36,000 products sitting with zero units sold at any given time. The engine identifies these automatically and generates price reduction recommendations. Products selling faster than expected trigger price increase recommendations to capture margin.
The real-time monitor ties both engines together. When a promotion drives unexpected demand, the monitor detects the shift within 15 minutes and flags our team. When a discount code conflicts with an existing markdown, the system alerts before margin erosion compounds. Every override is logged, creating an audit trail that feeds back into the elasticity model.
Price elasticity is the percentage change in quantity demanded for a given percentage change in price. An elasticity of -2.0 means a 10% price reduction drives a 20% increase in units sold. An elasticity of -0.5 means the same reduction only drives 5% — making that discount a net negative for margin.
We calculated elasticity at the category level rather than individual product level. Individual products rarely have enough transaction history to produce statistically significant estimates. But categories — dresses, electronics, homewares, accessories — have thousands of data points each, producing robust curves with tight confidence intervals.
The 151 distinct price points across 37,800 products gave us granular resolution. We could identify that womenswear had an elasticity of -1.8 (highly responsive to discounting) while electronics sat at -0.7 (relatively inelastic). The engine automatically discounts womenswear more aggressively to drive volume while protecting electronics margins with smaller adjustments.
These values are not static. The engine recalibrates weekly as new transaction data flows in, capturing seasonal shifts, promotional effects, and changing customer behaviour. Our team reviews the recalibration outputs to catch anything the automation misses.
| Capability | Manual / Spreadsheet | Rule-Based Vendor | Our Pricing Agent |
|---|---|---|---|
| Price points per week | 50-200 | 1,000-5,000 | 15,000+ |
| Elasticity modelling | None | Industry averages | Category-specific from your data |
| Feedback loop | Monthly review | Weekly reports | 15-minute monitoring |
| Constraint enforcement | Manual checks | Basic rules | Hard-coded guardrails + audit trail |
| Two-way pricing | Rarely | Discounts only | Automated increases for fast movers |
| Ongoing operation | Your team | Vendor support desk | Our operators, embedded in your business |
Meaningful results appear within 3-5 weeks of deployment. The engine needs 1-2 weeks to calibrate against live data, and results compound from there. We saw +77% revenue uplift by week five. The key is having sufficient historical data — at least 6 months of transaction history.
At minimum: transaction history (product, price, quantity, date), current inventory levels, and product cost data. Ideally also: customer segment data, competitor pricing signals, seasonal demand patterns, and promotional calendars. We built this engine on 3.6 million transactions — but meaningful models can work with as few as 100,000 if category coverage is broad enough.
Yes. The methodology applies to any business with variable pricing and sufficient transaction volume — hospitality, travel, events, B2B distributors, subscription services. The core principle is the same: understand price elasticity by segment and optimise for your business objective, whether that is revenue, margin, or inventory clearance.
Rule-based systems apply static logic: "if stock > 90 days, discount 20%." Our pricing agent understands that the same 20% discount drives 40% more demand in one category but only 5% in another. It adapts weekly based on actual market response and enforces constraints that prevent over-discounting.
We do. Our team monitors pricing agent performance daily, reviews recommendations weekly, and tunes the elasticity models as market conditions change. The engine recalibrates automatically, but our forward deployed engineers handle edge cases and strategic adjustments. That is the forward deployed model — we build it and we stay to run it.
We will look at your data, tell you what is possible, and build the engine if it makes sense. No commitment beyond the first conversation.