Pricing + merchandising / evidence-led perspective
A pricing recommendation override is a decision to change, defer, or reject a recommended price or promotion before the choice reaches stores. The decision is a useful place to investigate how the program works, but it does not by itself show why the result happened or which team was right.
In grocery pricing, a discussion may center on a specific choice: hold a promoted shelf price, use a different price, delay the change, or follow the recommendation as written. The explanation may be in the inputs, the decision process, the promotion setup, or store execution. Start with the record of that decision before choosing a cause.
Why would merchandising question a pricing recommendation?
Merchandising may question a recommendation when the evidence, business context, or path to execution is unclear. Possible issues include a data source that cannot be reconciled, a promotion mechanic that changed, a category exception, competing decision rights, or work that cannot be completed before the trading window. These are possibilities to check, not conclusions about a particular retailer.
Write down the recommendation as it appeared at the time, what merchandising understood it to mean, what changed in the final decision, and the reason each person recorded. That separates a different reading of the same information from a genuinely different set of inputs.
What evidence should we review after an override?
Start with one recent decision and gather the records the two teams used before it was changed. The exact records vary by retailer, but a useful review may include:
- The recommended price or promotion and the version shown to the decision maker.
- The available input snapshot, such as the cost, competitor, inventory, or promotion data used for that recommendation.
- The category or promotion context and any exception entered before approval.
- The decision owner, approval path, and reason given for changing or deferring the recommendation.
- The store, shelf-label, promotion, or point-of-sale check that shows what happened after approval, if the change was approved.
If a record is unavailable, record that as an observation. Do not fill the gap with a later reconstruction presented as if it were visible at the time. Keep the original source, timestamps, and people involved together where those details are available.
How should a team document an override before interpreting it?
Keep the decision reference, each team's evidence, and the remaining unknowns in one note. That makes it easier to compare perspectives while preserving the difference between a recorded fact and an explanation that still needs checking.
| Field | Record | Why it helps |
|---|---|---|
| Decision | Item, price zone or store set, promotion, recommendation version, and effective date | Confirms that people are discussing the same event |
| Recommendation | Suggested action and the input snapshot available at the time | Shows what was presented to the decision maker |
| Change | Whether the action was accepted, edited, deferred, or rejected | Keeps different decision outcomes distinct |
| Rationale | The reason recorded by each participant, in their own terms where possible | Preserves differing explanations without choosing a winner |
| Follow-through | Approval record and available shelf, label, or POS check | Separates an approval decision from later execution |
| Unknowns | Missing source, conflicting timestamp, or fact that cannot yet be verified | Prevents a gap from being filled by assumption |
| Next check | Evidence to locate, person responsible, and review date | Turns the discussion into a bounded follow-up |
Illustrative example: a changed promotion recommendation
This is a fictional example for demonstrating the method, not a customer finding. A pricing recommendation shows one promotion mechanic, while a merchant recalls a different mechanic in the category plan. The team records both descriptions, confirms the item and effective dates, and checks the versions of the recommendation and category plan that were available before approval. If those records disagree, the next action is to ask the owners of those sources which version governed the decision. If the versions match, the team can document that fact and ask what other evidence explains the different recollections. Neither outcome alone proves that a team or system caused a financial result.
Some decisions pass through more than one change: a recommendation can be edited, approved, and then adjusted again before reaching a store. Record each transition separately when the available history supports it. Collapsing the chain into a single “override” can hide whether the question concerns the recommendation, approval, or execution. If the system does not preserve each version, say so and treat the sequence as uncertain.
Avoid comparing raw override counts without defining what is counted. A deferred decision, a rejected recommendation, and an approved change that was not executed are different events. If teams compare rates, state the denominator and the period used, and do not infer a target from another retailer's figure without evidence that the programs are comparable.
Does an override prove that the recommendation was wrong?
No. An override records a change in the decision; it does not establish whether the original recommendation was sound or whether the final shelf price was executed correctly. The recommendation may have used incomplete context, or the override may have introduced a mismatch. Store execution can also differ from both intended choices.
To distinguish these cases, compare the recommendation and its inputs with the final approved decision, then check the execution record. If the information was sound but the decision changed, examine the decision path and rationale. If the approved change did not reach the shelf or point of sale as expected, examine the handoff and execution evidence. A single example can guide questions; it cannot establish a financial cause.
How can we tell which part of the program deserves investigation?
Use the evidence from the decision to choose what to check next across the program's operating dimensions:
- Data Readiness: Could the teams trace the inputs used for the decision?
- Decision Process: Was the decision owner and escalation path clear?
- Incentives: Did the measures used by pricing, merchandising, and stores support compatible choices?
- Labor Capacity: Could the people responsible complete the required work in the available window?
- Enforcement: What record shows that approved prices, labels, and promotion mechanics reached stores as intended?
- Adoptability: Could the people accountable for the category understand the recommendation and explain the next action?
These prompts organize an investigation; they do not assign a cause. For example, an unclear override log may point to a recordkeeping question, while a missing shelf check may leave execution uncertain. Neither observation alone explains the program's financial performance.
What if pricing and merchandising give different answers?
Keep the answers separate and ask what each person observed. A difference is a discussion signal, not proof that either person is wrong. Check whether both people are talking about the same recommendation, inputs, date, category, and execution outcome. Their disagreement may reflect a different evidence set; agreement may still leave a shared blind spot.
The free Pricing Reality Check asks eight questions about Data Trust behind one live decision. A person can complete it independently; inviting a colleague is optional. If the two perspectives differ, identify the record that would help explain the difference before choosing a corrective action.
When is the free check enough, and when is a broader audit useful?
The free check is a focused review of Data Trust, not a complete assessment of a pricing or promotion program. A strong result on its eight questions does not rule out constraints in Decision Process, Incentives, Labor Capacity, Enforcement, or Adoptability.
The $295 Adoption Gap Audit is a broader self-guided review for teams with a live program. Its 48 statements cover six dimensions and include a 90-day playbook and 50-question RFP bank. It helps organize evidence and a response; it does not prove one cause of financial performance.
What should we leave the review with?
Leave with one question to investigate, the evidence needed to answer it, an owner for locating that evidence, and a date to review what it shows. If the evidence supports a change, record the first action and how the team will check the result. If it does not, keep the uncertainty visible and choose what to examine next.
For a new or inherited program, the same approach keeps a review grounded in operating facts: begin with a recent recommendation, trace what each team saw, follow the decision through execution, and separate an observed gap from a possible explanation.
Start here: https://getgapsignal.com/pricing
Compare ways to proceed
If the current pricing program is live and the open question is adoption or execution, read GapSignal vs a pricing platform: when to diagnose instead of replace.
If you are deciding between a self-guided review and outside advisory support, read GapSignal vs a pricing consultant: what $295 buys and what it doesn't..
Author note: vendor-agnostic. Built for leaders already running a live pricing or promotion program.
A structured next step
Look across the full operating picture.
The free Pricing Reality Check can surface an evidence gap worth investigating. The Adoption Gap Audit uses 48 diagnostic indicators across six dimensions to organize a practical 90-day response.
Explore the Adoption Gap Audit