Pricing used a static formula in a category where small pricing mistakes immediately affected margin and conversion.
A pricing API in front of the existing platform, with monitoring and a monthly retraining loop behind it.
The live A/B test delivered a 20% margin uplift while keeping the trade-off with conversion explicit and measurable.
Compare Man and Van operated in one of the most price-sensitive corners of e-commerce, UK home moves. Every quote competed in a crowded market, and small pricing mistakes had immediate consequences. Price too low and margin evaporates. Price too high and the customer disappears.
The business already had strong fundamentals. Quotes were generated from the operational realities of a move, including mileage, item volume, labour requirements, and driver rates. But the final price still came from a static equation. It treated every customer with similar logistics as if they had identical willingness to pay.
That was the bottleneck. The company had years of quote and conversion data, but no system for learning where each customer's acceptable range actually sat. The brief was simple. Use the historical data to improve margin without blindly sacrificing conversion.
What dynamic pricing was solving
Dynamic pricing is not random price movement. Done properly, it is a decision system that estimates how likely a given customer is to accept a quote at different price points, then chooses the price that best matches the business objective.
In this case, the objective was expected margin. For each quote, the model estimated conversion probability across a range of candidate prices. Each price point could then be scored using a simple equation.
expected margin = margin if accepted × probability of acceptance
That matters because the highest price is rarely the best price. As price rises, margin per order improves, but conversion falls. The job of the model was to find the point where those forces balance most profitably for that specific quote.
The engine optimised for the top of the profit curve, not the top of the price range
This Plotly chart shows a representative quote. The recommended price is not the cheapest option or the most aggressive one. It is the point where expected margin peaks after factoring in the fall in conversion probability.
Illustrative example based on the deployed pricing logic, not raw client-confidential data.
The modelling challenge
Pricing is easy to oversell. Reach for complex ML before you've understood the data and you'll fit noise. We treated this as a supervised learning problem with one constraint above all. The model had to make better live pricing decisions than the static formula already in production.
That meant building features that captured the commercial reality of a move (customer behaviour, quote context, seasonality, broader conversion signals) and then testing model behaviour carefully across price bands rather than chasing a single offline accuracy score.
The key question was never "can we predict conversion?" It was "can we predict conversion well enough across different candidate prices to make a better pricing decision than the static formula already in production?"
How the system worked in production
We wrapped the model in a pricing API that accepted the features needed for a quote, evaluated conversion probability across multiple price points, calculated expected margin for each, and returned the optimal recommendation to the existing backend.
The delivery architecture was designed for production, not demo conditions. Each API version was containerised, stored in a registry, and deployed through AWS Lambda so the service could scale with traffic spikes. Alongside the model endpoint, we built dashboards for two separate monitoring concerns. Data quality going into the model, and commercial performance coming out of it.
We also put a retraining pipeline in place. It ran monthly on the latest data, versioned every trained model, and made rollback straightforward if any degradation or unexpected behaviour was detected. Pricing behaviour shifts over time, so the system needed to adapt without becoming a black box nobody trusted.
Real-time quote scoring and price recommendation for the existing platform.
Containerised deployment with enough concurrency headroom for live traffic.
Tracked both data quality and the commercial impact of pricing decisions.
Versioned retraining pipeline with rollback support when behaviour changed.
How we proved it
The model was not validated on offline metrics alone. Twenty percent of website traffic was routed through the pricing API while eighty percent stayed on the control logic. Running the treatment and control groups concurrently mattered because it neutralised seasonality and one-off external events that would otherwise distort the result.
The experiment ran for two months, long enough to reach statistical significance. The pricing engine improved margin by 20% while reducing conversion rate by 6%.
That trade-off was commercially positive because the system was explicitly optimising expected margin, not raw conversion. The result was a pricing strategy that captured more value from customers willing to pay while remaining disciplined about where pushing price too far would become self-defeating.
The change worth naming wasn't the uplift. It was that pricing stopped being a fixed rule and became a system the business could tune around its goals. Margin growth was no longer limited to periodic manual changes in a formula; it was a live decision, made quote by quote.