Pricing Engine

A pricing engine sits downstream of price monitoring and upstream of the price a customer or supplier actually sees. On the acquisition side, it powers instant trade-in and buyback quotes: the engine takes a device's model, condition, and IMEI status and outputs an offer within seconds. On the resale side, the same architecture underlies automated repricing, adjusting listed prices as competitor prices, inventory, and margin floors change. The core function is identical in both directions - map current inputs to a price - even though the acquisition and resale sides optimise for opposite outcomes.

The output quality of any pricing engine is bounded by its inputs. An engine that computes a mathematically correct price from stale, un-normalised, or condition-mismatched competitor data will still produce a wrong price - the rules layer cannot correct for bad data underneath it. This is why evaluating a pricing engine should weigh the data feed (freshness, coverage, condition matching) as heavily as the rules themselves; a sophisticated rules layer running on weekly-refreshed data will be outcompeted by a simpler engine running on data refreshed hourly.

Most production pricing engines separate into three layers: a data layer (competitor and market prices, normalised and matched to the catalogue), a rules layer (margin floors, grading-based price offsets, channel-specific constraints), and an output layer (an automated price update, an instant quote, or a recommendation queued for manual approval). Operators evaluating a pricing engine, whether built in-house or bought from a vendor, benefit from assessing each layer separately rather than treating the system as a single black box - a weakness in any one layer will limit the value of the other two, regardless of how well the rest is built.