Enterprise · Logistics · Portal
Nine million packages. No single place to find a problem.
130,000 field personnel. 600 facilities. A 20-year-old desktop app held together by sticky notes and a person at a window.
The problem
Nine million packages. No single place to find a problem.
When something went wrong across 600 facilities and nine million packages a day, there was no single system to track it. Issues lived in sticky notes, emails, spreadsheets, and manual logs. This was not a software problem. It was a systemic one.
How might we give every role in the FedEx Ground operation one place to see, flag, and resolve pickup and delivery issues in real time?
- Ops Admin
- Knew something was wrong but had no way to flag it automatically.
- Ops Coordinator
- Found out by word of mouth, typically the next morning.
- P&D Manager
- Learned about problems through email chains that had already lost critical context.
- CSP
- Responsible for the drivers and often the last to know.
- Driver
- Waiting in line at a window to talk to the one person who knew everything.
5 user roles researched
User roles researched
600+ facilities in scope
Facilities in scope
130K field personnel
Field personnel
9M packages daily
Packages daily
The research
We went to the dock, Not the conference room.
The ops coordinator: a person no one knew existed.
Research began on the dock, observing drivers queue at the ops admin window. The existing system had never been designed for the people using it. In its absence, users had constructed a parallel one: sticky notes on monitors, a shared spreadsheet, a rotating verbal handoff between shifts. The ops admin held every open issue, every driver relationship, and every schedule conflict in memory. There was no documentation for that role, no redundancy, and no way for anyone else to see what that person saw.
Before a wireframe was drawn, the project ran three months of structured stakeholder sessions. Twice a week, two hours at a time, business stakeholders mapped the difference between what the system was supposed to do and what it actually did. When early wireframes went to a dozen facilities for review, counterparts across the country began comparing notes for the first time. The research confirmed what the dock visits had suggested: the existing system had adapted successfully to its users. Replacing a system that works is a fundamentally different design problem than replacing one that has failed.
What was built
One dashboard. Every issue. Every role.
The P&D Portal gives every role in the facility one place to see all pickup and delivery activity. Issues are flagged by type, routed to the right person, and escalated automatically if unresolved within 36 hours.
The Ops Admin flags an issue at check-in and adds notes in real time. The Ops Coordinator reviews, updates status, or messages the CSP directly from the issue detail. The P&D Manager sees the full escalation history and facility-level metrics. The CSP sees only their drivers, with full context already attached.
Performance trends across the week are visible to the Coordinator and Manager. Repeat issues can be flagged for escalation before they become patterns. The information that previously lived in end-of-shift verbal handoffs now lives in the system.
For the first time, the same issue looked the same to everyone responsible for resolving it.
People want to ram software through. This was not software. It was a systemic change.
The teaching moment
The method worked because the project actually succeeded.
The research
Go where the work happens.
The dock revealed what no requirements document would have. The ops admin was the institutional memory for the entire facility. A conference room visit would have missed all of it.
The framing
Name the real problem.
This was not a software project. It was a systemic change. That distinction is what made the research possible and the solution defensible.
The process
Start before you build.
Three months in a room before a wireframe. The design followed the research. The go-live held because the sequence was right.
Contact
Let’s talk about what your program needs next.
Direct conversation, no pitch deck. Tell me what your program is wrestling with and where it’s behind. I’ll respond with how the method addresses it.
