Unreliable identity
The same part could appear under different names across systems.
Back to work
From Fragmented Tools to a Scalable Ordering System
Defining the workflow behind centralized parts ordering across 700+ repair locations.
- Role
- Product Designer II · Asurion/uBreakiFix
- Timeline
- June to December 2025
- Team
- Product · Lead Engineering · Operations · Finance/F&O
- Scope
- Request intake · Queue · Item creation · Work-order state · Purchasing
Platform Context
The Systems Behind the Work
Legacy Portal kept ordering, finance, and operations in one system. Next Gen separated F&O from the repair platform, while a centralized team was taking over ordering across 700+ locations.
The technology could support ordering, but the operating model behind it had not been defined yet. Different teams had different assumptions about ownership, required information, and when a request was ready to move.
Through working sessions with Product, Operations, F&O Engineering, and the ordering team, we defined what made a request actionable, how existing parts should be verified, when a new item needed to be created, and what “complete” actually meant.
Discovery
Understanding How the Work Actually Happened
I watched the ordering team work through real requests. They checked Power BI, interpreted technician notes, and cross-referenced a spreadsheet to prevent duplicate inventory before they could even begin creating a new item. That spreadsheet was doing work the product was not—it signaled business logic we needed to preserve, not remove.
Findings
Three Gaps Shaped the Redesign
No feedback loop
Unclear requests became side conversations with stores.
The loop stayed open
Approval didn't finish the work order, PO, or handoff back to the store.
Decision 1
Replace Freeform Requests With Actionable Intake
Technicians had been describing needs in notes. I worked backward from what the ordering team needed to move without another round trip, reusing estimate and work-order context that already existed in Portal instead of asking technicians to recreate it.
Start from the work order
Carry device, estimate, and customer context into the request so technicians are not rebuilding information that already exists.
Create only when lookup fails
If the part cannot be found in F&O, open a structured creation flow instead of leaving the request in notes or sending the technician somewhere else.
Capture proof before submit
Require the part number, vendor link, and photos up front so the ordering team has enough to verify the request without another round trip.
Decision 2
Bring Item Creation Into the Workflow
A valid request could still stop if the part didn't exist in F&O. Instead of treating creation as a separate process, I designed it as a stage inside the ordering workflow.
Keep status visible on the work order
After submit, show the request state where technicians already work so they are not waiting on a silent handoff.
Separate existing parts from new ones
Make it obvious which items can move forward immediately and which still need F&O creation, with the SKU entered directly in the review flow.
Return the part to the work order
Once approved, add the item back to the same repair with its ordering state intact instead of making someone re-enter it manually.
Decision 3
Make Completion Match the Real Workflow
A request wasn't complete just because it was approved. Specialists still had to add the item to the work order, create the PO, and keep both systems aligned.
Replace the spreadsheet with one queue
Give specialists one place to see the work order, store, part, and request state without relying on Power BI exports or a side spreadsheet.
PO confirms completion
The request only moved to complete once a purchase order existed, giving the workflow a real end state.
Make completion visible
Completed requests kept the ordered parts, SKUs, PO numbers, and evidence together so specialists could see exactly what was fulfilled.
Outcome
We defined intake requirements, ownership boundaries, item-creation rules, queue state, and completion logic—and turned a loosely connected process into one operating model.
Technicians gained a structured way to submit requests, while ordering specialists gained clearer information and visible state across the process. Fewer steps depended on side conversations or someone remembering what happened next.
700+
repair locations supported by one ordering model
1
shared queue replacing spreadsheet and Power BI intake
3
manual handoffs tracked in one request from intake through PO