Day 5 — AI Pricing & Promotion

You just used a spreadsheet that recommends pricing and promotion decisions for PittaRosso.

Is this AI?

What does the system observe from the environment?

Perception is the raw input - everything the system could potentially see before any structure is imposed.

Perception: Everything available: sales, inventory, visits, promotions, spend, prices, costs, competitor behavior, customer identity, brand perception, regional variation.

Representation: Designer choices about what to encode and how: demand aggregated across all 200 stores; products grouped into 8 categories; spend encoded as 3 levels (None / $15K / $43K) - not continuous, not content; promotions as 4 types - not creative or channel execution; price sensitivity as one coefficient per product group per month.

Model: Given the representations, predicts revenues, margin, and unsold inventory for any combination of lever settings.

Constraints: Revenue weight vs. margin weight (sum to 1); write-off penalty on unsold inventory; any manual lever overrides imposed by user.

Algorithm: Greedy local search over the discrete grid.

Behavior: A recommendation: markdowns, spend level, promotion type by month.

Perception: Everything available: sales, inventory, visits, promotions, spend, prices, costs, competitor behavior, customer identity, brand perception, regional variation.

Representation: Designer choices about what to encode and how: demand aggregated across all 200 stores; products grouped into 8 categories; spend encoded as 3 levels (None / $15K / $43K) - not continuous, not content; promotions as 4 types - not creative or channel execution; price sensitivity as one coefficient per product group per month.

Model: Given the representations, predicts revenues, margin, and unsold inventory for any combination of lever settings.

Constraints: Revenue weight vs. margin weight (sum to 1); write-off penalty on unsold inventory; any manual lever overrides imposed by user.

Algorithm: Greedy local search over the discrete grid.

Behavior: A recommendation: markdowns, spend level, promotion type by month.

The model calculates in this order:

1. Paid price per product group = full price × (1 - baseline discount - markdown decision - promotion effect)
2. Units per receipt = baseline UPR × (1 + promotion effect + aggregate discount elasticity × total discount applied)
3. Store visits = baseline visits × (1 + spend lift + aggregate discount effect on visits)
4. Conversion rate = baseline conversion + spend effect + aggregate discount effect on conversion
5. Number of receipts = visits × conversion rate
6. Volume sold per product group = receipts × UPR × product-level price sensitivity × (1 - markdown), capped at available inventory
7. Revenue = volume × paid price
8. Margin = revenue - (volume × unit cost)
9. Unsold inventory = initial inventory - volume sold
10. E12 = (revenue weight × total revenue) + (margin weight × total margin) - (write-off penalty × unsold inventory value)

What did you learn?

Start with the shoes.

What did you learn about the different shoe categories?

What did you learn?

Start with the shoes.

What did you learn about the different shoe categories?

Now the promotions.

The 3x2 promotion was designed to move old inventory. Did it work?

Online marketing.

What role did online marketing play - and when?

What were you trying to do?

Before looking at numbers - what objective function did you choose, and why?

What did you set? What were you optimizing for?

The objective function

E12 = W₁ × Revenue
    + W₂ × Margin
    - Penalty × Units unsold

Where:

• W₁ + W₂ = 100%
• Penalty = 0% to 100%
• Units unsold: volume or value

A human sets these before the algorithm runs.

The algorithm maximizes whatever number results.

What were you trying to do?

Before looking at numbers - what objective function did you choose, and why?

What did you set? What were you optimizing for?

The objective function

E12 = W₁ × Revenue
    + W₂ × Margin
    - Penalty × Units unsold

The marketing optimization algorithm took these as given:

• Price elasticity per product group per month
• Promotion response rates
• Spend lift coefficients

You used them. The algorithm treated them as truth.

They are estimates - produced by a statistical model running on PittaRosso’s historical transaction data before this spreadsheet was built.

That statistical model is a second algorithm in this system. One you never saw in the spreadsheet.

The Impact tab is its output, not its process.

The analysis that produced those numbers is invisible in what you used. The coefficients were estimated, frozen into the tab, and handed to the optimization as fixed inputs.

The quality of every recommendation you generated depended entirely on whether those estimates were accurate.

Two algorithms, two jobs, one sequence

Demand estimation algorithm runs offline, before deployment, on historical transaction data. Learns the statistical relationships between marketing actions and customer behavior. Produces the Impact tab coefficients.

Marketing optimization algorithm runs every time the Strategy tab recalculates. Takes the demand estimation output as fixed input. Finds the lever combination that maximizes the objective function.

The output of demand estimation is the input to marketing optimization.

They are coupled but separate. They do not communicate after that handoff.

Two algorithms, two jobs, one sequence

Demand estimation algorithm runs offline, before deployment, on historical transaction data. Learns the statistical relationships between marketing actions and customer behavior. Produces the Impact tab coefficients.

Marketing optimization algorithm runs every time the Strategy tab recalculates. Takes the demand estimation output as fixed input. Finds the lever combination that maximizes the objective function.

The output of demand estimation is the input to marketing optimization.

They are coupled but separate. They do not communicate after that handoff.

The demand estimation algorithm learns from historical transaction data

To estimate how customers respond to prices and promotions, the algorithm needs a structured record of what happened in the past - what discounts were applied, what promotions ran, and what customers did.

The representation compresses PittaRosso’s full transaction history into the variables the statistical model needs:

• Sales volume per product group per month
• Discount level applied per product group
• Promotion type running in that period
• Marketing spend level deployed
• Store visits and conversion outcomes

