Slalom

Enterprise sales tools for a Fortune 500 restaurant supplier

Timeline

> 6 months

Skills Focus

> Product Design
> Workshop Facilitation
> Qualitative Research
> Product Strategy

Role

> Principal UX Designer

01 —

Situation

The client was noticing an alarming cost to their profit margins on small, regional chain restaurants. The problem they noticed was that sales reps were using too many high-tier discounts and it was costing them millions. Their original ask was an oversight dashboard where leaders could monitor proposal and request changes.

— 02 —

Approach

I led a number of experiential workshops (modified event storming) to understand the current state proposal process. Through these workshops I identified a missing stakeholder from the project, the very sales reps causing the issues. After interviewing them, I discovered an opportunity to pivot our work towards improving the flow further up the work stream, building a tool to generate proposals that prevent unnecessary discounts.

— 03

Results

The final design was a major success for both quality of life and the bottom line. The app significantly dropped proposal creation time, meaning sales people could focus on meeting with more clients. Connecting data with business rules prevented over $1 million of unfunded discount losses in the first year. Finally the client was so happy with my work, the contract was extended by 6 months to expand the product to teams working with national clients.

$1 Million

Unfunded discount losses prevented

6 months

Contract extension to expand the project

78%

Reduced proposal creation time

Try the Demo Experience

The discount problem was just a symptom

A Fortune 500 foodservice distributor asked for a dashboard. High-tier discounts were costing them millions a year, and they wanted to watch the reps using them.

I ran modified event storming workshops with sales reps, performance leadership and account support, mapping the proposal process end to end. But a key stakeholder, the reps themselves, were not part of the discussion. So I pushed to include a round of 1:1 user interviews to understand the current experience better. Right away, a rep made the key comment that changed the project.

"Have you seen how this works? We have to search some old database then cut and paste into an excel just to send a proposal."

Building an even slightly complex proposal could take three to four days. Finding accurate product and pricing data meant hunting through an old search tool, then copying results into Excel. Discounting wasn't always a selfish or ignorant move to pump numbers. It was an important lever to maintain relationships.

I proposed moving our work upstream. By building a proposal tool, we solve two problems with one design. Discount misuse becomes something business rules can police in real time before anything reaches a client. At the same time, the teams building these proposals are excited to adopt this new tool and pick up much more time to spend improving the customer relationship. To make sure the final design solved the important challenges for both sides I made the following key decisions.

Flatten the flow.

My first iteration of the design at low fidelity nested the key elements into tabs. Reps struggled in two main ways. First, they would jump right to basket adjustments without addressing key elements like account and location changes which filter down to later steps. Second, it was harder for a person to step away from a single client, then pick up where they were and know what was left. After a round of early testing I opted for a linear flow. Users weren’t prevented from backtracking to make changes, but this helped users understand the value of following the flow of the data.

Show the whole trade

This flow may look like a simple ecommerce cart, but this tool needs to handle contracts that keep a customer stocked regularly. This also means that a vast majority are an evolution of an existing contract.

Each move has to give the customer what they need while also maximizing profit for the business. Moving a restaurant from a name brand to the distributor's own label improves margin, but it changes the pack size, and pack size changes storage and how many deliveries they get. Swap badly, negotiations and relationships suffer, not just the margin. So I adopted an almost git-like design, where removed and converted items don’t just disappear, but are visible and trackable as the basket is adjusted. This also helps the user quickly revert bad changes and reset when necessary.

Cover four regions with one menu

One challenge unique to the customers this project focused on was their scale. All customers in this group operated chains or restaurant groups across multiple distribution zones. Regional distribution centers don't always carry the same items, or the same pack sizes of the same item. A chain still wants one menu across all of them. This led me to a key innovation of this new app: coverage stacks.

Stacks allow a rep to group items into a single slot in the proposal. For example, a chain that offers hot wings at every location. The distribution network may only have the preferred brand at 3 out of the 4 locations, or a certain pack at 2 of 4. By adding multiple items and grouping them in a stack, the customer gets consistency and nobody promises a delivery that can't happen. The stack also lets the rep set priorities so the most desired item is used in as many locations as possible with the rest of the regions.

One design, two solutions

By combining the data sources, building faster interactions, and using business rules to create proper incentives, this design helped solve two big challenges for the business. One financial, one process.

Basket creation time fell 78%, from the three or more workings days mentioned in interviews, down to ~5.5 hours tracked in our analytics. Unfunded discount losses fell over $1m in the first year. The work, especially the process improvements, also caught the eye of the teams working with national clients. The improvements found by this tool led to my company getting an extension with the client. This included the oversight dashboard they asked for initially, which provided even more value with properly structured data underneath.