Rebuilding Returns Around Inventory State
Bringing return-required parts into Next Gen without losing the operational rules that kept inventory accurate.
- Role
- Product Designer II · Asurion/uBreakiFix
- Timeline
- April to June 2025
- Team
- Product · Engineering · Operations · Distribution · Finance
- Scope
- Reverse logistics · Inventory state model · Distribution handoff · Shipping readiness · Buyback workflow
Opportunity
The Opportunity
Next Gen was replacing Portal, the legacy POS and operations system used across stores, but return-required parts still lived in a disconnected workflow.
Technicians had to leave the main store system to send defective or otherwise return-required parts back to Distribution through the Return Merchandise Authorization process. Distribution, Finance, and Operations then depended on accurate return states to receive, process, and reconcile that inventory.
The challenge was not just moving the workflow into Next Gen. It was rebuilding it without losing the operational rules that kept the physical inventory accurate.
Discovery
What I Needed to Understand
The goal was not to recreate the Legacy workflow screen for screen. I needed to understand which parts of the process were essential, where the friction came from, and what needed to carry forward.
Store visits and working sessions with technicians, Technical Analysts, Operations, Distribution, and Finance helped map the rules behind that movement: eligibility, ownership, state changes, and where each part was being tracked.
Insight
The Insight
The biggest shift in my thinking was realizing this was more than a return-process problem. It was an inventory-state problem.
A part could be held at the store, grouped into an RMA, shipped, received by Distribution, and eventually reconciled out of inventory. At every step, the system needed to know where that part was and what still needed to happen.
The existing workflow technically had statuses, but broad states like Processing did not explain enough about where a part actually stood.
Decision 1
Make Returns Part of Inventory
RMAs were part of how store inventory moved through its lifecycle, so I placed the workflow inside Inventory instead of recreating it as a separate back-office tool.
I also designed the structure to support other return types, including Buybacks, without needing a separate experience later.
Place returns inside Inventory
Instead of recreating RMA as a separate back-office tool.
A shared home for returns
RMAs and Buybacks lived in the same Returns area, with separate views and lifecycle information for each.
Decision 2
Start From What the System Already Knows
Outstanding return inventory stayed visible from the RMA table, and eligible parts carried forward automatically when a technician started a new return.
That meant technicians were not rebuilding the RMA from memory. They started from what the system already expected back.
Keep outstanding parts in view
Unresolved return inventory stayed visible without forcing technicians to leave the workflow.
Carry eligible parts forward
A new RMA began with known eligible inventory instead of an empty table.
Verify the physical inventory
Scanning confirmed that the physical part matched what the system expected and helped catch duplicate or invalid additions before shipment.
Decision 3
Make Status Match the Real Operation
The existing statuses were too broad to show where a return actually stood. I worked with the team to define the moments where inventory condition or responsibility meaningfully changed, then translated those transitions into clearer states and groupings.
The result was a lifecycle that was easier to scan, trace, and trust.
Separate active work from completed returns
Status groupings made it easier to distinguish what still required action from what had actually moved forward.
Make the state traceable
Transaction history and serialized-part search connected individual inventory back to the return it belonged to and the state it had moved through.
Decision 4
Design Around a Distribution Approval Step
Submitting the RMA did not mean the shipment was ready. Distribution still had to approve the return before the shipping label could be generated, but Next Gen had no immediate signal telling it when that downstream work was complete.
My first instinct was to hide the wait and have the system check in the background. Engineering ruled that out: there was no clean signal from the downstream system and no practical polling solution.
Instead of automating the wait, I had to make it understandable. I used ChatGPT to pressure-test the technical options before bringing a direction to engineering. That helped me arrive at a lighter verification pattern: submit the return, make the pending state clear, and give technicians a reliable way to check back without wondering whether something had failed.
Confirm what can still ship
Before submission, the system checks eligibility one last time and surfaces any parts that can no longer be included.
Make the pending state checkable
Once submitted, Distribution still has to approve the return. The workflow gives technicians an explicit way to check whether the shipping label is ready.
Turn the wait into a real state
If the label is not ready, the interface explains what is happening and when the technician can try again.
Return to the normal flow once approved
Once Distribution approves the RMA and the label is generated, the technician can print it and continue with shipment.
Reflection
What started as a migration of an existing return workflow became a broader rethink of how return inventory should behave inside Next Gen.
The work created a stronger foundation for RMAs, Buybacks, transaction history, and future return types without rebuilding the experience each time.
The biggest takeaway was simple: rebuilding the process mattered more than rebuilding the screens.