Input to demand estimation. Output becomes the Impact tab.

The demand estimation algorithm learns from historical transaction data

To estimate how customers respond to prices and promotions, the algorithm needs a structured record of what happened in the past - what discounts were applied, what promotions ran, and what customers did.

The representation compresses PittaRosso’s full transaction history into the variables the statistical model needs:

• Sales volume per product group per month
• Discount level applied per product group
• Promotion type running in that period
• Marketing spend level deployed
• Store visits and conversion outcomes

Input to demand estimation. Output becomes the Impact tab.

What this representation cannot carry

• Individual SKUs - ~39,000 pairs compressed into 8 product groups
• Store identity - 200 stores treated as one
• Customer segments - 6 million loyalty members reduced to aggregate visit volume
• Competitor behavior - not observed
• Brand perception - no field exists for it

Input

Historical transaction records:

• Sales volumes by product group by month
• Discount levels applied per product group
• Promotion types and timing
• Marketing spend levels deployed
• Store visits and conversion rates observed

All from past seasons - before the spreadsheet was built.

Input

Historical transaction records:

• Sales volumes by product group by month
• Discount levels applied per product group
• Promotion types and timing
• Marketing spend levels deployed
• Store visits and conversion rates observed

All from past seasons - before the spreadsheet was built.

Output

The coefficients frozen into the Impact tab:

• Price elasticity per product group per month: β₁ in the demand model
• Promotion response rates: how each promotion type shifts basket size
• Spend lift: how each spend level shifts visits and conversion rate

Sales volume =
  baseline velocity
  + β₁ × markdown %
  + β₂ × promotion type
  + β₃ × marketing spend
  + ε

What good estimation requires

• Variation in the data
• Enough observations per product group
• A stable regime - the relationship must hold in deployment as in training

We will return to the third requirement.

Pace set the objective function to maximize sell-through rate, with a target of 85% by end of season.

“Change management was one of the most significant challenges: changing the way the team works, changing the approach, learning super quickly how to work in the new environment. The key was making sure that everyone is involved.”

• Valentina Labate, Head of Merchandise Planning

What the system was asked to do

Maximize the percentage of inventory sold by end of season.

What the system did not know

• Sports shoes were already selling fast without additional discounting
• Old casual shoes barely responded to any discount level
• Mid-season stockouts would become a problem if sell-through was too high too fast

The objective was valid.

The constraint set was incomplete.

What happened

Sports shoes were selling at a much higher rate than the same period in prior years - due to the additional discounting the system recommended.

The system was discounting already fast-selling products to hit its sell-through target.

“This happened because we took a uniform approach at first, and didn’t allow the system to consider different sales speed for different products. Once we learned this, we changed the inputs of the system.”

— Valentina Labate

The fix: Labate manually updated the demand estimation coefficients. Sub-category sales trajectories corrected. Model 1 edited by hand.

The mechanism

Objective: maximize sell-through

Demand estimation says: sports shoes
have high price elasticity - discounting
drives significant volume uplift

System recommends: heavy discounts
on sports shoes to hit 85% target

Reality: sports shoes were selling
anyway. The additional discounting
just burned margin.

Root cause: demand estimation was
trained on a world where sports shoes
were always discounted. It never
observed sports shoes selling without
discounts. It could not know they would.

Third requirement for good estimation: stable regime. Here is what happens when the regime is not stable.

What happened

Sell-through rates were higher than ever.

By mid-season, the average pairs per item per store had fallen from 10 to 3.

This fragmentation meant most sizes were unavailable for most items - making them effectively unsellable even with more discounts.

Sales fell. The fix (more discounts) did not work.

What they learned

The pricing and promotion system needed a companion: inventory distribution.

• Improve initial stock allocation across stores
• Enable fast inter-store transfers
• Maintain minimum size coverage per item per store

The system optimized what it could see.

It could not see that selling 97% of one size left a shoe no one could buy.

Representation constraint by omission: no store-level inventory field, no size- level tracking. The system was blind to fragmentation by design.

Summer 2019

Unprecedented for PittaRosso - had never exceeded 70% sell-through.

Fall/Winter 2019-2020

Objective updated: revenue maximization with high sell-through constraint. Revenue and margin goals met in first months. 100,000 pairs redistributed between stores by January.

February 20, 2020

All stores closed. COVID-19.

The AI system was halted.

As of late 2022, it had not been restarted.

What this tells us about AI adoption risk

When you build operations around an AI system, the fallback capability atrophies. The buyers had been sidelined. Their manual expertise had faded.

When the system fails - for any reason, including a global pandemic outside its training distribution - the organization may not be able to return to how it operated before.

Dependency risk is real and hard to see until the system stops.

What PittaRosso has

A decision support system. Two algorithms, a human in the loop, a manual feedback path.

It produces recommendations. Humans act. Humans detect drift. Humans update the model.

The system has all the Day 1 components. But its behavior is a recommendation - not an action in the world. The perception- action loop requires a human to close it every time.

This is not AI in the Day 1 sense.

What would make it AI

1. Automated action - prices and promotions deployed directly within approved constraints

2. Closed feedback loop - actual outcomes feed back to re-estimate demand estimation coefficients automatically

3. Online learning - demand estimation re-runs as new data arrives, not only when a human detects a crisis

Labate’s fix after Crisis 1 was doing step 3 by hand. She updated the Impact tab manually.

In a full AI system that loop closes itself.