From 12 days to 2 to resolve a pricing case
Pricing Room is the internal tool Walmart’s pricing and support teams use to find out why a Marketplace offer was unpublished, what thresholds it broke, and how to fix it. I rebuilt it as one investigation, and the average time to resolve a case went from 12 days to 2.
Walmart · 2025 · Shipped
Project sheet
- Sole designer
- 1 PM, content designer, engineering
- 1 month to handoff
I set the goal and the success metrics with the PM at the start. I led discovery and owned the information architecture and interaction design, through prototypes, documentation, handoff and QA.
- Problem
- Support investigated unpublished offers across fragmented tools, often escalating to the pricing team.
- Decision
- Design the screen as an investigation: the reason first, then the offers, the thresholds with their source, and the fix on the same page.
- Result
- Average resolution fell from 12 to 2 days; escalations fell from 27% to 19%, measured three months after the MVP. Targets were 1 day and below 10%.
Four links, days at each
A pricing rule unpublishes a reseller’s item on Walmart.com, and the chain that follows has four links. The seller looks in Seller Center, finds no reason, and contacts support. A SAM or a Partner Support agent investigates by hand across Pricing Room and several other internal platforms, where the same figure can appear twice with two values and none of them says which rule applied. Each analyst has their own route through those tools, so two people can reach two answers on the same item. When the evidence runs out, which happened 27% of the time, the case goes to the pricing team, the only people who can read the rule at its source. Every link adds days, and the item is off the site for all of them.
North starAn analyst should be able to say why an item came down, and fix it, without opening a second tool.
A case, step by step
Before · After
The same job, on two screens
The data an analyst needed was spread across four tools, and the Pricing Room page itself put every threshold in one list, each with the same “reason for the current value” beside it. Nothing said which one had brought the item down.
Before · the old Pricing Room
After · the redesign
What changed
The reason
Before: five ceiling prices, each with the same sentence under it.
After: one line saying which rule unpublished the offer, at the top of the offer.
The numbers behind a threshold
Before: a value, with no way to see where it came from.
After: the benchmark, the anchor and “view formula” next to the number.
Changing a price
Before: empty override fields, with no idea of the effect.
After: a calculator against the benchmark, and an override that expires.
One item at a time, across several tools
Pricing analysts, SAMs and Partner Support were working one item at a time under time pressure, with the data spread across several tools. None of those tools were going away, the thresholds behind a price (ceiling, Buy Box, floor) were owned elsewhere, and any change had to hold at marketplace volume.
The screen as an investigation
The screen organizes an investigation: what came down and why, the seller offers, the thresholds and their sources, then the available correction. The reason, formula and source sit beside the decision they support. Every part is built from Walmart's design system components; what was new was the order they come in.
Triage by severity
Offers are ordered by how badly they are off, above ceiling, below floor or Buy Box ineligible, so the worst case is at the top of the list.
Act where you decide
Rules are calculated from a competitive anchor and edited in place, with current versus proposed thresholds side by side, guardrails on the override, and a duration on it so a temporary fix cannot quietly become permanent.
How I knew
Discovery was a PRD and data review, the current journey mapped end to end, a read of real tickets, interviews with everyone in the chain, and shadowing SAMs, Partner Support and the pricing developers while they worked a case. Five things came back every time: fragmented data, rework, inconsistency between analysts, no clarity on why an item fell, and escalation as the default. The design was then reviewed continuously, in user testing, in design critiques, and with Content Design, the Design System team, PMs and engineering.
More scrolling, one tool
Explaining each rule next to its benchmark takes vertical space. I chose to show the context: an analyst scrolls a little more, and doesn’t need a second tool. We didn’t measure how that trade works for new versus experienced analysts.
Six times faster, and short of the target
- The targets, set before the work
- Bring the average time to resolve a case from 12 days down to 1, and escalations to the pricing team from 27% down to under 10%.
- What happened, three months after the MVP
- Six times faster to resolve a case, and almost a third fewer escalations to the pricing team.
- What that means
- Both numbers moved a lot, and neither reached its target. They are team results: design was one part of them, next to data, engineering and support.
What I got wrong, and what I would do next
Four things from the project’s own retrospective. The ceiling price calculator worked, and that part of the bet paid. Why so many tickets still escalate is unexplained, and that is the thread I would pull first: the design answers “why did this fall”, and the remaining escalations are probably a different question. The Design System team should have been involved earlier; bringing them in late cost consistency I had to argue for later. And the data coverage underneath is thin. The matching algorithms do not give SAMs and Partner Support enough to work with, so the tool is sometimes explaining a number that itself deserves less confidence than it appears to have.