Picture a shopper holding an item at the shelf. The label says one price. The till says another. The shopper does not care which system was updated first. The store has broken a promise.
This is an illustrative situation, not a reported incident at a client. It is the lens I use for pricing execution. A pricing screen is one part of the product. The decision must reach the store, take effect at the intended time and leave colleagues able to explain what changed.
My pricing notes break that journey into features such as item retrieval, current and future prices, price history, individual and bulk changes, pricing methods, cost updates and shelf-label printing. They are feature and measurement work, not proof that a particular rollout improved margin. The useful question is how those features combine into a dependable customer experience.
Start with the promise the customer sees
A pricing project can begin with a headquarters workflow because that is where the decision is made. I would begin by describing the promise that decision creates for the customer. What price should apply, to which item, in which place and at which time?
That simple description exposes ambiguities early. A base price is not the same as a multi-quantity offer. A future change is not an active change. A price displayed on a label may need context that does not fit into a single number. The product should make those distinctions clear before the store has to explain them in front of a customer.
The aim is not to add complexity for its own sake. It is to keep necessary complexity from appearing at the worst moment. A team can debate a definition during design. A colleague dealing with a mismatch at checkout often has less time and less authority.
I would use a few representative customer journeys to test the definition. Include a straightforward item, a scheduled change and an offer with conditions. If the team cannot agree on what the shopper should understand in those examples, the pricing interface is not ready to make that understanding automatic.
Make item retrieval dependable
The source features begin with finding the item. That is a sensible place to start because every later decision depends on selecting the right product. A price change applied to the wrong item can be technically successful and operationally wrong.
My notes considered search by product title, barcode, shelf barcode and product identifier, alongside sorting and category or status filters. I would evaluate those routes against the situation in which a colleague uses them. A person standing beside a shelf may have different information available from someone reviewing a category at a desk.
Search results should help the user distinguish similar items. The product should not rely on a title alone when variant, pack or status differences matter. The review should ask whether the selected record is unmistakably the item the person intends to act on.
There is also a useful exception question: what happens when the identifier on the shelf does not lead to a clear match? The system should support investigation rather than encourage a guess. Fast retrieval is valuable only when the result is dependable enough for the action that follows.
Separate the current price from the next price
A colleague may need to answer what the price is now, what it will be later and why it differs from an earlier value. Those are different information needs. Putting them in one undifferentiated history can make a routine question harder to answer.
I would present the active value and its context clearly, while keeping scheduled changes distinct. Effective and end dates should be understandable to the people who rely on them. A future price should not look like a price that has already reached the till.
An illustrative scheduled change may be approved centrally but not yet applied in a store system. The status should say what is known: approved, prepared, distributed or active. Calling every approved record “done” hides the work between the decision and the customer's experience.
Time is part of the requirement, not a formatting detail. The team needs to agree how the change is interpreted across the relevant systems and how exceptions are handled. The public feature record does not settle a particular retailer's timing rules; it identifies a decision that the implementation must make explicit.
Give history an operational purpose
The notes include pricing history, date ranges, sold quantities, margins and printable reports. I would begin by asking what someone is trying to learn from that history. A colleague investigating a mismatch needs a different view from someone assessing a longer-term pricing strategy.
For an operational review, the useful sequence may be the approved change, its intended timing and the evidence that it reached the relevant destination. The question is what happened, not merely which values exist in the database.
For a strategic review, historical price and sales information can support questions, but it should not be presented as proving that a price change caused an outcome. Other factors may differ between periods. The design should help the reviewer understand the comparison rather than reward a convenient story.
I would preserve reasons and ownership alongside the history where the workflow requires them. A list of old values without context can create more investigation work. The point of keeping a record is to make a later decision easier to ground, not just to satisfy a screen requirement.
Design individual changes and bulk changes differently
Changing one item and changing many items carry different review needs. The source material includes both modes, and I would avoid treating bulk change as an individual form with a larger selection box.
A single-item change can show detailed context about the chosen record. A bulk change needs a way to review the affected population, identify exceptions and understand whether the same rule makes sense for every selected item. A filter that looked convenient during selection should not silently become the final audience of the change.
In an illustrative bulk workflow, the team might select a category that includes inactive or unusual variants. The review should make those cases visible before commitment. The user needs to understand what will change and what will remain untouched.
A useful design also records partial outcomes. If some items are accepted and others require attention, the result should not be flattened into a generic success message. The person responsible needs a clear account of the remaining work, including which items were not changed and why.
Keep pricing methods understandable
My notes list several pricing methods, including multi-quantity deals, buy-one-get-one offers, quantity breaks and spend-based discounts. Naming the method is not enough. The product needs an agreed description of the conditions under which it applies.
I would use representative baskets or item combinations to review those conditions. What qualifies? What does not? How should the offer be explained on the shelf and at checkout? The team should inspect examples that sit near the boundary, not only examples that obviously qualify.
This is a place where product wording and transaction behaviour need to meet. A promotion can be configured consistently across systems and still be confusing to a shopper if the displayed explanation is incomplete. Conversely, a clear label cannot rescue a transaction rule that applies differently from what the label says.
The public discussion should not become a full promotion-engine implementation guide. The useful contribution is to make the decision boundaries visible. The detailed rule design belongs with the owners of the pricing, checkout, customer communication and exception workflows.
Treat shelf-label printing as part of completion
The feature list includes shelf-label printing. I would treat that as a step in the execution journey, not a separate convenience feature. If the price at the till changes while the physical label remains old, the shopper receives conflicting information.
The workflow should distinguish generating a label from having it ready for use. Printing succeeds when a file or print job is produced; operational completion requires the organisation's own process for placing and checking the label. Those states should not be confused.
An illustrative label exception might involve a device problem, a missing item or a label that cannot be placed immediately. The system needs an owner for that exception. It should not assume that every printed label reached the right shelf simply because a button was clicked.
The product can help by showing the affected items, the intended timing and unresolved label work together. It can make the gap visible without pretending that a digital record alone observes the physical result. That is an honest boundary between system evidence and store confirmation.
Connect cost information without confusing it with price
The source notes also include upcoming costs and cost updates. Cost and selling price can inform the same decision, but they are not the same record or responsibility. I would make their ownership and timing explicit rather than combine them into a single editable field set.
A cost change may prompt a pricing review. It does not necessarily authorise an immediate price change. The workflow should preserve the difference between information that informs a decision and information that constitutes an approved action.
For an illustrative review, a person might need to see a new cost, the current selling price and a proposed future price together. The product should help them compare those values while making clear which are confirmed, which are proposals and which remain subject to review.
This protects the reasoning as well as the record. If a later reviewer wants to understand why a price changed, they should be able to distinguish the underlying evidence from the final judgement. A useful interface makes that distinction easier to maintain rather than erase.
Define who can change what
Store-facing price changes raise questions of authority. The feature list mentions reasons, histories and changes from item lookup. I would connect those features to explicit permissions and review responsibilities before deciding how easy the action should be.
Who can propose a price? Who can approve it? Which changes may a store colleague make under the organisation's rules? Who resolves an exception? These answers vary by operation and should not be assumed from a generic design note.
The interface should communicate the user's actual authority. A disabled action needs an understandable reason and a route to the right owner. A permitted action should still show its scope and consequences. Convenience should not make an action look smaller than it is.
I would also review the record left by an override. An exception is easier to understand when the reason, affected item, relevant time and responsible decision are preserved. The goal is not to burden the colleague with unnecessary administration. It is to avoid asking the next person to guess what happened.
Make execution status more honest
A centrally approved price needs to move through several steps before it becomes the customer's actual experience. The product should identify those steps and avoid claiming completion from the earliest successful one.
I would describe the expected flow with the people who own it. What is prepared? What is sent? What acknowledgement is available? What evidence shows that the intended value is active? What still needs a physical or human check? The status model should follow those answers.
A failure needs a useful owner and explanation. “Update unsuccessful” may tell a person that something is wrong without telling them what they can do. A better design separates a data issue, an unavailable destination and a review requirement, because each needs a different response.
This is also why I would avoid a large green success banner for a partial result. It encourages the user to stop carrying the task before the system has actually finished it. A dependable product lets someone stop worrying because the remaining work is either complete or clearly owned.
Evaluate the customer journey, not just the workflow speed
My measurement notes include reporting, comparisons, segmentation and experiments. I would use those as a starting point for an evaluation plan, not copy a broad KPI list into the project and assume it measures pricing execution.
For this problem, the first test is whether the intended price and the customer's experience agree, including exceptions. The team should examine mismatches, unresolved distribution work and the time people spend investigating them. A faster headquarters approval does not necessarily mean better store execution.
Where business outcomes are assessed, the comparison needs its own design. A sales change during a promotion can have several explanations. The team should state what is being compared and which other conditions may affect the result. Correlation is useful for asking questions; it is not a licence to announce causation.
I would include colleague experience in the evaluation. Can people explain the current state? Do they know which action is theirs? Does the tool reduce the need to reconstruct a price change across separate screens? Those questions help reveal whether a process that looks efficient on paper works in the store.
Use a small pilot to expose the exceptions
A first pilot should not be designed to produce a flawless demonstration. It should reveal where the workflow is unclear. Choose a limited scope with enough variation to test scheduled changes, bulk actions, label work and the relevant offer conditions.
Include cases that should not proceed automatically. A disputed item identity, an unclear effective date or an unresolved permission question is a useful test of the product. The right result may be to pause and ask the owner, not to finish every scenario quickly.
Before widening the pilot, review training, support and rollback. Who can stop an incorrect change? How will affected records be identified? What information will store colleagues receive? The exact recovery mechanics need implementation work, but the responsibility should be part of the product plan from the start.
The pilot can also show that a proposed feature is unnecessary. If people solve the problem through a simpler, dependable path, keep that lesson. Product work is not measured by preserving every row in the original feature table.
The work after the approval screen
Pricing is easy to describe as a number changing. The real product is the chain of decisions that makes the change understandable and dependable. Item identity, timing, authority, transaction behaviour and physical communication all meet in the same customer experience.
That is why I do not consider the change finished at headquarters. It is finished when the relevant systems and people have a coherent account of what applies, and the exceptions have a clear route to resolution. The shopper should not have to absorb the gaps between those systems.
This is a product point of view drawn from pricing feature and measurement work, not a claim of a measured client outcome. I can help a team pressure-test the journey from decision to store execution before the implementation becomes larger. Start with the shelf promise. Then make every step needed to keep it visible, owned and testable.
Related reading: When the till disagrees: POS exception handling a store team can run.