Case Study
Dell Premier, Workflow & Access Management
Dell Premier is the portal where large companies buy Dell products. Inside it, different people have different levels of access. Nobody really understood how it worked, so they called Dell instead. Over 120,000 calls a month. My job was to reduce it by half or more.
- Client
- Dell Technologies
- Role
- Lead Designer
- Duration
- 6 months
- Team
- Product, Sales, PAM, Helpdesk, OBM
- Platform
- Web · B2B Enterprise
The problem
The system already had everything people needed. The problem was that nobody felt confident using it. Years ago, a site admin deleted something they didn't understand and broke every order on the account. After that, Dell locked parts of the system down and people stopped touching things they weren't sure about. Once someone did get access to Premier, there were no limits. They could buy anything, ship anywhere. So gatekeepers were extra careful about who they approved, and most of them just picked up the phone instead.
Approach
- 01Interviewed end users who needed access, site admins who were meant to give it, and Dell reps who kept getting pulled in to help.
- 02Ran two workshop sessions with 8+ stakeholders across product, sales, helpdesk and PAMs, spread across the US, Europe and Asia, using Menti for live anonymous polls so room politics didn't drown out honest opinions.
- 03Separated the four reasons people were actually calling, then designed a dedicated path for each one.
- 04Redesigned the role language around what people said they wanted to do (place orders, create quotes) instead of internal role names.
Context
Calls were the workaround, not the workflow
Dell Premier had a permissions model that had grown for 15 years. Roles, access groups, account hierarchies, all of it technically self-serve. In practice almost nobody used it that way. They called Dell. The volume was structural, not occasional.
Diagnosis
It wasn't a missing feature, it was missing confidence
Site admins could already manage access. They just didn't trust themselves to do it without breaking something. And because Premier had no spending or shipping limits once you were in, the people approving access were carrying a real risk they hadn't signed up for.
“I don't want to do it. I don't understand how to do it. So I need help.”
Research
Three groups, three very different problems
I talked to the people on every side of the request. The same workflow looked completely different depending on where you were standing in it.
“There is no way for a customer to track unless they keep track of the email communications. We don't have a customer-facing ticket system.”
End users
Didn't know why a feature was blocked. Couldn't find anywhere in Premier to ask. Once a request was sent, they had no idea what happened next.
Site admins
Didn't feel safe making changes. Requests came in through email, Teams, hallway conversations. Nothing was tracked anywhere.
Reps and PAMs
Handling 3,500 access requests a day, most of which the customer could have done themselves. Stuck using the same clunky interface as the customer.
Reframe
One call volume, four different reasons
As I sorted the transcripts, the 120K calls weren't one problem. They were four. Each one needed its own path, and the existing portal funnelled all of them through the same dead end.
Self-serve via admin
Someone needed access and their own site admin could sort it.
Routed through sales
Someone needed access but had to go through their Dell sales rep.
Direct to Dell
Someone needed access and had to contact Dell directly.
Broken access
Someone already had access but something wasn't working.
Workshops
Getting stakeholders to agree on the problem
Two sessions with 8+ people across product, sales, helpdesk and PAMs in three regions. Live anonymous Menti polls let people say what they actually thought without the room politics. The disagreement was real and useful, and it forced a clearer answer at the end.
“Don't make site admins feel like they're just a helpdesk.”
Simple requests go to the admin
Adding a user, changing a role. The site admin owns it.
Complex requests stay with Dell
Billing, SSO, payments. Too sensitive to delegate.
Self-service is opt-out
On by default, but a page can turn it off if the customer prefers Dell to handle it.
Insight
The real shift was making people feel safe
This wasn't about building a new feature. It was about making people feel safe enough to do something they technically could already do. Once we framed it that way, half the design decisions became obvious.
Language
Roles that match how people actually talk
Nobody said 'assign the Buyer role.' They said 'I just need them to be able to place orders.' Same system underneath, different surface. I rewrote the role language around outcomes people recognised, and added the consequences of each choice inline so admins could see what would change before confirming.
“In order to understand access groups and roles, you need to be in it all the time. Most customers just try to log in and start nosing around.”
Design
Two flows, deliberately separate
One flow for the person requesting access, one for the admin approving it. Linked together behind the scenes but never collapsed into a single screen. They have completely different needs and fears. Combining them would have made it worse for both.
Decisions
Research mapped to design moves
Audit
A history people can actually point at
Closed requests stop being lost email threads. Every approval and denial is timestamped, attributable, and searchable, which matters as much for the auditor six months later as for the admin tomorrow.
Reflection
What I took away
The hardest part wasn't designing the screens. It was getting people who all knew different pieces of a complicated system to agree on what the actual problem was. Keeping the two flows separate felt counterintuitive at first, but the more we tested it, the more obvious it became that one shared screen would have failed both groups.
Outcomes
What changed after the work shipped
