Some errors needed an expert.
A new configurator for Dell's channel partners, designed to handle the errors that used to require a specialist.
Dell's existing configurator is where internal sellers build their quotes. It works, and it wasn't going to be redesigned.
The growth was on the partner side. So Dell funded a second platform, Premier CP, built alongside the one internal sellers still use. That decision set the terms for everything: a new product, a familiar problem, and no permission to touch the system that works.
The familiar problem was error resolution. The configurator reported errors accurately. But some of them couldn't be resolved by the person in front of the screen. Those went to a Technical Sales Representative, a TSR. On complex products, getting a configuration back took about a day. Sometimes longer. And it happened to experienced internal sellers as often as it happened to partners.
I was accountable for how a configuration gets built and repaired on the new platform, working with a PM, engineers and other product designers. The team's early instinct was to reorganise a dense screen. Redirecting that toward the cost of escalation, before anything was drawn, is the decision the rest of the project rests on.
Status when I left in February 2026: designed, validated in usability testing, handed to engineering. Not built. Every target below is what we designed against, not a measured result.
No product screens, because the platform isn't public. The diagrams are mine.
So they stopped and called a TSR.
Dell's configurator worked. It checked a configuration against the rules and flagged what didn't fit.
The trouble was what came next.
Some errors were simple. A part conflicts with another, you swap it, you keep going. But on complex products the message named the problem without saying how to fix it. A seller could see something was wrong and have no idea what to change. Sometimes there were several errors in one configuration, with no way to know which to deal with first.
The cost wasn't the error. It was the wait. A seller sends the configuration to a TSR and waits. Sometimes a few hours. Usually about a day. Occasionally several. The customer is waiting too.
The catalogue kept moving. Products were updated and parts deprecated often enough that a configuration valid last quarter could fail today. When it did, the message explained neither the failure nor the change behind it. That's why experienced internal sellers hit this as often as partners did. It was never a gap between two kinds of users. It was a gap between naming a problem and helping someone solve it.
Senior product designer at staff scope, on a team with a PM, engineers and other product designers.
I owned the error resolution experience end to end: what the assistant says when a configuration fails, what it proposes, and what the seller can change. Most of the platform was inherited and refreshed rather than redesigned. Error resolution was the part being built.
The part that took the most effort wasn't design. It was getting agreement that escalation was the problem worth solving.
It wasn't the interface.
The screen was dense, so the first conversations were about the screen. Reorganise it, group things better, show less at once.
I'd owned the configurator for years. Over four of them I'd spoken with more than fifty sellers and TSRs about how they actually work. So I went back to them with a narrower question: where does the time go?
Sellers lost time at the moment an error appeared that they couldn't resolve. That's when the work stopped being design and became a wait for someone else. On complex products that cost about a day.
I didn't argue for a different design. I argued for a different measure of success. We weren't trying to make a dense screen easier to read. We were trying to reduce how often a seller has to stop and wait for someone else to finish their work.
Once the goal moved, the layout work failed on its own terms. A cleaner screen would have made the same job slightly more pleasant. It wouldn't have removed a single escalation.
So the question became narrower and harder. Which errors actually send someone to a TSR, and can the assistant handle those instead?
What it cost: the timeline moved. Explaining an error well is more work than reporting one, and we were asking for that on top of a platform that already had a date. I took that to the PM before the design review, because scope and schedule were theirs to trade. By the time we met as a team, the goal had already changed and the date had already given way.
The obvious build was an assistant that fixes the error. You hit a conflict, it applies a correction, you carry on. That version was on the table and we rejected it.
I designed it the other way round. The assistant explains what conflicts with what, then proposes a change you can accept or edit.
The reason is the same reason sellers called a TSR in the first place. They weren't calling for a corrected file. They were calling because they couldn't tell what was wrong. An assistant that silently fixes things solves the symptom and leaves the seller exactly as dependent as before, just on software instead of a colleague.
The cost: more steps than an auto-fix, and a much harder writing problem. Every explanation has to be readable by someone who doesn't know the rule it's describing.
AI recommendations carry a margin of error.
On a catalogue this large, some suggestions will be wrong, and no amount of tuning removes that.
That could have been treated as a model problem to solve before launch. I treated it as a design constraint. If the assistant is sometimes wrong, the seller has to be able to tell. So the design shows what the assistant compared, what conflicts, and what it changed, in language someone can check.
This is what actually reduces calls to a TSR. Not the assistant being right more often, but the seller understanding the problem well enough to decide. A seller who can see the reasoning can accept it, correct it, or judge that this one really does need a specialist. All three are faster than not knowing.
The cost: a smaller headline claim. "The AI fixes your errors" sells better internally than "the AI shows its work and you decide."
Nothing the assistant produces is applied automatically. Every suggestion arrives as a draft you can change, and it states what it assumed.
A seller has to explain the quote to a customer. If they can't see why something was chosen, they won't send it. They'll rebuild it by hand, and the assistant has cost them time instead of saving it.
So the design question was never how accurate the model is. It was whether someone can see what it did and change it in one step.
We tested this. In usability sessions, people were noticeably more confident once the assistant showed its reasoning. That was the clearest signal we got.
The first version made the flow shorter without making it easier.
Fewer steps, but the seller was still holding the whole configuration in their head. And when something conflicted, the tool told them what was wrong without helping them fix it. That's the exact failure we'd set out to remove. We'd rebuilt the old problem in a cleaner interface.
That's the part I'd flag about my own process. I had the reframe early and the first design still didn't reflect it. Knowing the right problem and designing for it are two different pieces of work.
It was also the point where my job changed. A designer on the team had carried that first version, and it had been reviewed and approved on its own terms. Sending it back meant saying that the work was good and the target was wrong, and that the target was wrong because of a brief I'd set. I gave them a different definition of done: not a shorter path to a valid configuration, but a recoverable one, tested on the configurations that used to get escalated. Then I worked through the rebuild with them rather than taking the problem back. The recovery flow that went to engineering is largely theirs.
We stopped designing the ideal path and designed the recovery instead.
Designed, validated in usability testing, handed to engineering. Not built when I left in February 2026.
I'd rather say what I'd measure than claim a result I don't have. Three things would tell us whether it worked.
Escalation rate: how often a configuration still goes to a TSR. This is the number the whole project is aimed at.
Time to resolution: when an escalation does happen, how long it takes. With the assistant's explanation attached, it should be shorter even when it can't be avoided.
Edit rate on suggestions: how much sellers change what the assistant proposes before sending it. Too little means they're accepting without reading. Too much means the suggestions aren't good enough.
If I started again, the thing I'd push hardest for is a baseline measured before the build lands. We designed against a target, halving the time to build a quote, without a firm number for what it took before.
The tool wasn't failing at finding errors. It was failing at the moment after.