Pricing Intelligence

What an agent must know before it can price

Price elasticity is the easy part. The constraints that make a price legal, contractual and commercially survivable are what the model does not have.

Agent must know before: bu ne anlama geliyor

Agent must know before: from data through prediction to a recorded decision

A pricing model can estimate elasticity from transaction history. That is a solved problem and it is not the obstacle.

The obstacle is that most prices are not free to move. They are bounded by contracts, commitments, regulation and relationships that exist nowhere in the sales data.

The constraints that are not in the data

Contractual floors and ceilings. Negotiated customer agreements, most-favoured-nation clauses, distributor terms. Breaching one is not a suboptimal price, it is a legal exposure.

Price relationships within the range. The 500ml cannot cost more per unit than the 1L. A premium line cannot fall below the standard line. These are commercial rules, and a model optimising SKUs independently breaks them routinely.

Channel consistency. What is permitted between online and store, between regions, between direct and distributor. Often unwritten and strongly enforced.

Regulatory limits. In some categories and jurisdictions, price changes are constrained in size, frequency or notice period.

Why this is a data problem before it is a model problem

Elasticity estimation needs history, and history exists. Constraints need to be written down, and mostly they have not been — they live in contracts as prose, in the heads of commercial managers, and in the habit of not doing certain things.

A pricing agent cannot infer a constraint that has never been violated in the data. It sees no evidence of a floor precisely because nobody has ever gone below it.

The order of work

Encoding the constraints comes first. Not because it is more interesting, but because a recommendation that violates one is worse than no recommendation: it costs credibility that the programme does not get back.

The first recommendation a commercial manager sees that breaks a customer agreement is usually the last recommendation they read.

Constraints as a structure, not a filter

Applied as a post-hoc filter, constraints reject recommendations and leave nothing in their place. Applied as the boundary of the optimisation, they shape the recommendation from the start.

The difference shows in what the agent produces when the unconstrained optimum is illegal: a filter produces silence, a bounded optimiser produces the best legal price and states which constraint was binding.

What “which constraint was binding” is worth

It is the most commercially useful output the system produces. A list of prices sitting at a contractual floor is a negotiation agenda — it names, with a number attached, where the contract is costing money.

That output requires the constraints to be explicit. It is unavailable to any system that treats them as filtering rules applied at the end.

The readiness test

Before building the model: can the organisation produce a machine-readable list of what bounds each price, and who owns each bound? Most cannot on first asking. Producing it is the project, and it delivers value even if the pricing agent is never built.

Request a Demo