US Foods sellers (known internally as Territory Managers) relied on three separate systems (Edge, Sous, and the e-commerce portal) plus phone calls just to get a complete picture of their accounts. The most critical signal, credit hold data, lived in Tandem, a system sellers couldn’t access at all. I was brought in to design the Seller Dashboard: a mobile-first risk-management tool embedded in the e-commerce platform that consolidated financial signals into one real-time view, giving sellers the power to act before an account hit a hold. I translated seller needs into data requirements and worked through the Product Owner to validate, signal by signal, what engineering could integrate from Tandem, adapting the design where the data couldn’t follow.

Even though sellers could see most of their account data, the picture was incomplete and scattered. Edge, Sous, and the e-commerce each held a piece of the story, and credit hold status wasn’t in any of them. That lived in a separate system only coordinators could access. So when something went wrong, sellers had to call coordinators, then the coordinators had to look things up, and customers waited and orders stopped cold. The process worked, but it was clunky. Sellers knew there was no good reason for three systems, a phone call, and a middleman just to answer: is this account safe to serve today?

This was a loss-prevention and relationship-protection problem. The business wanted fewer late payments and fewer holds. Sellers wanted visibility and autonomy, and the Seller Dashboard sat directly between the two.

Before talking to a single seller, I aligned with the Product Owner and Product Manager to establish shared ground: team structure, user scope, business goals, and the vision for what the dashboard needed to become. We used an early consulting firm mockup to map assumptions, surface possible scenarios, and make sure we were solving the right problem before committing to a direction.

With the scope defined, I scheduled a working session with 10+ Territory Managers, the group closest to the problem and always willing to co-create. I approached this round without a structured interview guide, an honest conversation, to learn from them. “Walk me through your day. What information do you need before a customer goes on hold?”

I used the initial mockup, with the goal of provoking reactions and getting the conversations started.

The three principles that guided design decisions

1) Reorganize from system logic to seller logic V1 grouped data the way the system stored it. In V2 I reorganized it around the questions sellers actually ask such as Who is at risk? Who is already on hold? Who is safe? The dashboard levels were reorganized by putting risk-first at the top, context in the middle, detail at the bottom.

2) Make status visible at a glance V1 treated all metrics the same, with no color differentiation between a good status like autopay and a critical one like overdue accounts. In V2 I implemented color-coded status logic: red for critical, yellow for caution, neutral for stable. Sellers needed to scan, not read.

3) Reduce friction at the entry point V1 proposed a standalone menu item. In V2 I embedded the dashboard directly into the Payments page as a tab visible only to sellers via feature flag. This eliminated an extra navigation step and put the tool where sellers already were.

Structural changes

• 1st level: seller-prioritized KPIs (open invoices, overdue invoices, accounts close to terms, accounts past terms)
• 2nd level: credit holds, autopay, one-time payment, scheduled payments
• 3rd level: full customer list with filtering by credit status, invoices, and payment type
• Removed breadcrumbs (no longer needed with the new entry point)
• Added date range filters (defaulting to last 6 months to prevent system overload)
• Removed redundant links that duplicated content already in the customer view

During Round 2 analysis, two terms kept surfacing as points of confusion “close to terms” and “past terms“. This wasn’t on my radar going into Round 2. Sellers understood what both terms meant, but the confusion was about timing. An account could be past terms but still have 8 days to pay before a credit hold was triggered. That was called grace period, which gives late-paying customers extra cushion to prevent a credit hold, however it wasn’t reflected anywhere in the dashboard, so the data showed a critical status when it wasn’t.

Rather than guess how sellers were interpreting that window, I ran a quick survey posted directly in the Teams group of all sellers. This gave me the answer to define and display both metrics in the dashboard, and it directly informed the grace period disclaimer we placed above the data table in V3 as “Data does not include the 8-day grace period.”

What V2 proved

The direction was right but gaps remained, terminology needed clarification, metric hierarchy needed refinement, and the table still felt designed for accountants.

What changed in V3

Information architecture reorganized by risk priority. The order of metrics was defined directly by sellers in Round 2. Credit holds and past terms surfaced first, and autopay plus one-time payment were removed because the sellers confirmed they didn’t help prevent or resolve issues.

“Even at the early stages when we only had assumptions and a lot of gaps, she came in prepared, asked the right questions, and kept the project moving. She aligned sellers, stakeholders, and cross-functional teams without letting anything get stuck in the weeds.” Noah K. Product Owner

“We had so many edge cases, but Chio has this way of dissecting complexity and turning it into clarity. Her magic wand took 400 sticky notes and turned them into a grid system the entire org now uses.”
Julie Y. Product Manager

“Chio went above and beyond, she shipped as a leader.” Michael H. Direct Manager